From: Ryan Johnson <ryanjohn@ece.cmu.edu>
To: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: Best way to intercept terminal escape sequences?
Date: Fri, 27 Aug 2010 20:04:48 +0200 [thread overview]
Message-ID: <4C77FE40.6090207@ece.cmu.edu> (raw)
In-Reply-To: <834oegm5c3.fsf@gnu.org>
On 8/27/2010 5:40 PM, Eli Zaretskii wrote:
>> Date: Fri, 27 Aug 2010 16:44:12 +0200
>> From: Ryan Johnson<ryanjohn@ece.cmu.edu>
>>
>> Is there really no other way to do this?
> You could use the :post-read-conversion attribute of a coding-system.
> That is, define a new coding-system that has this attribute specifying
> a function you will write. That function will first decode the mouse
> stuff, and then decode the rest by the terminal-coding-system set by
> the user.
> You can see an example of this in ctext-with-extensions. It is
> defined on mule-conf.el and its post-read-conversion function is
> defined on mule.el.
That's actually what I tried first, but as I mentioned in the OP, emacs
doesn't always deliver characters to :post-read-conversion in the
correct order, which makes it impossible to do anything reliable with
either escape sequences or utf-8. See
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=6920 for more details.
The other problem is, I need to convert escape sequences into mouse
events, not characters. Even if the bug were fixed, and even if it were
easy to detect the user's desired coding system and piggy-back on it
reliably, there's a problem with event ordering. I can't put a mouse
event in the buffer, so if I'm ever given text and mouse-escape-sequence
I'd have to leave the buffer empty, then load up unread-command-events
with both text and mouse events. I'm not sure where those rejoin the
input processing chain, but even with (t . EVT) I suspect they skip
something (input methods, perhaps?). Also, I had some trouble getting (t
. EVT) to work from within :post-read-conversion, though that could just
be a bug in my code.
> Other than that, it's no surprise that this is not easy: we ask Emacs
> to read keyboard input that is encoded in two different encodings,
> which is not how keyboard input was designed.
Not quite... emacs insists on interpreting everything as encoded in some
way, and I'd really like to just get my hands on a few raw bytes before
it does so.
> I think the only way that is easier and cleaner would be if Emacs
> could read the mouse input from a separate file descriptor. We could
> then set that file descriptor to use a different encoding. Of course,
> that would need low-level changes in Emacs, even if it is possible in
> xterm.
What I had in mind was simpler:
Right now we have input -> coding system -> input method -> read-char ->
input-decode-map -> ... other keymaps galore ... -> read-key
read-key is nice because it comes after all the interpretation is
complete (high-level). Read-char is nice for interpreting key sequences
(e.g. if you're a key map, mid-level), and it makes perfect sense to
apply coding systems first. However, for things like escape sequences
(very low-level), which are raw bytes with a specific meaning regardless
of locale (and even keyboard layout, for xterm), coding systems are
unnecessary at best and harmful at worst.
I'd propose adding an input filtering mechanism, which allows to
register functions which pick off the raw input and are expected to put
back anything they doesn't need. Sort of like a coding system, but
orthogonal. Then you'd have:
input -> input-filter(s) -> coding system -> input method -> read-char
-> input-decode-map -> ... other keymaps galore ... -> read-key
That said, if coding systems can really be abused as you suggest, and
the ordering bug could be fixed, and unread-command-events does the
right thing, then that would have the same effect and I'd be happy to
use it. If just seems like taking the long way around.
Ryan
next prev parent reply other threads:[~2010-08-27 18:04 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20100827142724.E1DD712F@hazard.ece.cmu.edu>
2010-08-27 14:44 ` Best way to intercept terminal escape sequences? Ryan Johnson
2010-08-27 15:40 ` Eli Zaretskii
2010-08-27 18:04 ` Ryan Johnson [this message]
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
2010-09-04 13:01 ` Improve input handling documentation (was Re: Best way to intercept terminal escape sequences?) Štěpán Němec
[not found] ` <jwvy6bfdp23.fsf-monnier+emacs@gnu.org>
2010-09-07 0:32 ` Best way to intercept terminal escape sequences? 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
2010-08-26 15:58 Ryan Johnson
2010-08-26 23:03 ` Stefan Monnier
2010-08-27 9:28 ` Ryan Johnson
2010-08-27 10:36 ` David Kastrup
2010-08-27 23:50 ` Stefan Monnier
-- 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=4C77FE40.6090207@ece.cmu.edu \
--to=ryanjohn@ece.cmu.edu \
--cc=eliz@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.