Re: Pattern bug on (a*|)~^(*b)

[Johan Grande <nahoj@crans.org>]

Le 29/07/2023 à 03:35, Bart Schaefer a écrit :
> On Thu, Jul 27, 2023 at 11:41 PM Stephane Chazelas 
> <stephane@chazelas.org> wrote:
>> 
>> I have to say I'm with the OP and don't understand that explanation
>> either.
> 
> In the absence of a direct response from PWS, I'll just point you to 
> his comments in pattern.c, some of which date from before we had a
> git repository: [...]
> 
> By my reading, zero-length matches may be short-circuited to avoid 
> pathological behavior.

Thank you for your answers, though the latter is rather obscure to me.

If you can answer, or if PWS reads this:

What globbing should do is one thing, but in the meantime I'm interested
to know what I can safely put on the left-hand side of ~ with the
current implementation. Does this behavior concern any case of
backtracking, or only (...|...) patterns, or, which would be even
better, only (|...) and (...|) patterns?

In my project, I use globbing to find files with tags matching patterns
provided by the user, because I noticed that it's much faster than
anything else I tried, and I use ()~^() and (|) as AND and OR operators.

As an example, here is the pattern generated for files with tags 
matching pat1:

*[[](((* |)pat1( *|)))[]]*

which I could easily replace with:

*[[](((* )#pat1( *)#))[]]*

Then this would be the pattern for files with pat1 and pat2 and neither 
pat3 nor pat4:

*[[](((* )#pat1( *)#)~^((* )#pat2( *)#))[]]*~*[[](((* )#pat3( *)#|(* 
)#pat4( *)#))[]]*

So I'm thinking I could filter for user-provided patterns that contain 
'|' and don't put them in the mega-pattern but filter for them 
post-globbing. Does that sound like a sound solution to you?

-- 
Johan