In article <[EMAIL PROTECTED]>, Stefan Monnier <[EMAIL PROTECTED]> writes:
>> The very right way is to shift to emacs-unicode. As long as
>> we have multiple character codes for characters that user
>> don't want to distinguish, any fix is just a dirty work
>> around.
> I'm not sure about "workaround" but it'll only ever be a heuristic.
The current heuristic about translation-table-for-input is
that:
We translate a character to what matches
buffer-file-coding-system of a buffer to which a user is
going to insert that character.
But you are going to extend that heuristic to:
We translate a character event to what matches
buffer-file-coding-system of the current buffer
(regardless of how the character is going to be used).
I basically agree that such an extension is good considering
the current limitation of non-unicode Emacs. But, as we are
in the stage of feature freeze, I think we should not do
that unless there's no other way to fix a problem.
And, for the current case, we do have another solution;
fixing ispell.el.
> Within the constraints of the non-unicode Emacs, it seems to be The Right
> Way in that it's a heuristic that fixes all the places where we've already
> had to introduce a fix, and I can't think of a place where it's going to
> break something.
With your change, what (read-char) returns will be different
depending on buffer-file-coding-system. I don't know a
single actual example, but one may bind a non-ASCII
character to some command, or one may have his own input
method that does something about typed non-ASCII character.
Your change may break such cases.
> I.e. it's a much better heuristic than the one we
> currently have. Also it allows us to remove the heuristic code (in quail
> and self-insert-command, and soon in isearch) we've added at various other
> places, so it cleans up the code a bit. Since that code is not necessary in
> Emacs-unicode, it ends up bringing the two closer which I think is a good
> thing as well. I.e. it just feels Right.
I don't oppose to that.
Richard Stallman <[EMAIL PROTECTED]> writes:
> I didn't know that self-insert-cmmand also uses
> translation-table-for-input. I have thought that the
> variable is for an input method as in this docstring:
> Perhaps the first step is to come up with a clearer statement of what
> its job should be. From that, we should be able to decide easily
> where it should or should not be used.
At least the current statement is clear that it should not
be used for translating in read-char.
Char table for translating self-inserting characters.
This is applied to the result of input methods, not their input. See also
^^^^^^^^^^^^^^^
`keyboard-translate-table'.
Anyway, as far as I know, we are now discussing "what its
job should be".
We (me and Stefan) has already shown opinions and solutions
to the problem. Richard, could you please decide what to
do?
---
Ken'ichi HANDA
[EMAIL PROTECTED]
_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel
