Subject: CVS scott: Apply conditionals patch.

From: FVWM CVS <[email-masked]>
Date: Sun, 11 Jul 2004 01:26:55 -0500

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.

--
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-masked].
To report problems, send mail to [email-masked]

---

From: Dominik Vogt <[email-masked]>
Date: Sun, 11 Jul 2004 17:03:37 +0200

> 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-masked]
Reply-To: [email-masked]

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 11 Jul 2004 16:25:46 +0000

> 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.

> 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.

---

From: Norman Yarvin <[email-masked]>
Date: Sun, 11 Jul 2004 16:56:08 -0400

>I didn't expect this to be commited so shortly too, but so be it.

In any case, thanks.

>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|".

>  $[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?

---

From: Mikhael Goikhman <[email-masked]>
Date: Sun, 11 Jul 2004 22:21:15 +0000

On 11 Jul 2004 16:56:08 -0400, Norman Yarvin wrote:
> >> The current syntax is inaccepable

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.

---

From: Scott Smedley <[email-masked]>
Date: Mon, 12 Jul 2004 12:40:46 +1000

> 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.