unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
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




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