Re: regex and case-fold-search problem

["Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu>]

> In article <200208231736.g7NHafW02174@rum.cs.yale.edu>, "Stefan Monnier" <monnier+gnu/emacs@rum.cs.yale.edu> writes:
> > But I think that if it works with (case-fold-search nil) it should
> > also work with (case-fold-search t).  The current behavior is really
> > counter-intuitive.
> 
> I agree.
> 
> >>  But, anyway, we have to decide what to do.
> >>  
> >>  (1) Regard the above case as a bug, and fix it completely.
> >>      As we don't support a range striding over different
> >>      charsets by the current Emacs, I think the fix is
> >>      difficult but not that much.  But, in emacs-unicode, we
> >>      can't have such a restriction, and thus the fix is very
> >>      difficult.
> 
> > For ASCII it's pretty easy to fix.  But for other charsets, it's
> > indeed more tricky.  Maybe we can simply use the smallest contiguous
> > range of chars that includes all the chars we should match,
> > so the behavior is indeed "implementation-defined" (in the sense
> > that it's not necessarily obvious to the user what happens) but
> > it's at least less confusing (in the sense that (case-fold-search t)
> > matches at least as much as (case-fold-search nil)).
> 
> Ideally, the range "[A-_]" must be converted to "[a-z[-_]".

Indeed and the (new) current code does just that for ASCII.

> But, it seems that your idea is to convert "[A-_]" to
> "[_-z]", correct?  I agree that it results in less
> counter-intuitive behaviour.

Not quite: [_-z] would not include [ \ ] and ^.
So instead it's [[-z] which includes all of [a-z[-_]
as well as ` (in this particular case).

> > How about the patch below ?
> [...]
> ?? It seems that the patch handles only non-ASCII chars.

Well, that's because the code for ASCII was already there (just
didn't work right because we did PATFETCH instead of PATFETCH_RAW).


	Stefan