Re: Buffer-local variables affect general-purpose functions

[Paul Eggert <eggert@cs.ucla.edu>]

Eli Zaretskii wrote:
> do we want to do something about that?

Yes, and we should start by removing the backwards-compatibility hacks 
in question.  Whether the current buffer is unibyte should not affect 
the behavior of general-purpose functions on characters.

Elisp code that blindly extracts bytes from unibyte buffers or strings, 
and treats these bytes as characters, is broken anyway.  It needs to be 
fixed to convert bytes to characters (using 'unibyte-char-to-multibyte', 
say) before it gives them to general-purpose character functions like 
'downcase' and 'char-equal'.

Years ago, when these backwards-compatibility hacks were put in, it made 
sense to have them, because unibyte non-ASCII locales were widespread 
and converting code to multibyte was a hassle.  But nowadays the vast 
majority of non-ASCII usage is multibyte and these hacks cause more 
trouble than they're worth -- not just core dumps such as Bug#17011, but 
subtle behavioral problems not easily diagnosed.  It's time for the 
hacks to go.