Re: Can't isearch 'ö'

Re: Can't isearch 'ö'

[Kenichi Handa]

In article <87fyxtxwku.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Hmm... indeed the translation-table-for-input is not used for X11 keys.
> Now that I look at it a bit more, I think the patch below would make sense.
> What do other people think?

That doesn't work in some case.  The value of
translation-table-for-input can be different in each buffer
(depending of buffer-file-coding-system of a buffer).

The translation should be done where we are sure about the
target buffer; for instance, in isearch-printing-char.

---
Ken'ichi HANDA
handa@m17n.org

Re: Can't isearch 'ö'

[Stefan Monnier]

>> Hmm... indeed the translation-table-for-input is not used for X11 keys.
>> Now that I look at it a bit more, I think the patch below would make sense.
>> What do other people think?

> That doesn't work in some case.  The value of
> translation-table-for-input can be different in each buffer
> (depending of buffer-file-coding-system of a buffer).

Of course, that's why we can't do directly it in the
xkeysym->char conversion.  But it seems like doing it in read-char
should work.  Can you show me an existing piece of code where it wouldn't
work right?  Hypothetical examples aren't too interesting since we can also
concoct such examples where the current "translate in
self-insert-command" can be made to fail.


        Stefan

Re: Can't isearch 'ö'

[Kenichi Handa]

In article <87br8g2pe0.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>>  Hmm... indeed the translation-table-for-input is not used for X11 keys.
>>>  Now that I look at it a bit more, I think the patch below would make sense.
>>>  What do other people think?

>>  That doesn't work in some case.  The value of
>>  translation-table-for-input can be different in each buffer
>>  (depending of buffer-file-coding-system of a buffer).

> Of course, that's why we can't do directly it in the
> xkeysym-> char conversion.  But it seems like doing it in read-char
> should work.

I don't know the diffence between them because even
read-char doesn't know how a caller will treat the returned
character.

> Can you show me an existing piece of code where it wouldn't
> work right?

No, I can't.  But shouldn't we avoid such an incompatible
change at this stage?

> Hypothetical examples aren't too interesting since we can also
> concoct such examples where the current "translate in
> self-insert-command" can be made to fail.

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:

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, could you show me such an example?

---
Ken'ichi HANDA
handa@m17n.org

Re: Can't isearch 'ö'

[Stefan Monnier]

> No, I can't.  But shouldn't we avoid such an incompatible
> change at this stage?

Can be.  But since it's about a year now since we called a freeze and I see
no sign of getting to the pretest stage, I figure I don't understand enough
what "feature freeze" means: I just propose changes and I'll let someone
else decide whether they should be installed.
I think it's The Right Way to solve the problem, so that's what I use in my
local code, but if someone wants to write a "quick&safe" fix instead and use
that instead I see no problem with it.  I'm still interested to know whether
I'm right or not in thinking that my fix is The Right Way.

>> Hypothetical examples aren't too interesting since we can also
>> concoct such examples where the current "translate in
>> self-insert-command" can be made to fail.

> I didn't know that self-insert-command also uses
> translation-table-for-input.  I have thought that the
> variable is for an input method as in this docstring:

> 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, could you show me such an example?

Let's see:

      (insert (with-current-buffer foo
                (buffer-substring (point)
                                  (progn
                                    (call-interactively 'self-insert-command)
                                    (point)))))

Yes, it's silly,


        Stefan

Re: Can't isearch 'ö'

[Kenichi Handa]

In article <877jj07owm.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> writes:

>>  No, I can't.  But shouldn't we avoid such an incompatible
>>  change at this stage?

> Can be.  But since it's about a year now since we called a freeze and I see
> no sign of getting to the pretest stage, I figure I don't understand enough
> what "feature freeze" means: I just propose changes and I'll let someone
> else decide whether they should be installed.
> I think it's The Right Way to solve the problem, so that's what I use in my
> local code, but if someone wants to write a "quick&safe" fix instead and use
> that instead I see no problem with it.  I'm still interested to know whether
> I'm right or not in thinking that my fix is The Right Way.

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.   And, for the current case, I think the quick&safe
work around is something like attached.

Your patch may fix not only the current case but also the
other cases, but may break some case.  My patch fix only the
current case and won't break the other case.


>>>  Hypothetical examples aren't too interesting since we can also
>>>  concoct such examples where the current "translate in
>>>  self-insert-command" can be made to fail.

>>  I didn't know that self-insert-command also uses
>>  translation-table-for-input.  I have thought that the
>>  variable is for an input method as in this docstring:

>>  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, could you show me such an example?

> Let's see:

>       (insert (with-current-buffer foo
>                 (buffer-substring (point)
>                                   (progn
>                                     (call-interactively 'self-insert-command)
>                                     (point)))))

> Yes, it's silly,

As it's too silly, we can't guess what is the right
behaviour.  Perhaps, the reason for using "foo" buffer is
that the author wanted to translate a character in that
buffer, then, the above does what expected.

---
Ken'ichi HANDA
handa@m17n.org

*** isearch.el	21 Mar 2005 11:32:26 +0900	1.261
--- isearch.el	18 Apr 2005 13:34:38 +0900	
***************
*** 1805,1810 ****
--- 1805,1812 ----
  
  (defun isearch-process-search-char (char)
    ;; Append the char to the search string, update the message and re-search.
+   (if (char-table-p translation-table-for-input)
+       (setq char (or (aref translation-table-for-input char) char)))
    (isearch-process-search-string
     (char-to-string char)
     (if (>= char ?\200)

Re: Can't isearch 'ö'

[Stefan Monnier]

> 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.

> Your patch may fix not only the current case but also the
> other cases, but may break some case.  My patch fix only the
> current case and won't break the other case.

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.  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.


        Stefan

Re: Re: Can't isearch 'ö'

[Richard Stallman]

    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.

Re: Can't isearch 'ö'

[Kenichi Handa]

In article <87k6n05jo7.fsf-monnier+emacs@gnu.org>, Stefan Monnier <monnier@iro.umontreal.ca> 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 <rms@gnu.org> 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
handa@m17n.org

Re: Can't isearch 'ö'

[Richard Stallman]

    We (me and Stefan) has already shown opinions and solutions
    to the problem.  Richard, could you please decide what to
    do?

I have not been reading these messages, because they were numerous and
long.  Now that there are two proposals, would you please show me the
two proposals, each described clearly from scratch in one message?

Re: Can't isearch 'ö'

[Kenichi Handa]

In article <E1DQMxC-0001xK-Le@fencepost.gnu.org>, Richard Stallman <rms@gnu.org> writes:

>     We (me and Stefan) has already shown opinions and solutions
>     to the problem.  Richard, could you please decide what to
>     do?

> I have not been reading these messages, because they were numerous and
> long.  Now that there are two proposals, would you please show me the
> two proposals, each described clearly from scratch in one message?

The original problem was that when a user have `ö' of
iso-8859-15 in a buffer of iso-8859-15 coding system, he
can't isearch that character by typing `ö' on his keyboard
because that key is recognized as `ö' of iso-8859-1.

Stefan's proposal is to translate a character by
translation-table-for-input in read_char ().  This is a
generic solution, but it makes read_char () return different
character depending on the buffer-file-coding-system of the
current buffer, which may or may not cause anther problem.

My proposal is to translate a character by
translate-table-for-input in isearch-process-search-char.
This is a limitted solution only for the current problem.

---
Ken'ichi HANDA
handa@m17n.org

Re: Can't isearch 'ö'

[Richard Stallman]

    Stefan's proposal is to translate a character by
    translation-table-for-input in read_char ().  This is a
    generic solution, but it makes read_char () return different
    character depending on the buffer-file-coding-system of the
    current buffer, which may or may not cause anther problem.

    My proposal is to translate a character by
    translate-table-for-input in isearch-process-search-char.
    This is a limitted solution only for the current problem.

Suppose we use the latter solution.  We probably would want to use it
in other places as well, but which ones?  Can you suggest a rule for
programmers to decide whether to translate the result from read-char
thru translate-table-for-input, and when not to?

Could you look thru the calls to read-char in Emacs, and see which
ones clearly should do this translation, which ones clearly should
not, and which ones would work right either with or without the
translation?

Re: Can't isearch 'ö'

[Luc Teirlinck]

There is something that has not been pointed out in the summary Handa
gave, but which I believe may be relevant.  If I understood correctly,
the problem in question will automatically completely disappear with
Unicode and hence with Emacs 23.  (Unless I misunderstood.)

Sincerely,

Luc.

Re: Can't isearch 'ö'

[Stefan Monnier]

> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant.  If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicode and hence with Emacs 23.  (Unless I misunderstood.)

Indeed,


        Stefan

Re: Can't isearch 'ö'

[Kenichi Handa]

In article <200504300225.j3U2P9M18132@raven.dms.auburn.edu>, Luc Teirlinck <teirllm@dms.auburn.edu> writes:

> There is something that has not been pointed out in the summary Handa
> gave, but which I believe may be relevant.  If I understood correctly,
> the problem in question will automatically completely disappear with
> Unicode and hence with Emacs 23.

Yes.

---
Ken'ichi HANDA
handa@m17n.org