Re: CVS scott: Apply conditionals patch.
On Sun, Jul 11, 2004 at 01:26:55AM -0500, fvwm-workers wrote: CVSROOT: /home/cvs/fvwm Module name: fvwm Changes by: scott 04/07/11 01:26:55 Modified files: . : AUTHORS ChangeLog fvwm : conditional.c fvwm.1.in fvwm.h 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 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. Ciao Dominik ^_^ ^_^ -- Dominik Vogt, [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] pgpWkUHa4TaEy.pgp Description: PGP signature
Re: CVS scott: Apply conditionals patch.
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. 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 '*'. 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' Regards, Mikhael. -- 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]
Re: CVS scott: Apply conditionals patch.
On Sun, Jul 11, 2004 at 04:25:46PM +, 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]
Re: CVS scott: Apply conditionals patch.
On 11 Jul 2004 16:56:08 -0400, Norman Yarvin wrote: On Sun, Jul 11, 2004 at 04:25:46PM +, 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: Committed patch by Norman Yarvin (with a few minor mods) to extend conditionals to handle multiple window names. 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? There is a need for the quoting syntax of '*', '?' and '|' in names. I would not encourage usage of $[w.name] as-is in any place with special characters, so this should not be an issue. The current situation is that there is no way to specify the exact window names like raised, transient, visible, sticky and many others in conditionals. This problem is IMHO even worse than a possible '|' problem. I think the current syntax of non-option names should not be the main one in the long run. How about to solve the whole issue correctly by introducing the following options in conditions: Name pattern, IconName pattern, Class pattern, Resource pattern AnyName pattern All of these will support special pattern characters including |. The non-option names are still supported, but there is a better syntax. And we still need the variable filters like $[var:pattern], and quoting syntax for names in conditions; ||, ** and ?? is ok by me. Regards, Mikhael. -- 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]
Re: CVS scott: 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 issue unresolved I was not aware of this issue. This is the first post I've seen discussing it. I saw Mikhael's proposal (liked it) audited/tested Norman's subsequent patch to make sure it did what Mikhael suggested. Did I miss other posts on the topic? Either way, I'm sorry to have caused a problem. SCoTT. -- 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]
