On Dec 7, 2012 4:36 AM, "Thorsten Wißmann" <edu@thorsten-wissmann.de> wrote:
>
> On Thu, Dec 06, 2012 at 12:29:20PM -0800, Tyler Thomas Hart wrote:
> > I've realized that there are a lot of unncessesary delarations. Patch 0014
> > fixes this.
>
> If you have a fixup for a patch, that isn't merged to master yet, then
> please resend the fixed patch and *not* another patch that fixes a bug,
> that's not there in hlwm yet. (That also applies to all other submitted
> patch sets).
>
This makes sense, sorry. And noted.
> Sorry for letting you wait for an answer. I was very busy (and still am
> today). So I'll probably check your patches tomorrow.
>
No worries! No hurry. I sent the first ones in because I was excited to get critiques. I sent the latter ones because I actually think they'd help people. But I doubt anyone using HLWM is in desperate need of a negation command :).
> - negation: That's a good feature. I first didn't added it because I
> didn't want to create yet-another scripting language
Yeah, I'd be weary of that too, and I really appreciate how seemingly focused you are about the direction you want to take this project. A side effect of and and or command was that it created an internal scripting language (a functional, logical one). The majority of users won't care about that, especially when the i.s.l. isn't a traditional, imperative syntax. But there will always be users like me, who will exploit it to the best of there ability if it means a slight gain in performance.
Whether or not enabling these people is a goal, a side effect, or an enemy to the project is entirely up to you. It's your thing!
There are definitely more uses of negation and query (or whatever your implementation will be called) than YASL though, and if it doesn't add too many lines of code and doesn't effect the functionality of the rest of the program, I personally find it OK to enable the hackers.
> - shift_edge: I don't know why someone needs that but if it's useful
> to you and not much code, I don't mind.
Thanks, that patch was a couple weeks ago, so I don't remember how clean the implementation was. But I think the premise would be useful to a lot of people.
The reason I wrote it was basically to abbreviate part of a script, which kept calling shift until it returned a nonzero. Shift_edge just does the thing server side instead of client side.
An alternative solution would be writing a command that takes any other command, and repeats it (until a nonzero). This would take only a few lines of code, and have greater scope and more uses than my command. But it would also contribute to my yet-another scripting language paradigm, and it would also be DANGEROUS without safeguards like a max_repeat or something similar. So your call.
> - cycle_shift: That sounded equivalent to move_index with a relative
It was just move_index and use_index rolled into one command before I realized what chain did. Not even worth looking at.
> - shift_cycle_monitor: I'd prefer something like a monitor equivalent
> to move_index. The name shift_monitor should be OK, and the syntax
> should be: shift_monitor INDEX, where INDEX is either absolute,
> relative (if it's prefixed by a sign) or also a monitor name (in
> near future).
Your suggestions are great. Those are some things I'll look into implementing. Flo, what exactly are you offering?
> - query: I like the basic idea, but I don't like that we have to
> implement each variable to query explicitly (ntags, nframes,...).
> But I already planned to implement something more general in near
> future. (It heavily will be inspired by KObjects known from the
> linux kernel).
Yeah, come to think of it, most of these queries just point to integers that already exist, so I could've made query just contain a names, and unions of either pointers to ints or functions (for the handful of queries that require descending the tree). This would cut my code nearly in half.
I'm not sure what you mean by implementing each variable explicitly. If we DID let the user query just any old value in the running image, we'd still have to provide them with aliases to be able to access them, right?
That's essentially all the argument QUERY represents: an alias to an already existing value. With a few exceptions, that's all creating a query is, giving an int in the source a name that's easy for the user to remember.
I'm not familiar with KObjects, but if you have a better implementation that can accomplish the same thing, then by all means!
As long as there is some kind of _expression_ evaluation, so I can keep (secretly) exploiting the internal scripting language, then I'd be happy with that.
Thanks
Tylo