Re: Can't isearch 'ö'

[Kenichi Handa]

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