Re: 23.0.60; Cannot isearch for non-ascii chars with emacs -nw -Q

[Stefan Monnier <monnier@iro.umontreal.ca>]

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