[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Can't isearch 'ö'
From: |
Kenichi Handa |
Subject: |
Re: Can't isearch 'ö' |
Date: |
Mon, 25 Apr 2005 15:32:04 +0900 (JST) |
User-agent: |
SEMI/1.14.3 (Ushinoya) FLIM/1.14.2 (Yagi-Nishiguchi) APEL/10.2 Emacs/22.0.50 (sparc-sun-solaris2.6) MULE/5.0 (SAKAKI) |
In article <address@hidden>, Stefan Monnier <address@hidden> 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 <address@hidden> 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
address@hidden
- Re: Can't isearch 'ö', Kenichi Handa, 2005/04/14
- Re: Can't isearch 'ö', Stefan Monnier, 2005/04/15
- Re: Can't isearch 'ö', Kenichi Handa, 2005/04/17
- Re: Can't isearch 'ö', Stefan Monnier, 2005/04/17
- Re: Can't isearch 'ö', Kenichi Handa, 2005/04/18
- Re: Can't isearch 'ö', Stefan Monnier, 2005/04/18
- Re: Can't isearch 'ö',
Kenichi Handa <=
- Re: Can't isearch 'ö', Richard Stallman, 2005/04/26
- Re: Can't isearch 'ö', Kenichi Handa, 2005/04/28
- Re: Can't isearch 'ö', Richard Stallman, 2005/04/29
- Re: Re: Can't isearch 'ö', Richard Stallman, 2005/04/18