unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Logan Perkins <logan@lp-programming.com>
Cc: 39687@debbugs.gnu.org
Subject: bug#39687: 26.3; Add customize-variable option for not locking keyboards
Date: Fri, 21 Feb 2020 10:23:14 +0200	[thread overview]
Message-ID: <83mu9cjqml.fsf@gnu.org> (raw)
In-Reply-To: <3a518d18-cc99-195b-42a9-adc8ef764d67@lp-programming.com> (message from Logan Perkins on Wed, 19 Feb 2020 21:01:30 -0800)

> From: Logan Perkins <logan@lp-programming.com>
> Date: Wed, 19 Feb 2020 21:01:30 -0800
> 
> Is there some further reason to lock the keyboard that I haven't
> considered?

Can we back up a little, and discuss the use cases where the current
behavior presents a limitation?  Is quitting in the other clients the
only one, or are there more?

Also, are you implicitly saying that several persons work
simultaneously vis-à-vis the same Emacs server?  Because if not, I'm
not sure I understand how simultaneous need to input from different
clients could even happen.

> Should I make the behavior depend on some elisp function? I think that
> might be the easiest way to support the "minibuffer in use" message and
> the like, but I'm not sure what the downside would be.
> 
> Is it a waste of time for me to submit patches related to this feature?
> If there's zero interest in adding this, or it would be less work for
> someone else to write it than review my patches, I won't waste your time
> sending them.

Speaking for myself, I think the interest depends on the relevant use
cases where the current behavior implies restrictions.  Thus my
questions above.

In any case, we thank you for your interest in Emacs and look forward
to seeing your contributions, but I suggest to start your legal
paperwork rolling now, because changes you are talking about will
probably be non-trivial in length, so we will need a copyright
assignment from you in order to accept the changes.  If you agree, I
can send you the form to fill and the instructions to go with it.





  reply	other threads:[~2020-02-21  8:23 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-20  5:01 bug#39687: 26.3; Add customize-variable option for not locking keyboards Logan Perkins
2020-02-21  8:23 ` Eli Zaretskii [this message]
     [not found]   ` <32ea14fb-1ab8-186e-2534-4d3d2a56d6d8@lp-programming.com>
2020-02-22  9:27     ` Eli Zaretskii
2020-02-22 18:00       ` Logan Perkins
2020-05-19  1:15       ` Logan Perkins
2020-10-01 18:44         ` Lars Ingebrigtsen
2020-10-01 19:23           ` Eli Zaretskii
2021-07-21 15:57         ` Lars Ingebrigtsen
2021-07-21 17:52           ` Logan Perkins
2021-07-21 19:52             ` Eli Zaretskii
2021-07-21 22:08             ` Lars Ingebrigtsen
2021-07-21 22:44               ` Logan Perkins
2021-07-22 12:05                 ` Lars Ingebrigtsen

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=83mu9cjqml.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=39687@debbugs.gnu.org \
    --cc=logan@lp-programming.com \
    /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).