Subject: Re: FVWM: Matching windows with * in it's name

From: Rafal Bisingier <[email-masked]>
Date: Sat, 6 Nov 2004 15:00:12 +0100

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.

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

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

> > 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? ;-)

I'd realy like to see this Name/IconName/Class/Resource/AnyName syntax.

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

I've noticed that Dominik doesn't have time recently... ;-)

> fvwm-workers should be a better place for these discussions.

So I'm moving this thread to fvwm-workers, because here is my next patch
atached adding discussed here new functionality.

-- 
Greetings
Rafal Bisingier

---

From: Mikhael Goikhman <[email-masked]>
Date: Sat, 6 Nov 2004 20:42:28 +0000

> This functionality is already implemented.

True. I forgot that we discussed the commited code in that thread.

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

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

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

---

From: Rafal Bisingier <[email-masked]>
Date: Mon, 8 Nov 2004 16:49:28 +0100

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

> 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

So now I see filter support have to be added first. ;-)

> 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 want to see it too. But I want to see 2.6 even stronger.

:-)

> his authors also does something from todo-2.6.

I understand, and try to do something to speed up 2.6 release... ;-)

-- 
Rafal Bisingier