Re: a few MULE criticisms, cemacs, & current emacs segfaults by changes in GNU ld.

[Stefan Monnier]

> This is not meant to be a flame - Mr Stallman asked me why I would rather
> continue to use emacs 19.34 (and fixes its problems) in combination
> with an old cemacs elisp script instead of using MULE, and I am writing
> this in the hope that MULE will satisfy my editing needs one day. I
> am native Chinese, and can also do a small amount of Japanese, so
> my experience is probably quite representative.

I have no knowledge of any non-latin script, so could you explain
to me how Emacs-19.34 can be used to edit in a character-set larger
than 256 chars ?

> (4) The inability to process part of a file in one encoding and
> save it as a binary stream: This might be possible in MULE, but
> I can't work out how - MULE seems to insist that I save or
> convert documents into its internal representation.

That is true but not fundamentally bothersome, when you think about it:
the way the file is internally represented is not important.
What matters is what you see on screen and what you get when you
save the file (i.e. mostly that the unedited parts of the file are
preserved bit-for-bit).
Emacs-21 is much better at "preserving bytes that we don't understand".

> e.g. I have a file,
> part of which is in GB2312, part in JIS-euc, and part BIG5, separated
> by clear ASCII markers. I would like to edit the different parts

This is indeed not well supported.  But you can try to read it
once with GB2312 (at which point the BIG5 part will look like
garbage, but it should be preserved AFAIK, if not you might want
to report it as a bug).
You can later re-read the file with a BIG5 encoding (at which
point the GB2312 part will look like garbage, ...).

> individually, and without breaking the others, and without converting
> to MULE's internal format or a common one like UTF-8. I don't think
> it is difficult to implement, but it is more like the MULE developers
> think they know my needs better than I do, and insist that I do
> things their way.

Emacs could support the situation you describe, but nobody has bothered
to write the code for it AFAIK.  It can all be done in elisp, tho.

> As for the portability problem with the elisp script cemacs.el
> (the origin of the whole thread) to current emacs versions, I have been
> looking deeper into the documentation of current emacs and just
> found my answer; starting current emacs with the --unibyte option
> would do. I also looked a bit further - apparently the --unibyte option
> was not available before emacs 20.3, so cemacs.el had indeed been
> broken for about 3 years between 1995 and 1998. As a result, cemacs's
> README contains a warning that it doesn't run under emacs 20+,
> and a later fork+enhancement of it even contains codes for
> version checking and abort under emacs 20+. I'll write
> to the author of cemacs to rectify that.

Emacs-20.1 also had an option to run in unibyte mode, although
it didn't have the --unibyte argument.  etc/NEWS for Emacs-20.1 says:

    [...]

    You can disable multibyte character support as follows:

      (setq-default enable-multibyte-characters nil)

    [....]

Note that Emacs-20.1 and 20.2 turned out to have many problems,
so very few people are still using them (much fewer than 20.3
or 19.34).


        Stefan