Re: Improvements to `(emacs)File Variables'

[Miles Bader <miles@lsi.nec.co.jp>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> I think the lisp/C level are a complete mess also, but it's probably too
>> painful and too much work to fix it.
>
> But are you still talking about the *concept* of unibyte, then?

I'm not sure.  "Unibyte" as used in emacs seems (to me) to imply several
things:  (1) of course, a single byte per character, (2) the concept of
strings/buffers whose encoding is "unknown".

If you were to consistently treat (2) as in fact meaning an explicit
"binary" encoding, maybe it would be useful, but my impression is that
at least historically, people/code have _not_ always done this, leading
to lots and lots of confusion.  I suppose much of the reason is that
people want the efficiency gain of (1), and either don't realize the
problems caused by (2) or think they can kludge around it.

As I've posted before, I think "unibyte" strings/buffers should be only
an optimization, and should have an explicit (8-bit) encoding associated
with them, so that any conversions to/from multibyte can automatically
do the correct thing; one of these encoding could of course be "binary",
which maybe would allow the historical usage of unibyte to be preserved.

[Note that I only vaguely understand Emacs unibyte stuff, so the above
may simply be a reusult of my confusion.]

-Miles
-- 
`Cars give people wonderful freedom and increase their opportunities.
 But they also destroy the environment, to an extent so drastic that
 they kill all social life' (from _A Pattern Language_)