Re: Unibyte characters, strings and buffers

[Eli Zaretskii]

> Date: Fri, 28 Mar 2014 11:42:16 -0700
> From: Paul Eggert <address@hidden>
> CC: Emacs development discussions <address@hidden>
> 
> On 03/28/2014 01:18 AM, Eli Zaretskii wrote:
> > what you suggest will just
> > replace one set of subtly buggy behaviors with another
> 
> Code that blithly passes bytes in the range 128-255 to char-equal is 
> *already* buggy.

There's nothing wrong with those bytes, certainly not when they stand
for Latin-1 characters.

> Although the proposed change wouldn't fix those bugs, it'd fix
> others, so it'd be a win.

How is it a win, when it actually _adds_ bugs?  E.g., under your
proposal, (char-equal 192 224) will yield non-nil when
case-fold-search is non-nil.

> Plus, the change is simpler and easier to explain than what we have now, 
> and that is a long-term win.

I don't see how it is simpler or easier to explain.  It replaces one
lopsided interpretation of 128-255 values with another.

> I'm afraid what I'm hearing is "although it's broken, unless we come up 
> with a perfect solution we shouldn't do anything".

I don't know where you heard that.  I certainly didn't say anything
like that.

> I'd rather fix this particular problem now, even if it's not
> practical to fix all the related problems now.

I suggested a solution: ignore case-fold-search in unibyte buffers.  I
think that's a greater win.

> We don't need to slay the entire unibyte dragon to fix the
> relatively minor issue of comparing characters.

I agree.  But then you are responding in a wrong thread ;-)