Re: [PATCHES] Add command 'query'

[Thorsten Wißmann <edu _at_ thorsten _minus_ wissmann _dot_ de>]

On Mon, Mar 04, 2013 at 12:59:43PM -0800, Tyler Thomas Hart wrote:
> The first frame-index, ie, knowing what frame is selected. This is tricky,
> because of the tree structure. If we were to provide an attribute to the
> current-selected frame, should we use a string akin to the index that rules
> use? ie. "011"? or a 'flat' index (just an int)? Both would be useful...
> although a 'flat' index would be counterintuitive, imo, comparing ints is just,
> well, easier.

Why not both[1]? But I can't see an application of that index being an
integer. One could check if the "first" frame is activated (so it
doesn't mater if the index is 00 or 000). But why would someone need
that?

> The second one is: would it be viable to provide attributes for environment
> variables? In particular, I would use it to substitute variables with the
> 'substitute' command (which, for my uses, would be very useful, for example,
> comparing an attribute to an envvar). 'getenv' and 'setenv' could be
> depreciated/redundant due to these more general methods, and I suspect there
> are other uses as well.

I don't want to remove these "redundant" commands for the sake of
compatibility and intuition. "getenv foo" is much more intuitive then
"get_attribute environment.foo" for someone who knows environment
variables and getenv(3).

For what do you need this? If you need it for maintaining some state,
then the actual (and planned) solution is to allow the creation of
custom attributes on any object.

> For herbstlogic to have an intuitive syntax it should fully support if...then...else
> statements. This is ALMOST supported with the current chain operators:
> 
> if CMD1 then CMD2 else CMD3 ~= (CMD1 && CMD2) || CMD3
> 
> The problem is that if CMD1=true and CMD2=false, CMD3 still executes. This was a
> problem in my original query-swap script on arch BBS.
> 
> The solution is to 'cast' CMD2 to always return true. The ideal solution, imo, is
> to create wrapper commands 'true CMD' and 'false CMD' to do this. I already have
> a branch which implements this. [...] 'true' is a command that always
> returns 0 (eg. 'list_foo')
> 
> My question is, should 'true CMD' and 'false CMD' be implemented if there already
> exists a viable workaround? Again, perhaps not, because of the argument that 'hlwm
> shouldn't support explicit server-side-scripting', but it would only add ~10 lines
> of code... (we could even the completion factions for '!')

I also thought about that problem. But IMO "true CMD" is not intuitive,
because if I run "true bla" I do not expect bla to be evaluated. But
true and false are nice: they're analogous to /bin/true,/bin/false.
(btw, i fear i need something like a sprintf command...)[2]

By now, I don't have a problem with hlwm becoming a scripting language
(if it is not already). I just do not want it to become undecidable (or
even Turing Complete). My goal is: hlwm still is running and responding,
no matter what command the user executes (except for quit/wmexec of
course).

> I guess the REAL question I should be asking is: can anyone think of any use-cases
> for 'true CMD' and 'false CMD' besides my example?

No, mainly for adjust the behaviour of and/or. Does anyone else see an
application?

Cheers,
Thorsten

[1] http://www.quickmeme.com/meme/3t8u78/
[2] http://en.wikipedia.org/wiki/Greenspun's_tenth_rule