From: Drew Adams <drew.adams@oracle.com>
To: Juri Linkov <juri@linkov.net>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>, emacs-devel@gnu.org
Subject: RE: Losing minibuffer input
Date: Thu, 20 Nov 2014 16:24:26 -0800 (PST) [thread overview]
Message-ID: <52b231e3-f2a2-4d92-91e9-da3c625b1b9f@default> (raw)
In-Reply-To: <87zjbll9ao.fsf@mail.linkov.net>
> > [FWIW, S-RET is used in at least one 3rd-party library for
> > an alternative (to RET) action on the input.]
>
> There is no conflict since a 3rd-party library can freely override
> any default keybinding.
Sure, but users sooner or later start to complain about interference
with "standard" vanilla bindings, even if it is Emacs itself that
has come late to the game.
RET in Emacs, especially during completion, is not just like RET
in most applications. Like TAB. They both do so much more in
Emacs.
Modifiers used with RET and TAB should be reserved for actions
similar or analogous to what RET and TAB are used for without
modifiers (as we have done with M-TAB, for instance). In particular,
in the minibuffer they should be reserved for actions similar to
what RET and TAB do in the minibuffer. And this, whether it is
vanilla Emacs (now or in the future) or users or a 3rd-party
library that binds RET or TAB + modifier keys in minibuffer maps.
We should not be jumping at the chance to copy other programs,
which do not have such sophisticated (minibuffer, completion etc.)
interactions (if they have any such at all), in their simple use
of S-RET as a way to simply insert a hard return. That is leveling
toward the bottom (most rudimentary) editing behavior instead of
reaching toward the top (the rest of Emacs).
Especially since in the Emacs (and UNIX and GNU/Linux and ASCII...)
world, we **already have a way of inserting a newline char**: just
type it (`C-j'). That's what we use for searching, and that is
what we should use to insert a newline char in the minibuffer also.
Use `C-j' to insert a newline char. Simple. Emacsy. Unixy.
This is *already* a useful Emacs idiom. There is no good reason
to use up a powerfully mnemonic key like S-RET, to simply insert
a newline.
Make S-RET, M-RET, C-M-RET, C-S-RET, M-S-RET, C-M-S-RET, if we use
them, do things that are Emacs-analogous to things that Emacs does
for RET. Similarly, make S-TAB, M-TAB, C-M-TAB, C-S-TAB, M-S-TAB,
C-M-S-TAB, if we use them, do things that are Emacs-analogous to
things that Emacs does for TAB.
It just does not always make sense to copy what is done in other
programs that cannot take advantage of all that Emacs has to offer.
They have no advantage in fitting in with other, existing Emacs
keys, habits, features and ways of use. Too bad for them. You
don't need to waste S-RET on inserting a C-j char. So don't
bother. I guarantee that you will find better, more
minibuffer-oriented things to do with such a key.
next prev parent reply other threads:[~2014-11-21 0:24 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-09 17:57 Losing minibuffer input Juri Linkov
2014-11-09 18:17 ` Óscar Fuentes
2014-11-09 18:33 ` Juri Linkov
2014-11-09 18:53 ` Drew Adams
2014-11-13 20:23 ` Juri Linkov
2014-11-14 11:16 ` Dmitry Gutov
2014-11-18 21:36 ` Juri Linkov
2014-11-20 22:38 ` Johan Bockgård
2014-11-20 23:58 ` Juri Linkov
2014-11-21 7:37 ` previous-line, next-line at the first, last lines of the buffer Ivan Shmakov
2014-11-21 8:49 ` Eli Zaretskii
2014-11-21 9:12 ` Ivan Shmakov
2014-11-30 13:31 ` Stefan Monnier
2014-11-09 18:52 ` Losing minibuffer input Drew Adams
2014-11-09 18:52 ` Drew Adams
2014-11-13 21:14 ` Stefan Monnier
2014-11-18 21:40 ` Juri Linkov
2014-11-19 4:22 ` Drew Adams
2014-11-20 23:52 ` Juri Linkov
2014-11-21 0:24 ` Drew Adams [this message]
2014-11-20 16:35 ` Daniel Colascione
2014-11-20 23:55 ` Juri Linkov
2014-12-05 0:38 ` Multi-line input (was: Losing minibuffer input) Juri Linkov
2014-12-05 2:03 ` Multi-line input Stefan Monnier
2014-12-05 16:24 ` Yuri Khan
2014-12-05 18:45 ` Stefan Monnier
2014-12-05 22:43 ` Richard Stallman
[not found] ` <<E1Xx1bN-0007f9-Ut@fencepost.gnu.org>
2014-12-05 23:02 ` Drew Adams
2014-12-06 12:06 ` Richard Stallman
[not found] ` <<94e0230f-c396-4266-8ada-9816d8118946@default>
[not found] ` <<E1XxE8T-0002OE-U9@fencepost.gnu.org>
2014-12-06 16:44 ` Drew Adams
2014-12-05 23:43 ` Juri Linkov
2014-12-06 3:20 ` Drew Adams
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=52b231e3-f2a2-4d92-91e9-da3c625b1b9f@default \
--to=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=juri@linkov.net \
--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).