From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Jared Finder <jared@finder.org>
Cc: "jared--- via \"Emacs development discussions.\"" <emacs-devel@gnu.org>
Subject: Re: Additional xterm-mouse cleanup
Date: Wed, 24 Feb 2021 22:56:31 -0500 [thread overview]
Message-ID: <jwv4ki0kdzu.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <3e616ab0b40a4141c8688e9cdc95cdfc@finder.org> (Jared Finder's message of "Wed, 03 Feb 2021 22:54:10 -0800")
Sorry for not answering earlier.
> Ah, got it. I agree, it is mostly straightforward. To do this properly
> required making an assumption that .timestamp=0 for SELECT_WINDOW_EVENT is
> ok. Looking through the C code, I don't see any location that reads
> .timestamp for the SELECT_WINDOW_EVENT, so I make it uniformly
> 0 throughout. Updated patch attached.
Looks good to me.
>>>> [ Oh ... how I hate that echo area code. ]
>> I have the impression that a whole lot of code can run between the
>> `clear_message` and your code, so I don't immediately see why we can be
>> sure that `echo_area_buffer[1]` indeed always contains the thing before
>> the `clear_message`. And if it doesn't, then maybe we shouldn't try to
>> revert the echo message.
>
> Good point. I will update my patch to have a copy of the echo area made
> inside read_key_sequence.
I don't see this in your patch, so I assume it'll be in a subsequent patch.
>> I agree it doesn't seem easy, but in my experience "do and later undo"
>> sooner or later leads to extra difficulties so I tend to prefer "delay
>> the do until we're sure we want to perform it".
> I completely agree with the sentiment, but I do not think it is the right
> tradeoff. To delay until we're sure, we'd need to have some sort of
> assumption of how terminal escape sequences are received that normal humans
> would never do. Consider that the following key sequence is a mouse movement
> escape sequence but is completely possible for a human to type slowly:
>
> ESC [ < 3 5 ; 1 9 ; 3 4 m
>
> What should the echo area display if it has read "ESC ["? At this point,
> input-decode-map still doesn't know if this is a xterm escape sequence or
> not.
Right, so indeed the best we can do is to record the clear in such a way
that we can undo it as faithfully as possible. This also begs the question
of what I mean by "*the* clear" since there's presumably going to be one
clear per byte in the above sequence.
> Or to use a metaphor: this feels like you're asking for heart bypass surgery
> before putting a bandage over a cut on Mr. Echo Area's elbow.
Actually, I suspect it's worse than bypass surgery, because it requires
an oracle.
Stefan
next prev parent reply other threads:[~2021-02-25 3:56 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-28 6:32 Additional xterm-mouse cleanup jared--- via Emacs development discussions.
2021-01-28 14:25 ` Stefan Monnier
2021-02-02 8:24 ` jared--- via Emacs development discussions.
2021-02-02 14:37 ` Stefan Monnier
2021-02-04 6:54 ` jared--- via Emacs development discussions.
2021-02-15 1:02 ` Jared Finder via Emacs development discussions.
2021-02-25 3:56 ` Stefan Monnier [this message]
2021-02-25 6:08 ` Jared Finder via Emacs development discussions.
2021-02-25 13:52 ` Stefan Monnier
2021-01-30 9:38 ` Eli Zaretskii
2021-02-02 8:28 ` jared--- via Emacs development discussions.
2021-02-02 15:08 ` Eli Zaretskii
2021-02-04 6:57 ` jared--- via Emacs development discussions.
2021-02-04 15:04 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwv4ki0kdzu.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=emacs-devel@gnu.org \
--cc=jared@finder.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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).