Subject: Renaming "On" command to "Test"?

From: Dominik Vogt <[email-masked]>
Date: Thu, 22 May 2003 09:29:44 +0200

I think "On" is only something programmers understand.  How about
renaming it to "Test" (like the shell command) before 2.6?

Bye

Dominik ^_^  ^_^
--
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: Mikhael Goikhman <[email-masked]>
Date: Thu, 22 May 2003 10:54:19 +0000

> renaming it to "Test" (like the shell command) before 2.6?

No opinion here. You may rename it if you like.

I think it sounds naturally for an English man when used as:

  On (Version 2.6.0) do something
  On (Restart) do something  # this condition is only true in .fvwm2rc

It may be renamed to "If" as well.

Regards,
Mikhael.

---

From: "Mathias Megyei;Munich" <[email-masked]>
Date: Thu, 22 May 2003 13:32:22 +0200

> It may be renamed to "If" as well.

What about "Given"?
("Given" will be introduced in Perl 6 for statement like
  switch ... case.)

Regards,

Mathias

---

From: Olivier Chapuis <[email-masked]>
Date: Thu, 22 May 2003 09:40:53 +0200

> renaming it to "Test" (like the shell command) before 2.6?

No objection.

Regards, Olivier

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 22 May 2003 13:10:17 +0000

> ("Given" will be introduced in Perl 6 for statement like

Just thought about something new. The current "Cond" and "CondCase"
may probably be mixed into the "On" command.

If we take this "Given" suggestion here goes:

  Next (XTerm) WarpToWindow
  Given (Match) Focus
  Given (!Match) Break

Actually this "Given" syntax is for "Cond".  "CondCase (Match)" may be
replaced with "Given (Match) Continue". Yes I think it is good and useful
to have Continue command (prefix) that just preserves the previous
returning code ignoring a possible returning code of the current command.

Here is an example for a case statement:

  Given (Version < 2.7.2) Echo Please upgrade to at least 2.7.2
  Given (Match)    # do something old
  Given (NoMatch)  # do something new for 2.7.2+

Another examples (probably "-" may be optional):

  Given (-x fvwm-root) Exec fvwm-root bg.xpm
  Given (NoMatch) Exec xmessage "Fix your PATH for fvwm-config & fvwm-root"

  Next (MyConsole) MoveToDesk
  Given (Match) Raise
  Given (!Match) Given (-x rxvt) Exec rxvt -name MyConsole
  Given (NoMatch, -x xterm) Exec xterm -name MyConsole

I think that I like this syntax.

Regards,
Mikhael.

---

From: Mikhael Goikhman <[email-masked]>
Date: Thu, 22 May 2003 21:41:51 +0000

> I think that I like this syntax.

It's buggy. For this to actually work, we should keep separate return
codes for window based conditionals ("Match", "NoMatch", "Error") and non
window conditional, i.e. "Given", the new codes may be "Then" and "Else".

  Given (Version < 2.7.2) Echo Please upgrade to at least 2.7.2
  Given (Then)    # do something old
  Given (Then)    # do something old
  Given (Else)    # do something new for 2.7.2+
  Given (Then)    # do something new for 2.7.2+

And the last example may be:

  Next (MyConsole) MoveToDesk
  Given (Match) Raise
  Given (Match, Xinerama) MoveToScreen  # just an example
  Given (!Match) Break
  Given (-x rxvt) Exec rxvt -name MyConsole
  Given (Else, -x xterm) Exec xterm -name MyConsole
  Given (Else) Echo No good terminal found to run MyConsole

Probably there are more intuitive names than "Then" and "Else", like
"Pass" and "Fail".

Maybe it is not such a perfect idea to combine "Cond" and "On".
But it seems to work ok and separating return codes is good in any case.

What do you think?

Regards,
Mikhael.