emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: regex and case-fold-search problem


From: Kenichi Handa
Subject: Re: regex and case-fold-search problem
Date: Sat, 24 Aug 2002 10:16:10 +0900 (JST)
User-agent: SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/21.1.30 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI)

In article <address@hidden>, "Stefan Monnier" <monnier+gnu/address@hidden> 
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[-_]".
But, it seems that your idea is to convert "[A-_]" to
"[_-z]", correct?  I agree that it results in less
counter-intuitive behaviour.

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

---
Ken'ichi HANDA
address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]