From: David Kastrup <dak@gnu.org>
To: emacs-devel@gnu.org
Subject: Re: Best way to intercept terminal escape sequences?
Date: Fri, 27 Aug 2010 12:36:52 +0200 [thread overview]
Message-ID: <87tymg8hq3.fsf@lola.goethe.zz> (raw)
In-Reply-To: 4C778535.9020206@ece.cmu.edu
Ryan Johnson <ryanjohn@ece.cmu.edu> writes:
> On 8/27/2010 1:03 AM, Stefan Monnier wrote:
>>> all encoded events of some sort. For example, the xterm escape sequence
>>> "ESC O D" is eventually converted to<right>, but anybody calling
>>> read-char or read-event will get a string of characters instead (and
>>> probably wish they hadn't).
>> Yes, that's why they should use `read-key' instead.
> !!
>
> I didn't know about that function. I tried s/read-event/read-char/ in
> mouse.el, and nothing obvious broke. However, I'll need to modify
> xt-mouse.el to take advantage of the change -- it still doesn't trust
> mouse.el.
>
> Meanwhile, though, I'm hitting another problem which still seems to
> require a lower-than-low-level equivalent for read-char which can
> bypass coding systems.
>
> For reasons I don't understand, xterm's mouse escape sequence is
> completely non-standard: "ESC [ M pb px py". The p* are bytes taking
> values between 33 and 255, and there is no terminator byte.***
>
> The result of this unfortunate design decision is that px and py can
> throw a huge wrench in emacs' utf-8 decoding, because a (px py) pair
> can look like all kinds of utf-8 (valid or otherwise). As long as px <
> 0xe0 *and* py< 0xC0 I can reliably decompose the unicode char I'm
> given into the original utf-8 sequence (possibly in the illegal C0 or
> C1 range) and py follows immediately to satisfy the decoder. The rest
> of the time, though, the lack of a sequence terminator leaves me at
> the decoder's mercy to decide how to interpret the bytes, and it's at
> the mercy of whatever input follows the mouse sequence.
>
> I tried setting the keyboard-coding-system to iso-latin-1, but no
> luck.
You should set it to raw-text, do your mouse code preprocessing, and
afterwards decode the remainder using the intended coding system.
--
David Kastrup
next prev parent reply other threads:[~2010-08-27 10:36 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-26 15:58 Best way to intercept terminal escape sequences? Ryan Johnson
2010-08-26 23:03 ` Stefan Monnier
2010-08-27 9:28 ` Ryan Johnson
2010-08-27 10:36 ` David Kastrup [this message]
2010-08-27 23:50 ` Stefan Monnier
[not found] <20100827142724.E1DD712F@hazard.ece.cmu.edu>
2010-08-27 14:44 ` Ryan Johnson
2010-08-27 15:40 ` Eli Zaretskii
2010-08-27 18:04 ` Ryan Johnson
2010-08-27 20:38 ` Eli Zaretskii
2010-08-27 23:54 ` Stefan Monnier
2010-08-28 7:54 ` Ryan Johnson
2010-08-28 14:47 ` Stefan Monnier
2010-08-28 20:34 ` Ryan Johnson
2010-08-31 23:12 ` Ryan Johnson
2010-09-02 10:53 ` Stefan Monnier
2010-09-02 12:33 ` Ryan Johnson
[not found] ` <jwvy6bfdp23.fsf-monnier+emacs@gnu.org>
2010-09-07 0:32 ` Kenichi Handa
2010-09-08 9:05 ` Stefan Monnier
[not found] <20100827112348.5023B3D5@osgood.ece.cmu.edu>
2010-08-27 13:56 ` Ryan Johnson
2010-08-27 14:17 ` David Kastrup
-- strict thread matches above, loose matches on Subject: below --
2010-08-26 13:22 Ryan Johnson
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87tymg8hq3.fsf@lola.goethe.zz \
--to=dak@gnu.org \
--cc=emacs-devel@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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.