From: Kenichi Handa <handa@m17n.org>
Cc: Peter_Dyballa@Web.DE, emacs-pretest-bug@gnu.org, emacs-devel@gnu.org
Subject: Re: Can't isearch 'ö'
Date: Mon, 25 Apr 2005 15:32:04 +0900 (JST) [thread overview]
Message-ID: <200504250632.PAA09312@etlken.m17n.org> (raw)
In-Reply-To: <87k6n05jo7.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Mon, 18 Apr 2005 08:59:39 -0400)
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
next prev parent reply other threads:[~2005-04-25 6:32 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ea747b3b2d97aa98d6f831fd50b24adf@Web.DE>
[not found] ` <m18y3qitbv.fsf-monnier+emacs@gnu.org>
[not found] ` <296c27822efac3bf0271bf82f19ca485@Web.DE>
[not found] ` <m1r7hih67o.fsf-monnier+emacs@gnu.org>
[not found] ` <606b3ca39653eb6a62837e841402d5c8@Web.DE>
[not found] ` <87fyxtxwku.fsf-monnier+emacs@gnu.org>
2005-04-14 23:42 ` Can't isearch 'ö' Kenichi Handa
2005-04-15 12:36 ` Stefan Monnier
2005-04-18 2:52 ` Kenichi Handa
2005-04-18 3:27 ` Stefan Monnier
2005-04-18 5:16 ` Kenichi Handa
2005-04-18 12:59 ` Stefan Monnier
2005-04-25 6:32 ` Kenichi Handa [this message]
2005-04-26 10:06 ` Richard Stallman
2005-04-28 11:31 ` Kenichi Handa
2005-04-29 10:15 ` Richard Stallman
2005-04-30 2:25 ` Luc Teirlinck
2005-05-01 20:33 ` Stefan Monnier
2005-05-02 0:29 ` Kenichi Handa
2005-04-18 21:05 ` Richard Stallman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200504250632.PAA09312@etlken.m17n.org \
--to=handa@m17n.org \
--cc=Peter_Dyballa@Web.DE \
--cc=emacs-devel@gnu.org \
--cc=emacs-pretest-bug@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).