On Sat, Nov 06, 2004 at 08:42:28PM +0000, Mikhael Goikhman wrote: > On 06 Nov 2004 15:00:12 +0100, Rafal Bisingier wrote: > > > > On Tue, Oct 26, 2004 at 01:33:11PM +0000, Mikhael Goikhman wrote: > > > 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.
Well, look's like I haven't understood you indeed. And even worse: to get what you've said, much bigger change than I thought is needed... :-( In the meantime I've found a problem with this double char escaping algoritm. If we use '**' to get literal match for '*' and '*' to match any string, then there is no posibility to match strings like: 'One*', 'Two*', 'Three*' with a wildcard pattern. So I've thought that we should change escaping character to some non-special one (eg. '\'), and use '\*' for literal '*' match, and of course '\\' for '\'. I know this will add new special character, but I don't see any other solution. > > > 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. The code for variable expanding is a little strange. There are 2 functions. One for simple variables (like n), and one expanding extended variables (like w.name). First function calls second two times: - first it only check output length, and allocates memmory for it - at the second call it actually copy output to the allocated memory. That's why I decided to use 'static char*' buffer. Nevertheless it's not needed there, because we should do filtering in another function. ;-) > 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' So now I see filter support have to be added first. ;-) > > > > 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. If using current fvwm can be treated as testing, then I do that every day... ;-) For fixing bugs - I'm afraid my programming skills are insufficient. :-( > > 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. I understand, and try to do something to speed up 2.6 release... ;-) -- Rafal Bisingier
pgpvAHxcFKMe7.pgp
Description: PGP signature
