[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

  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

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

Ken'ichi HANDA

reply via email to

[Prev in Thread] Current Thread [Next in Thread]