Re: a few MULE criticisms

[Hin-Tak Leung <hintak_leung@yahoo.co.uk>]

Jason Rumney wrote:
> Hin-Tak Leung <hintak_leung@yahoo.co.uk> 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.
>

No, the first two aren't really new methods; they are ways of displaying
alternatives, anticipating and asking the user which of the alternatives he
might like, based on (1) what he had just inserted in the current buffer,
or (2) explicit user-initiated regular-expression matches within the current
input method. But both of them addresses the problem that the user may not
know or remember the precise key-strokes for invoking the desired input.

(1) certainly needs big dictionaries, for each locale. Continuing my
examples, to anticipate that the user may want "for", "engine" or
"through" after he had inputted the word "search", because "search for",
"search through", "search engine" are commonly used phrases.

(2) is probably more like an enhancement or change in
window/buffer management. At  the moment, under MULE, if I don't know
the exact input key-strokes for a particular character, there is very
little chance of arriving at the result.

It is probably a bit like a "spell-checker" within the current input method:
e.g. I vaguely know the character I want needs "pronou*", and the ability
to type 'pronou*ion' or 'pronou?" and get emacs to suggest to me that
it could be "pronoun", "pronounciation", etc. It doesn't require a
dictionary (unlike this English example), but it requires
(a) some standards of specifying wild cards, (b) being able
to scan the current input method table for matches, (c) and displaying
the list of matches from the current input method for me to
choose from. So it requires some kind of searching mechanism within
the current input method, and a way of displaying an axcilliary buffer
with an enumerated list of all such matches in it, and some glue
between this buffer and the main buffer.