On 06 Nov 2004 15:00:12 +0100, Rafal Bisingier wrote: > > On Tue, Oct 26, 2004 at 01:33:11PM +0000, Mikhael Goikhman wrote: > > 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. > > This functionality is already implemented.
True. I forgot that we discussed the commited code in that thread. > > 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) ... > > Ok, so I've done it. Conditional commands now understand doubled '*', > '?' and '|' as escaped chars. > I've made also $[w.name:pattern] filter. Hmm, you didn't do what I meant. :) I meant a filter that may be applied to any variable, i.e. $[w.iconname:pattern] $[HOME:pattern] This escapes all special chars like "*" to be suitable for conditions. > > If you are at it, you may implement other suggested filters, but please > > test this thoroufully if you do it. > > I've tested it, and don't see any problems with it. I didn't see the whole code, just the diff, but it seems that your $[w.name:pattern] is done incorrectly. IIRC, there should be 2 parts, one that estimates the resulting string length and one that generates the expanded string content. You should not really allocate the string space yourself. For the "pattern" filter you may double the string length as an estimation. But there is no support for filters yet, it should be added. Possible filters would be: $[VAR] - expanded to: 'My %^&* window' $[VAR:dquote] - expanded to: "My %^&* window" $[VAR:noquote] - expanded to: My %^&* window $[VAR:pattern] - expanded to: 'My %^&** window' $[VAR:menu] - expanded to: 'My %%^&* window' > > > 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. > > I suspected you'll say that. I don't think I can do anything to change > this, so maybe from the other side: what is needed to release 2.6? ;-) Testing, testing and fixing bugs in the bug system and todo-2.6. > I'd realy like to see this Name/IconName/Class/Resource/AnyName syntax. I want to see it too. But I want to see 2.6 even stronger. I will support inclusion of the patch for these condition options if his authors also does something from todo-2.6. 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]
