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

[Jason Rumney]

Hin-Tak Leung <address@hidden> writes:

Your first two comments look like they could be handled by writing new
input methods. Because they are likely to require big dictionaries,
they don't necessarily have to be bundled with Emacs. They could exist
as an external package just as cemacs does now, but taking advantage
of the leim framework that is in place now.

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

There is no reason why you can't add new input methods to your
site-lisp directory, I think.

As for minor personal modifications to existing input methods,
abbrev-mode provides functionality in this direction already. If it
is not good enough, maybe it could be tied in more closely with
leim/quail somehow.

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

You'd have to initially read in the buffer as binary, and do the
en/decoding conversion into an indirect buffer. I think Gnus already
does something similar to handle multiple text parts in MIME messages
with different encodings.

> it is more like the MULE developers think they know my needs better
> than I do, and insist that I do things their way.

The usual case is that files are saved in a single encoding. The MULE
developers have done a very good job of making that work, but I doubt
they have encountered this use-case before outside of Gnus, or there
would already be a way to handle it.

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

As Stefan replied in gnu.emacs.bug, this exact change was made almost
two years ago, so if there are bugs remaining in the current release,
there must be something wrong with the way the change was made that
makes it ineffective for you.  Can you confirm that you still need to
make this change yourself in 21.3 or the latest CVS?