[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: 23.0.60; Cannot isearch for non-ascii chars with emacs -nw -Q
From: |
Stefan Monnier |
Subject: |
Re: 23.0.60; Cannot isearch for non-ascii chars with emacs -nw -Q |
Date: |
Wed, 27 Feb 2008 23:05:54 -0500 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
>> > It seems that something is broken in isearch-x.el (although
>> > unicode merge didn't change it). I'm now investigating.
> I found that when isearch-printing-char is called,
> last-command-char is already what decoded by
> encoded-kbd-mode.
That's good, right?
> But, when I wrote isearch-x.el, last-command-char was the first byte
> of utf-8 sequence. So, isearch-x.el pushed back that byte in
> unread-command-events and re-read the whole utf-8 sequence.
I see your patch doesn't remove this use of unread-command-events.
Is it still needed?
>> Now that we've moved the keyboard decoding to input-event-map,
> Ah! Is that the change I wrote above?
I don't see why that change would have such an effect.
Actually, it seems that this "new" behavior is already present in the 22
branch, maybe even in Emacs-22.1.
So it looks like the
(if (and enable-multibyte-characters
(>= char ?\200)
(<= char ?\377))
test has been harmful for a while, but in the non-unicode branch, the
o200-o377 range was never matched by "untranslated" data, whereas in the
unicode branch these are now perfectly valid latin-1 chars.
>> I'm not sure what would be the benefit. Of course, if we
>> can just reuse C code and get rid of the encoded-kbd code,
>> that's good.
> Yes. I think it can be done by adding less than 100 lines
> of C code (mostly for handling meta-key) in
> tty_read_avail_input and removing most of encoded-kb.el (we
> still need the code of calling set-input-mode property).
Might worth trying,
Stefan
Re: 23.0.60; Cannot isearch for non-ascii chars with emacs -nw -Q, Tassilo Horn, 2008/02/27