On Sun, Jul 11, 2004 at 04:25:46PM +0000, Mikhael Goikhman wrote: >On 11 Jul 2004 17:03:37 +0200, Dominik Vogt wrote: >> >> On Sun, Jul 11, 2004 at 01:26:55AM -0500, fvwm-workers wrote: >> > >> > Log message: >> > Apply conditionals patch. >> > >> > Committed patch by Norman Yarvin (with a few minor mods) to extend >> > conditionals to handle multiple window names. >> >> Hm, I did not expect this to be committed with the option naming > >I didn't expect this to be commited so shortly too, but so be it.
In any case, thanks. >> issue unresolved, but so be it. The current syntax is inaccepable >> because it is now impossible to use "$[w.name]" in a condition if >> the window has a '|' in its name. It's already bad enough with >> '?' and '*', but I see no need to add new problems. >> >> Instead, a new option should be added, perhaps >> >> Next (foobar "Netscape|Mozilla") foo >> >> that considers '|' to be special while the old syntax does not. > >This still leaves the problem with '?' and '*'. The situation with '|' is worse than with '?' or '*', because both of those match the literal characters; if someone names his window "**BIG**ANNOYING**WINDOW**", then the pattern "**BIG**ANNOYING**WINDOW**" will still match it. Not so with the window name "|BIG|ANNOYING|WINDOW|". >I think, the new condition option is not necessary. > >Instead, some filters may be added to variable expansion. I.e.: > > $[w.name] - expanded to: 'My %^&* window' > $[w.name:dquote] - expanded to: "My %^&* window" > $[w.name:noquote] - expanded to: My %^&* window > $[w.name:glob] - expanded to: 'My %^&\* window' > $[w.name:menu] - expanded to: 'My %%^&* window' At the moment, the code that interprets '|' doesn't deal with quotes itself, and can't even tell that there once were quotes -- they get stripped off inside GetNextSimpleOption(), or rather inside the general parsing code which it calls. Another thing that happens inside that code is that backslashes disappear. (Double backslashes get converted into single backslashes.) But one thing that can be done without changing or bypassing the general parsing code is to have repeating the '|' character twice, as in "||", match a literal '|'. (The only thing that would impair would be the ability to specify a zero-length string as one of the alternatives to match to; if the user wanted to specify a zero-length string, he'd have to make it the first or last alternative, as in "|foo|bar" or "foo|bar|".) Then one of those filters could expand "|" into "||". But is using "$[w.name]" in a condition a useful enough thing to do, that it is worth the trouble? -- Visit the official FVWM web page at <URL:http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm-workers" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
