Re: Real unibyte files

[Eduardo Nahum Ochs]

> From: Eli Zaretskii <eliz@is.elta.co.il>
> Date: Wed, 25 Oct 2000 09:54:05 +0200 (IST)
>
> > From: Eduardo Nahum Ochs <edrx@inx.com.br>
> > Date: Tue, 24 Oct 2000 18:15:49 -0200
> > 
> > Hi! I need help to "modernize" some of my files to make them
> > compatible with GNU Emacs20 (20.7.2, to be precise) -- at this moment
> > they work only if I force Emacs in unibyte mode explicitly in one way
> > or another...
> > 
> > So: is there some variable that can be set in the "Local Variables:"
> > section of a file that will force Emacs to load that file in a "real"
> > unibyte mode?
>
> You haven't told enough details to give you useful advice.  For
> starters, please consider describing what non-ASCII characters do your
> files include, and for what purposes.
>
> In general, the best solution would be not to force Emacs into the
> unibyte mode.  But given the information you posted, it's really hard
> to say whether this is possible in your case, and if so, how.

Sorry - I haven't given more details at first because I was afraid of
getting an answer on the lines of "then you deserve what you got"...
:-)

I don't think I can give a short objective description telling exactly
the information you need, but I'll try to at least describe everything
in a useful or interesting way... Sorry for the length.

I use GNU Emacs to edit some giant files of mathematical notes, with
many TeX'able parts, and over the years I have been tweaking the
console font I use to replace all the characters I don't need for
useful mathematical symbols. You can see a (slightly outdated) picture
of my Emacs using that font here:

  http://angg.twu.net/emacs.html
  http://angg.twu.net/a/IMAGES/emacsvtutil.png

The special mathematical characters are scattered by all possible
ranges: 128-255 (not only 160--255!) and even 0--31. I had to do some
display-table hacking and even assign complex string glyphs to the
ones that would be unprintable by default, using this function to make
the string:

  ; See "man 4 console_codes";
  ; search for "ESC % G", "ESC % @" and "UTF-8"
  ;
  (defun glyphs-unicode-char (n)
    "Return a string that will display char N, for 0<=N<=511."
    (if (eq system-type 'gnu/linux)
        (format "\e%%G\xef%c%c\e%%@"
                (+ 128 (logand (lsh n -6) 7)) (+ 128 (logand n 63)))
      "?"))

Note that a command like the one below in TeX or LaTeX will assign a
definition for one of those characters (I replaced the char by a "*"
for obvious reasons).

  \catcode`*=13 \def*{\multimap}

So, I've been using Emacs as an extremely convenient, but somewhat
unportable, TeX editor.

Over the last weeks I learned how convert my console font to a BDF
font that X can use, and I've added a language to iso-accents-mode to
let me enter my characters in a convenient way. But I'm also helping a
friend type some texts in Chinese (the chinese-tonepy input mode is
great, by the way!), and I decided that it was time to stop forcing
Emacs into unibyte mode, and that I should instead use the "Local
Variables:" section of my files to tell Emacs to enter unibyte mode
for them.

The problem is that neither the "raw-text" or the "no-conversion"
codings are exactly unibyte modes; if you place the cursor on a char
174 or 175 and do a "C-x =" (or "C-u C-x ="), at least on my Emacs
20.7.2, you see that they are reported as chars 2048+174 or 2048+175
-- a MULE-ism, I think... These characters get very special glyphs in
my font: they get more complex strings assigned to them in console
mode, and they get a face attribute in their glyphs in X mode, and the
result is that they get displayed as green guillemots ("<<" and ">>").
I use other colored characters also, but let's concentrate in these
for now.

The simplest and most elegant solution would be to find a variable
(that could be set in the "Local Variables:" section, if possible)
that would force a buffer into a "real" unibyte mode; I can also
change my glyph-setting routines very carefully to make them work in
all cases, but if I have to do that then I would like some advice on
which Lisp and C files to check to understand Emacs' behaviour.

  TIA and cheers,
    Eduardo Ochs
    http://angg.twu.net/
    http://angg.twu.net/eev-manifesto.html
    http://angg.twu.net/tourism.html
    edrx@inx.com.br