unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Marcin Borkowski <mbork@mbork.pl>
To: Drew Adams <drew.adams@oracle.com>
Cc: "Karl O. Pinc" <kop@meme.com>, Stefan Kangas <stefan@marxist.se>,
	3540@debbugs.gnu.org
Subject: bug#3540: Please reserve a ctrl-key combination for interoperability
Date: Wed, 09 Oct 2019 20:33:03 +0200	[thread overview]
Message-ID: <8736g1epls.fsf@mbork.pl> (raw)
In-Reply-To: <014ff1d6-9e7e-4bdf-88ed-eefc9133353d@default>


On 2019-10-06, at 23:29, Drew Adams <drew.adams@oracle.com> wrote:

>> Actually, that's what I do in my config.  (Is there anyone who actually
>> wants C-z's default binding???)
>
> Dunno.  But I use something very close to it (for GUI).
> It has the same behavior as the default command, unless
> you use a prefix arg:
>
> (defun iconify/show-frame (&optional all-action)
>   "Iconify selected frame if now shown.  Show it if now iconified.
> A non-negative prefix arg iconifies all shown frames.
> A negative prefix arg deiconifies all iconified frames."
>   (interactive "P")
>   (cond ((not all-action)
>          (when rename-frame-when-iconify-flag
>            (rename-non-minibuffer-frame))
>          (iconify-or-deiconify-frame))
>         ((natnump (prefix-numeric-value all-action))
>          (iconify-everything))
>         (t (deiconify-everything)))) ; <== Emacs default
>
> But I'm not arguing to keep the default `C-z' binding.
> I'm really arguing against wasting `C-z' on something
> else, by default.
>
> Someday we'll come across a really important new feature
> that really deserves `C-z' (e.g. as a prefix key).  Keys
> shouldn't be bound by default lightly.  Once a key is
> bound by default it becomes harder to later remove or
> replace its binding.
>
> `C-z' is a wonderful key for general things, including
> use as a prefix key.  (And if not a prefix key then at
> least for a repeatable command.)  And it's as easy to
> reach as `C-x' on most keyboards.
>
> If ever there was a key that I don't think should be
> bound by default willy nilly (aka wasted, in my view),
> it's `C-z'.

I agree.

>> > The manual should not suggest that users bind any
>> > particular keys.  It's OK for a 3rd-party library
>> > to suggest key bindings.  It's not good for Emacs
>> > itself to do that.
>> 
>> I'm not sure I agree.  I'd welcome a list of bindings like C-z or M-o
>> which do nothing useful by default.  (In fact, I compiled such a list
>> myself - https://urldefense.proofpoint.com/v2/url?u=http-3A__mbork.pl_2019-
>> 2D03-2D18-5FFree-5FEmacs-5Fkey-
>> 5Fbindings&d=DwIBAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=kI3P6ljGv
>> 6CTHIKju0jqInF6AOwMCYRDQUmqX22rJ98&m=vtPmjCas97xufIKnzS06ZEh04AKsMp8iJj-
>> 9W7kHURQ&s=zXD57trzqr01K4n0EBvwEqWYU6PCjR6gahEDtLcmms8&e=  - but I'm
>> not very happy with it.)
>
> One person's not-very-useful is another's useful.

Of course.

> And certainly the manual shouldn't suggest that users
> bind some key that has a default binding because that
> binding isn't very useful.
>
> If Emacs really thinks some default binding isn't
> very useful then it shouldn't bind it by default.

Here I don't agree.

Logically, you are of course right.

Psychologically, many people hesitate to rebind default keys for various
reasons.  While it is unreasonable for the manual to suggest binding
particular keys to particular commands, I would find it very reasonable
to encourage users to customize Emacs, including rebinding keys - also
the defaults.

After all, customizability is one of Emacs' greatest strengths.  It
should be natural for the manual to encourage the users to take
advantage of it.

>> > 3rd-party libraries are opt-in by users.  Using
>> > one is like adding its feature/code to your init
>> > file - it's a user choice.
>> >
>> > The same isn't true of much of the code distributed
>> > by Emacs.  And even when a distributed library (e.g.
>> > `dired-x.el') is opt-in, Emacs should not suggest
>> > bindings for its commands.  "Suggestion" by Emacs
>> > is sometimes mistakenly taken by users as a "rule"
>> > or a convention.
>> 
>> That's why it should be made clear that it's a suggestion, like:
>> 
>> "Many users find some commands not useful for them at all.  They might
>> want to rebind their keys to ones that they use frequently."
>
> That's not helpful, IMO.  Anyone can know that and
> do that, without Emacs suggesting to bind specific
> keys. And what one user finds not useful another one
> finds useful.

Again: logically, you're correct.  But there is a huge gap between
"knowing" and "doing".  And some people (me included) could find such an
ecouragement helpful.

> (Why does "Many users..." remind me of DJT's "Many
> people are saying..."? ;-))

I have no idea who or what DJT is.  DuckDuckGo mentioned one of the
better American presidents, is that what you meant?

> But sure, many users find some things not useful for
> them.  Many users aren't even aware of much of Emacs.
> Most users, me included, use only a tiny bit of what
> Emacs offers.
>
> Users differ.  Use cases differ.  There are many ways
> to use Emacs.
>
> Any user who finds some key that is bound by default
> not to be useful can rebind it.  That's not specific
> to any particular key.  The doc should not be trying
> to find and inform about keys that "many users" find
> not so useful.
>
>> > There's no good reason for Emacs to suggest that
>> > users use `C-z' for anything particular.
>> 
>> On the contrary, there is: the meaning of C-z is "I want to leave Emacs
>> for a moment and be able to come back".
>
> Not in GUI Emacs, it's not, unless you consider
> iconifying to be "leaving Emacs".

While I do not consider iconifying to be "leaving Emacs", I think it can
be described as "leaving Emacs for a moment", which is a very different
concept.

Again: I don't think this is so important to waste so much time
discussing.  I can live without any change in that department.  But
I guess that some encouragement to rebind keys in the manual could be
beneficial.

Best,

-- 
Marcin Borkowski
http://mbork.pl





  reply	other threads:[~2019-10-09 18:33 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-06-12  1:46 bug#3540: Please reserve a ctrl-key combination for interoperability Karl O. Pinc
2010-12-25 11:02 ` bug#3540: reserve a key + inform other gnu package maintainers and mode-authors Arne Babenhauserheide
2019-10-06  4:56 ` bug#3540: Please reserve a ctrl-key combination for interoperability Stefan Kangas
2019-10-06  7:04   ` Marcin Borkowski
2019-10-06 16:10     ` Drew Adams
2019-10-06 19:39       ` Marcin Borkowski
2019-10-06 21:29         ` Drew Adams
2019-10-09 18:33           ` Marcin Borkowski [this message]
2019-10-10 11:04             ` Stefan Kangas
2019-11-17 20:41               ` Stefan Kangas
2019-11-23 23:37               ` Stefan Kangas
2019-10-06 17:38     ` 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=8736g1epls.fsf@mbork.pl \
    --to=mbork@mbork.pl \
    --cc=3540@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=kop@meme.com \
    --cc=stefan@marxist.se \
    /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).