GNU bug report logs - #23009
25.0.92; xterm-mouse-mode should not assume UTF-8 coordinates

Previous Next

Full log

Message #17 received at 23009 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: 23009 <at> debbugs.gnu.org
Subject: Re: bug#23009: 25.0.92;
 xterm-mouse-mode should not assume UTF-8 coordinates
Date: Tue, 15 Mar 2016 19:57:06 +0200

> From: Philipp Stephani <p.stephani2 <at> gmail.com>
> Date: Mon, 14 Mar 2016 23:03:21 +0000
> Cc: 23009 <at> debbugs.gnu.org
> 
> Added a patch. I've had to use latin-1 instead of no-conversion to prevent resetting the meta mode. 

Not sure I understand the problem you had with no-conversion.  Can you
elaborate?

> --- a/lisp/international/mule.el
> +++ b/lisp/international/mule.el
> @@ -1484,6 +1484,9 @@ set-keyboard-coding-system
>    (set-keyboard-coding-system-internal coding-system terminal)
>    (setq keyboard-coding-system coding-system))
>  
> +(gv-define-setter keyboard-coding-system (coding-system &optional terminal)
> +  `(set-keyboard-coding-system ,coding-system ,terminal))

I don't think you can do that: mule.el is preloaded, while gv.el
isn't.

It isn't a catastrophe to temporarily switch keyboard encoding "the
dull way".

> +               ;; Use Latin-1 instead of no-conversion to avoid
> +               ;; flicker due to `set-keyboard-coding-system' changing
> +               ;; the meta mode.

Ah, so that's the problem...  Did you try raw-text instead?

And anyway, doesn't latin-1 give you trouble for bytes in the 128..159
range?

Other than that, I have no comments.  Let's wait for a few days to
give others time to chime in, if they want to.

Thanks.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.