On 26 Oct 2004 14:21:56 +0200, Rafal Bisingier wrote: > > On Tue, Oct 26, 2004 at 10:10:16AM +0200, Dominik Vogt wrote: > > On Thu, Oct 21, 2004 at 10:58:40AM +0200, Rafal Bisingier wrote: > > > > > > > > On Wed, 20 Oct 2004, Rafal Bisingier wrote: > > > > > > > > >I've found a problem with selecting windows which > > > > >name/res/class/icon contains a literal *. > > > > >I've looked in the source code, and if I understand it function > > > > >matchWildcards from libs/wild.c use every * as a wildcard, so > > > > >there is no chance to match only a literal *. > > > > >I think I can patch it to use ** as a literal *, but I'm not > > > > >sure if it's a good way of resolving this problem. > > > > We recently had a discussion about qouting of window titles. > > Mikhael came up with with a suggestion to solve it by enhancing > > $[...] expansion. Maybe someone can look up the thread in the > > list archives. > > I've found a thread "CVS scott: Apply conditionals patch." from July in > which this (and couple of other, even more serious) problem has been discussed, > but this thread ended with Mikhael's suggestion: > <cite> > 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. > </cite> > > I can implement "||", "**" and "??" part (it should be simple), but I > want to know if there is a chance to inclusion of this patch into to > fvwm (this is my original question as you can see above)?
I think someone else wanted to implement the OR syntax, i.e. "|", I have no idea what is the status of this. The first step (that you can do) is to handle the specified doubled chars as escaped char rather than meta-chars in conditions. And implement one filter "pattern" that quotes variables in order to be used in commands that require patterns. I.e. Next ($[w.name:pattern], !Iconified) ... If you are at it, you may implement other suggested filters, but please test this thoroufully if you do it. > It'll be good to implement also the proposed syntax for selecting window > exclusivly by it's class, resource, icon name or title, but I'm not > sure if I have enough skill to do it. > And there's still a problem with backward compatibility of this new > syntax. Can we just leave existing syntax as is, and add only the new > options? I know it can break backward compatibility in some (I think > rare) cases when one want to select window named for ex: "Name" or > "Resource", but in this cases there will always be posibility to use the > new option AnyName. I don't think that Name/IconName/Class/Resource/AnyName should be done before 2.6. > PS. I know I'm a little boring with this, but some time ago I've send a > patch adding new Test option... ;-) I guess, noone had a time to look at it yet. fvwm-workers should be a better place for these discussions. Regards, Mikhael. -- Visit the official FVWM web page at <URL: http://www.fvwm.org/>. To unsubscribe from the list, send "unsubscribe fvwm" in the body of a message to [EMAIL PROTECTED] To report problems, send mail to [EMAIL PROTECTED]
