Re: Additional cleanup around xterm-mouse - Jared Finder via Emacs development discussions.

unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed

From: Jared Finder via "Emacs development discussions." <emacs-devel@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Additional cleanup around xterm-mouse
Date: Tue, 15 Dec 2020 21:30:24 -0800	[thread overview]
Message-ID: <ba8bd6041d5668de028872bf6c576f4f@finder.org> (raw)
In-Reply-To: <83ft48csj5.fsf@gnu.org>

On 2020-12-14 7:32 am, Eli Zaretskii wrote:
>> Date: Sun, 13 Dec 2020 16:54:26 -0800
>> From: Jared Finder <jared@finder.org>
>> Cc: "Jared Finder via \"Emacs development discussions.\""
>>  <emacs-devel@gnu.org>, Eli Zaretskii <eliz@gnu.org>
>> 
>> Any updates here?
>> 
>> I do not know what the etiquette is here in terms of replies, so I'd
>> like to apologize in advance if I'm just being impatient.
> 
> FWIW, I was waiting for Stefan to react to your responses.

It seems Stefan is very busy right now.  Would you be okay deferring the 
issues Stefan raised?  Or would you prefer to just wait?

My impression is that his concern is around if it makes sense to add a 
new parameter to read-key and if inhibit--unbound-mouse-fallback should 
instead be done through function-key-map (avoiding adding a new var).  
But these can both be avoided:

1. I can just not add a new parameter to read-key. I only did this so 
that external packages had a solution that didn't involve 
inhibit--unbound-mouse-fallback or read-potential-mouse-event.

2. Since inhibit--unbound-mouse-fallback is internal (both in doc 
comment and in its name), it can safely be removed in the future.

With the above done, if you / Stefan want to instead make this work via 
function-key-map and not add a parameter to read-key, that can be done 
while safely removing inhibit--unbound-mouse-fallback.

Thoughts?  I'm okay either way.

   -- MJF

next prev parent reply other threads:[~2020-12-16 5:30 UTC|newest]

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=ba8bd6041d5668de028872bf6c576f4f@finder.org \
    --to=emacs-devel@gnu.org \
    --cc=eliz@gnu.org \
    --cc=jared@finder.org \
    --cc=monnier@iro.umontreal.ca \
    /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).