Re: regex and case-fold-search problem

[Kenichi Handa <handa@etl.go.jp>]

In article <9743-Sat24Aug2002123958+0300-eliz@is.elta.co.il>, "Eli Zaretskii" <eliz@is.elta.co.il> writes:
>>  > Does that happen because under case-fold-search non-nil the
>>  > characters on the range specification are downcased?
>>  
>>  Yes.

> Then perhaps, instead of downcasing the range, we should do the
> comparison in a case-insensitive manner?  Or is that impossible with
> the current regex code?

Of course, it's not impossible.   It's just not easy.

>>  I mean that the concept of character range itself is not
>>  good.

> As Miles wrote, it does make a perfect sense in a context of a
> specific language.  For example, if the characters that designate the
> range are all Cyrillic characters, the range is sensible.

It makes sense only when we assume some character set (or
locale).  For instance, in Emacs 21, Cyrillic characters has
the same code order as that of iso-8859-5.  But, in
emacs-unicode, we use Unicode.  So, a Cyrillic char range
that works well in Emacs 21 won't work in emacs-unicode.

> It would IMHO be a pity to lose the ability to specify ranges in such
> cases.

I don't suggest to remove that ability.  I'm just wondering
if it is worth spending our time (and perhaps users time) to
make Emacs behave completely correctly to handle a char
range especially in the case that case-fold-search is t.

I think something like Stefan's compromise method (quoted
below) is good enough.

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

---
Ken'ichi HANDA
handa@etl.go.jp