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

[Hin-Tak Leung]

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.

(1) Associations: the ability to let the user choose the next possible
associated characters. In English, "Search" is often followed by "engine"
"for" or "through". In Chinese, When I type "Leung" (not in common sentence 
vocabulary, but it is a common surname), it is almost certain that I would
follow with the rest of my name. Another example in Chinese, the simplest
one character word "one", is often followed by a few specific characters
to make up small compound units which means "definitely", "a few",
"all", "generally", "once", "unified", "together", "one sided", etc. It
saves a lot of typing by a factor or 2 or 3 in Chinese - It is 3 letters
(for "Leung") then "1" (for choice), instead of the 3+5+4 for the
shortest method (ChangJie). The input of many common phrases which
would normally requires 10+ key strokes, can be shorten by associations.
The facility is available in localised version of MacOS, in English MacOS's
CJK add-on's (I have used the latter, and seen a Japanese friend using
the former), and available in 3rd party add-ons to English MS Windows
for many years. This would most certainly require extending MULE with
the ability of loading distionaries of commonly used phrases in
various languages. And will make the leim package a lot bigger.

(2) Hints: quite similiar to (1), e.g. sometimes I can't quite
remember the code for "Leung", but vaguely know it is "e*f" in
ChangJie. (it is actually 'eif'). On just about any other systems
(MacOS's CJK extensions, etc), the full list is displayed and it
narrows down as the user types, so the user can select the correct
one visually if he can't remember the exact code. On Cxterm,
one can do 'e?f' or 'e??f' to obtain a list of matches.

(3) new input methods, and per-user input methods: adding new input
mapping methods on a per-user basis and make that the default. I know
this is possible in MULE - but the procedure is not in the obvious places.
There are new methods coming out, e.g. new ones developed in view of
handhelds, which only requires the key-pad numeric keys. And there
are personal per-user needs e.g. I might like an enhanced ChangJie
method, which includes a special short-hand for my own name, to
over-ride the system one.

(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. 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
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.

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.

And lastly, I don't need to keep on porting emacs 19.34 forward anymore -
However, the answer: adding LDFLAGS='-z nocombreloc', should be applied
to current version of emacs's configure to stop it from being broken
by recent change to default 'combreloc' in GNU ld.

I would like to thank everybody for the work on emacs and the other
works from FSF.

-------- Original Message --------
Subject: Re:  Re: emacs-19.34 segfauls when built with Xfree 4.3.0 (glibc 
2.3.x,gcc 3.2)
Date: Wed, 14 May 2003 09:48:09 -0400
From: Richard Stallman <address@hidden>
Reply-To: address@hidden

<snipped>
In contrast,, we might be interested in trying to fix this problem

    I want to use a elisp script called cemacs (for Chinese inputs)
    but unfortunately the inclusion the MULE (Multi-lingual Extension)
    since version 20 has broken it.

if you send a bug report with a precise complete test case.

We are certainly interested in improving MULE.  Could you write to
address@hidden and tell us why specifically MULE is not as good
as cemacs for your usage?