On Monday 09 October 2006 20:28, Andrey Borzenkov wrote:
> On Monday 09 October 2006 16:00, Peter Stephenson wrote:
> > Andrey Borzenkov <arvidjaar@newmail.ru> wrote:
> > > The point of patch is to replace exhaustive enumeration of all possible
> > > combinations by comparison of patterns. I.e. it checks if two patterns
> > > may have something in common - this can be generalized later using
> > > different pattern representations.
> > >
> > > I would be happy if we could just toss away this function.
> > >
> > > Comments?
> >
> > I don't know enough about this stage of completion to comment in any
> > detail, but it certainly looks like we need to do something about
> > it...
>
> to avoid duplication of efforts - I know now how to do it properly (that
> is, to preserve full functionality without relying on current fixed 256
> byte tables), I just have to find some time to write it down.
>

OK so here is the updated patch; all tests passed; unfortunately I still do 
not know how to write regression tests that would specifically check this 
function.

I dare to presume that code became legible enough to be understandable now. It 
checks if it can match next character(s) and then recursively tries to match 
the rest. The net effect is that instead of answering "how to find all 
characters matching given pattern" we have to answer "can two patterns match 
the same character". It is obvious for literal character, ? and equivalence 
class; it is also obvious for future [:upper:] and [:lower:] patterns; and it 
is straightforward (albeit not necessarily fast) for [...] set.

Question - how does zsh internally represent [...] now? If this is a (set of) 
bit strings, comparison is trivial.

Comments (now attached)?