Losing minibuffer input

Losing minibuffer input

[Juri Linkov]

There is a long-standing usability problem when editing multi-line text in
the minibuffer: it's too easy to lose edited text by pressing an up-down
arrow key with the intention to go to the next/previous line like in a
normal buffer.  The changes are lost because the up-down key has a special
meaning in the minibuffer to go to the next/previous history item.

The fix is simple: allow up-down arrow keys to have their usual behavior
and only on hitting the beginning/end of the minibuffer move to the next
or previous history item, thus making navigation more smooth and continuous.

=== modified file 'lisp/bindings.el'
--- lisp/bindings.el	2014-07-21 05:38:17 +0000
+++ lisp/bindings.el	2014-11-09 17:56:08 +0000
@@ -839,11 +839,11 @@ (define-key global-map [XF86Back] 'previ
 (let ((map minibuffer-local-map))
   (define-key map "\en"   'next-history-element)
   (define-key map [next]  'next-history-element)
-  (define-key map [down]  'next-history-element)
+  (define-key map [down]  'next-line-or-history-element)
   (define-key map [XF86Forward] 'next-history-element)
   (define-key map "\ep"   'previous-history-element)
   (define-key map [prior] 'previous-history-element)
-  (define-key map [up]    'previous-history-element)
+  (define-key map [up]    'previous-line-or-history-element)
   (define-key map [XF86Back] 'previous-history-element)
   (define-key map "\es"   'next-matching-history-element)
   (define-key map "\er"   'previous-matching-history-element)

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2014-11-08 23:52:59 +0000
+++ lisp/simple.el	2014-11-09 17:57:01 +0000
@@ -1982,6 +1982,36 @@ (defun previous-history-element (n)
   (or (zerop n)
       (goto-history-element (+ minibuffer-history-position n))))
 
+(defun next-line-or-history-element (&optional arg)
+  "Move cursor vertically down ARG lines, or to the next history element.
+When point is at the bottom line of multi-line minibuffer, puts ARGth
+next element of the minibuffer history in the minibuffer."
+  (interactive "^p")
+  (or arg (setq arg 1))
+  (let ((old-point (point)))
+    (condition-case nil
+	(next-line arg)
+      (end-of-buffer
+       ;; Restore old position since `line-move-visual' moves point to
+       ;; the end of the line when it fails to go to the next line.
+       (goto-char old-point)
+       (next-history-element arg)))))
+
+(defun previous-line-or-history-element (&optional arg)
+  "Move cursor vertically up ARG lines, or to the previous history element.
+When point is at the top line of multi-line minibuffer, puts ARGth
+previous element of the minibuffer history in the minibuffer."
+  (interactive "^p")
+  (or arg (setq arg 1))
+  (let ((old-point (point)))
+    (condition-case nil
+	(previous-line arg)
+      (beginning-of-buffer
+       ;; Restore old position since `line-move-visual' moves point to
+       ;; the beginning of the line when it fails to go to the previous line.
+       (goto-char old-point)
+       (previous-history-element arg)))))
+
 (defun next-complete-history-element (n)
   "Get next history element which completes the minibuffer before the point.
 The contents of the minibuffer after the point are deleted, and replaced

Re: Losing minibuffer input

[Óscar Fuentes]

Juri Linkov <juri@jurta.org> writes:

> There is a long-standing usability problem when editing multi-line text in
> the minibuffer: it's too easy to lose edited text by pressing an up-down
> arrow key with the intention to go to the next/previous line like in a
> normal buffer.  The changes are lost because the up-down key has a special
> meaning in the minibuffer to go to the next/previous history item.
>
> The fix is simple: allow up-down arrow keys to have their usual behavior
> and only on hitting the beginning/end of the minibuffer move to the next
> or previous history item, thus making navigation more smooth and continuous.

I see some incoveniences with this approach: when you are on the first
displayed line and you think that there are more lines preceding it,
pressing up has the same problem you want to solve if there was no
preceding line. Ditto if you are on the last displayed line.
Furthermore, if you are on the first line and you want to pick the next
item on the minibuffer history you are forced to press down until the
last line. Ditto if you are on the last line and want to pick the
preceding item on the minibuffer.

A safer option seems to disable up/down history navigation when the
minibuffer contains more than one line. Use M-p/M-n instead.

Re: Losing minibuffer input

[Juri Linkov]

> I see some incoveniences with this approach: when you are on the first
> displayed line and you think that there are more lines preceding it,
> pressing up has the same problem you want to solve if there was no
> preceding line. Ditto if you are on the last displayed line.

This problem is very rare in the minibuffer because usually the
minibuffer contents is displayed completely in its entirety.  However,
later we can add an option like `scroll-error-top-bottom' that will
signal an error on the first hit to the beginning/end of the minibuffer,
and only on the second hit go to the previous/next history item.

> Furthermore, if you are on the first line and you want to pick the next
> item on the minibuffer history you are forced to press down until the
> last line. Ditto if you are on the last line and want to pick the
> preceding item on the minibuffer.

Then you can use M-p/M-n.

RE: Losing minibuffer input

[Drew Adams]

> when editing multi-line text in the minibuffer: it's too easy to lose
> edited text by pressing an up-down arrow key with the intention to go
> to the next/previous line like in a normal buffer.  The changes are
> lost because the up-down key has a special meaning in the minibuffer
> to go to the next/previous history item.

So just don't do that.  Use `C-n' & `C-p' to move to a different line.

And you can always use `undo' to undo any such boo-boo and get back
what (you think) you lost.  You can _edit_ text in the minibuffer.
In particular, `undo' works fine.

But if the vanilla Emacs behavior really bothers you, then customize
bindings in your `minibuffer-local-map' - for your own use.  Trivial
to do.

> The fix is simple:

It ain't broke; don't fix it.

> allow up-down arrow keys to have their usual behavior and only on
> hitting the beginning/end of the minibuffer move to the next
> or previous history item, thus making navigation more smooth and
> continuous.

So now users will need to move point to the beginning or end of the
minibuffer, just to get `up' and `down' to navigate the history list?

No thanks.

>(define-key map [down]  'next-line-or-history-element)
>(define-key map [up]    'previous-line-or-history-element)
> 
> (defun next-line-or-history-element (&optional arg)
>   "Move cursor vertically down ARG lines, or to the next history element.
> When point is at the bottom line of multi-line minibuffer, puts ARGth
> next element of the minibuffer history in the minibuffer."

The language here even underlines how much of a mishmash this is.
Move _the cursor_ to the next history element?  I don't think so.

This behavior is not only not handy; it is also confusing.

RE: Losing minibuffer input

[Drew Adams]

> A safer option seems to disable up/down history navigation when the
> minibuffer contains more than one line. Use M-p/M-n instead.

So your not knowing whether you are on the first/last line or not
will now translate into the up/down keys having different behavior
depending on where you are?  That's precisely (part of) what is
wrong with Juri's "fix".

You guys are trying to fix something that is not broken.
Please don't.

RE: Losing minibuffer input

[Drew Adams]

> > I see some incoveniences with this approach: when you are on the
> > first displayed line and you think that there are more lines
> > preceding it, pressing up has the same problem you want to solve
> > if there was no preceding line. Ditto if you are on the last
> > displayed line.
> 
> This problem is very rare in the minibuffer because usually the
> minibuffer contents is displayed completely in its entirety.
>
> However, later we can add an option like `scroll-error-top-bottom'
> that will signal an error on the first hit to the beginning/end of
> the minibuffer, and only on the second hit go to the previous/next
> history item.

!?  Good for April 1.

Epicycles on top of epicycles...

Please work out your own new solar-system design as a customization,
not a change to Emacs.  We already have an easy way to customize the
key behavior: Customize your `minibuffer-local-map` keys.
 
> > Furthermore, if you are on the first line and you want to pick
> > the next item on the minibuffer history you are forced to press
> > down until the last line. Ditto if you are on the last line and
> > want to pick the preceding item on the minibuffer.
> 
> Then you can use M-p/M-n.

You can use M-p/M-n all the time, and you can bind up/down to
whatever other behavior you want for the minibuffer - yourself,
like any other user who has a personal preference.

Re: Losing minibuffer input

[Juri Linkov]

> Epicycles on top of epicycles...

Other software whose developers care about users do not throw user
input away on cursor movement.  For example, both Firefox and Chromium
allow up/down keys to move the cursor to the top/bottom of the multi-line
Console minibuffer before advancing to the previous/next history element.

Re: Losing minibuffer input

[Stefan Monnier]

> The fix is simple: allow up-down arrow keys to have their usual behavior
> and only on hitting the beginning/end of the minibuffer move to the next
> or previous history item, thus making navigation more smooth and continuous.

Sounds good to me (oddly enough, while I use up/down/left/right
frequently in normal buffers, it seems that I never use up/down in the
minibuffer (I use M-p/M-n to go through the history and C-p/C-n for
in-buffer movement)).


        Stefan

Re: Losing minibuffer input

[Dmitry Gutov]

Juri Linkov <juri@jurta.org> writes:

> Other software whose developers care about users do not throw user
> input away on cursor movement.  For example, both Firefox and Chromium
> allow up/down keys to move the cursor to the top/bottom of the multi-line
> Console minibuffer before advancing to the previous/next history element.

I just checked Firefox's behavior, and when in the middle the first
line, <up> first moves cursor to the beginning of the line (and
similarly for the <down> key). Maybe that's worth borrowing, too?

Re: Losing minibuffer input

[Juri Linkov]

> I just checked Firefox's behavior, and when in the middle the first
> line, <up> first moves cursor to the beginning of the line (and
> similarly for the <down> key). Maybe that's worth borrowing, too?

I think it would be better in the minibuffer to reproduce
the default behavior of these keys in an ordinary Emacs buffer.
Typing <down> in the middle of the last line (that doesn't end
with a newline) moves point to the end of the line.  This is similar
to Firefox's behavior.

However, typing <up> in the middle of the first line in an ordinary
Emacs buffer doesn't move point to the beginning of the first line.
I don't know why do we have such inconsistency and whether we should
reproduce it in the minibuffer?

Re: Losing minibuffer input

[Juri Linkov]

>> The fix is simple: allow up-down arrow keys to have their usual behavior
>> and only on hitting the beginning/end of the minibuffer move to the next
>> or previous history item, thus making navigation more smooth and continuous.
>
> Sounds good to me (oddly enough, while I use up/down/left/right
> frequently in normal buffers, it seems that I never use up/down in the
> minibuffer (I use M-p/M-n to go through the history and C-p/C-n for
> in-buffer movement)).

There is another convenience in other programs that we could use.
Most programs allow typing S-RET to insert a newline in their analogue
of the minibuffer.  Even though it might be unavailable on some terminals,
what do you think about adding it for GUI sessions?

RE: Losing minibuffer input

[Drew Adams]

> There is another convenience in other programs that we could use.
> Most programs allow typing S-RET to insert a newline in their
> analogue of the minibuffer.  Even though it might be unavailable
> on some terminals, what do you think about adding it for GUI 
> sessions?

Again, please don't. 

[FWIW, S-RET is used in at least one 3rd-party library for
an alternative (to RET) action on the input.]

What makes more sense, IMO, is to simply let `C-j' (newline)
be self-inserting.  There is no reason not to - along with
`?' and `SPC' (generally, not just for file names).  But I
repeat myself...

Re: Losing minibuffer input

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 947 bytes --]

On 11/18/2014 01:40 PM, Juri Linkov wrote:
>>> The fix is simple: allow up-down arrow keys to have their usual behavior
>>> and only on hitting the beginning/end of the minibuffer move to the next
>>> or previous history item, thus making navigation more smooth and continuous.
>>
>> Sounds good to me (oddly enough, while I use up/down/left/right
>> frequently in normal buffers, it seems that I never use up/down in the
>> minibuffer (I use M-p/M-n to go through the history and C-p/C-n for
>> in-buffer movement)).
> 
> There is another convenience in other programs that we could use.
> Most programs allow typing S-RET to insert a newline in their analogue
> of the minibuffer.  Even though it might be unavailable on some terminals,
> what do you think about adding it for GUI sessions?
> 

S-RET is a good idea; I've seen this keybinding used in lots of other programs for "insert a newline without executing an action".


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: Losing minibuffer input

[Johan Bockgård]

Juri Linkov <juri@linkov.net> writes:

> Typing <down> in the middle of the last line (that doesn't end
> with a newline) moves point to the end of the line.  This is similar
> to Firefox's behavior.
>
> However, typing <up> in the middle of the first line in an ordinary
> Emacs buffer doesn't move point to the beginning of the first line.

But it used to do so before Emacs 23.

Re: Losing minibuffer input

[Juri Linkov]

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

Re: Losing minibuffer input

[Juri Linkov]

> S-RET is a good idea; I've seen this keybinding used in lots of
> other programs for "insert a newline without executing an action".

It can be added by this patch:

diff --git a/lisp/bindings.el b/lisp/bindings.el
index 789fdf0..658d0c6 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -851,6 +851,7 @@ (let ((map minibuffer-local-map))
   ;; indent-for-tab-command).  The alignment that indent-relative tries to
   ;; do doesn't make much sense here since the prompt messes it up.
   (define-key map "\t"    'self-insert-command)
+  (define-key map [S-return] 'newline)
   (define-key map [C-tab] 'file-cache-minibuffer-complete))
 
 (define-key global-map "\C-u" 'universal-argument)

Re: Losing minibuffer input

[Juri Linkov]

>> Typing <down> in the middle of the last line (that doesn't end
>> with a newline) moves point to the end of the line.  This is similar
>> to Firefox's behavior.
>>
>> However, typing <up> in the middle of the first line in an ordinary
>> Emacs buffer doesn't move point to the beginning of the first line.
>
> But it used to do so before Emacs 23.

Seems necessary to do pre-23 git bisecting.

RE: Losing minibuffer input

[Drew Adams]

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

previous-line, next-line at the first, last lines of the buffer

[Ivan Shmakov]

>>>>> Johan Bockgård <bojohan@gnu.org> writes:
>>>>> Juri Linkov <juri@linkov.net> writes:

 >> Typing <down> in the middle of the last line (that doesn't end with
 >> a newline) moves point to the end of the line.  This is similar to
 >> Firefox's behavior.

 >> However, typing <up> in the middle of the first line in an ordinary
 >> Emacs buffer doesn't move point to the beginning of the first line.

 > But it used to do so before Emacs 23.

	Or, rather, before visual-line-mode was made a default.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: previous-line, next-line at the first, last lines of the buffer

[Eli Zaretskii]

> From: Ivan Shmakov <ivan@siamics.net>
> Date: Fri, 21 Nov 2014 07:37:05 +0000
> 
> >>>>> Johan Bockgård <bojohan@gnu.org> writes:
> >>>>> Juri Linkov <juri@linkov.net> writes:
> 
>  >> Typing <down> in the middle of the last line (that doesn't end with
>  >> a newline) moves point to the end of the line.  This is similar to
>  >> Firefox's behavior.
> 
>  >> However, typing <up> in the middle of the first line in an ordinary
>  >> Emacs buffer doesn't move point to the beginning of the first line.
> 
>  > But it used to do so before Emacs 23.
> 
> 	Or, rather, before visual-line-mode was made a default.

You mean, line-move-visual, I presume.

Re: previous-line, next-line at the first, last lines of the buffer

[Ivan Shmakov]

>>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>> From: Ivan Shmakov  Date: Fri, 21 Nov 2014 07:37:05 +0000
>>>>> Johan Bockgård <bojohan@gnu.org> writes:
>>>>> Juri Linkov <juri@linkov.net> writes:

 >>>> Typing <down> in the middle of the last line (that doesn't end
 >>>> with a newline) moves point to the end of the line.  This is
 >>>> similar to Firefox's behavior.

 >>>> However, typing <up> in the middle of the first line in an
 >>>> ordinary Emacs buffer doesn't move point to the beginning of the
 >>>> first line.

 >>> But it used to do so before Emacs 23.

 >> Or, rather, before visual-line-mode was made a default.

 > You mean, line-move-visual, I presume.

	Indeed I do.

-- 
FSF associate member #7257  http://boycottsystemd.org/  … 3013 B6A0 230E 334A

Re: previous-line, next-line at the first, last lines of the buffer

[Stefan Monnier]

>>>>> Typing <down> in the middle of the last line (that doesn't end
>>>>> with a newline) moves point to the end of the line.  This is
>>>>> similar to Firefox's behavior.
>>>>> However, typing <up> in the middle of the first line in an
>>>>> ordinary Emacs buffer doesn't move point to the beginning of the
>>>>> first line.
>>>> But it used to do so before Emacs 23.
>>> Or, rather, before visual-line-mode was made a default.
>> You mean, line-move-visual, I presume.
> 	Indeed I do.

But your original point still stands: It seems that this change was an
unintended consequence of an unrelated change.


        Stefan

Multi-line input (was: Losing minibuffer input)

[Juri Linkov]

> S-RET is a good idea; I've seen this keybinding used in lots of other
> programs for "insert a newline without executing an action".

Other problematic place where S-RET could help to insert a newline
is shell input.  What is worse in shell than in the minibuffer
typing RET accidentally in the middle of multi-line shell input
causes a mess: it sends the part before point, and leaves
the remaining lines dangling at the end of the shell buffer.

This patch gets the input until the end of the possibly multi-line
input field instead of only the end of the line:

diff --git a/lisp/comint.el b/lisp/comint.el
index da37827..da21d66 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -457,6 +457,7 @@ (defvar comint-mode-map
     (define-key map [?\C-c ?\M-s] 'comint-next-matching-input-from-input)
     (define-key map "\e\C-l" 	  'comint-show-output)
     (define-key map "\C-m" 	  'comint-send-input)
+    (define-key map [S-return]    'newline)
     (define-key map "\C-d" 	  'comint-delchar-or-maybe-eof)
     ;; The following two are standardly bound to delete-forward-char,
     ;; but they should never do EOF, just delete.
@@ -1781,7 +1782,7 @@ (defun comint-send-input (&optional no-newline artificial)
       (widen)
       (let* ((pmark (process-mark proc))
              (intxt (if (>= (point) (marker-position pmark))
-                        (progn (if comint-eol-on-send (end-of-line))
+                        (progn (if comint-eol-on-send (goto-char (field-end)))
                                (buffer-substring pmark (point)))
                       (let ((copy (funcall comint-get-old-input)))
                         (goto-char pmark)

While checking this, I also noticed a problem in searching the history of
multi-line entries.  `comint-line-beginning-position' operates only
on the current line, so it too should be replaced with `field-beginning':

diff --git a/lisp/comint.el b/lisp/comint.el
index da37827..da21d66 100644
--- a/lisp/comint.el
+++ b/lisp/comint.el
@@ -1475,7 +1476,7 @@ (defun comint-history-isearch-search ()
       (or
        ;; 1. First try searching in the initial comint text
        (funcall search-fun string
-		(if isearch-forward bound (comint-line-beginning-position))
+		(if isearch-forward bound (field-beginning))
 		noerror)
        ;; 2. If the above search fails, start putting next/prev history
        ;; elements in the comint successively, and search the string
@@ -1491,7 +1492,7 @@ (defun comint-history-isearch-search ()
 			(when (null comint-input-ring-index)
 			  (error "End of history; no next item"))
 			(comint-next-input 1)
-			(goto-char (comint-line-beginning-position)))
+			(goto-char (field-beginning)))
 		       (t
 			;; Signal an error here explicitly, because
 			;; `comint-previous-input' doesn't signal an error.
@@ -1509,7 +1510,7 @@ (defun comint-history-isearch-search ()
 				      (unless isearch-forward
 					;; For backward search, don't search
 					;; in the comint prompt
-					(comint-line-beginning-position))
+					(field-beginning))
 				      noerror)))
 	       ;; Return point of the new search result
 	       (point))

Re: Multi-line input

[Stefan Monnier]

> Other problematic place where S-RET could help to insert a newline
> is shell input.

As mentioned earlier, I'm not convinced S-RET is a great idea, since
I think it's more beneficial to get people to learn about C-q.

I do realize that we have a problem in C-q because you need C-q C-j
rather than C-q RET (the same problem recently pointed out by Raman
w.r.t to the ?\n in electric-indent-chars which affects the behavior of
RET rather than that of C-j).

So, S-RET is not without merit, but I'm still not quite convinced it's
a good idea.  I wish I could solve the "C-q RET doesn't insert
a newline" problem instead.

> What is worse in shell than in the minibuffer typing RET accidentally
> in the middle of multi-line shell input causes a mess: it sends the
> part before point, and leaves the remaining lines dangling at the end
> of the shell buffer.

> This patch gets the input until the end of the possibly multi-line
> input field instead of only the end of the line:

Good, please install it.

> While checking this, I also noticed a problem in searching the history of
> multi-line entries.  `comint-line-beginning-position' operates only
> on the current line, so it too should be replaced with `field-beginning':

I'm less confident, but I think this is good as well.  Please install.


        Stefan

Re: Multi-line input

[Yuri Khan]

On Fri, Dec 5, 2014 at 8:03 AM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Other problematic place where S-RET could help to insert a newline
>> is shell input.
>
> As mentioned earlier, I'm not convinced S-RET is a great idea, since
> I think it's more beneficial to get people to learn about C-q.

C-q is one thing, S-RET is another.

It *is* a great idea. All Internet chat programs have standardized on
it — Enter sends the current contents of the message entry area,
Shift+Enter adds a newline. (Some provide a user preference to swap
these.) And shell prompts and Emacs minibuffer are basically chats
with the user on one side and the interpreter on the other.

Re: Multi-line input

[Stefan Monnier]

> It *is* a great idea. All Internet chat programs have standardized on
> it — Enter sends the current contents of the message entry area,
> Shift+Enter adds a newline.

Obviously, I don't chat very much.


        Stefan

Re: Multi-line input

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  >   I wish I could solve the "C-q RET doesn't insert
  > a newline" problem instead.

I tried to find a good solution for this, but I don't see one.
C-q ^M is the only natural way to insert a ^M, and on a tty that
can't be distinguished from C-q RET.

On a graphics window, C-M and RET can be distinguished.
Maybe it is possible to make C-q C-m insert ^M and make
C-q RET insert newline.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

RE: Multi-line input

[Drew Adams]

> On a graphics window, C-M and RET can be distinguished.
> Maybe it is possible to make C-q C-m insert ^M and make
> C-q RET insert newline.

Huh?  Why a newline?  Control J *is* a newline char.

Instead of treating that as an aberration or some secret
incantation, we should (and we do, for the most part)
simply make the Control J <=> newline relationship, and
hence `C-q C-j' for insertion, known from the outset.

Emacs users, like GNU/Linux users in general, should be
aware of this, if they make explicit use of newline chars.

You can distinguish the key `C-m' from the key `<return>',
but you cannot distinguish the character Control M from
the character CR (carriage return) - by definition.

Re: Multi-line input

[Juri Linkov]

> As mentioned earlier, I'm not convinced S-RET is a great idea, since
> I think it's more beneficial to get people to learn about C-q.

The only downside of S-RET is that it's not available on a tty.
But on a graphical display S-RET is a common key to insert a newline.

> I do realize that we have a problem in C-q because you need C-q C-j
> rather than C-q RET (the same problem recently pointed out by Raman
> w.r.t to the ?\n in electric-indent-chars which affects the behavior of
> RET rather than that of C-j).

`electric-indent-mode' has a similar problem.
NEWS.24 recommends using `C-j' to insert a newline:

  *** `electric-indent-mode' is now enabled by default.
  Typing RET reindents the current line and indents the new line.
  `C-j' inserts a newline but does not indent.

But e.g. in *scratch* typing `C-j' evaluates the last expression.
S-RET could help here as well, after agreeing on its universal meaning
of inserting a newline.

RE: Multi-line input

[Drew Adams]

> The only downside of S-RET is that it's not available on a tty.
> But on a graphical display S-RET is a common key to insert a
> newline.

Nope.  As I mentioned in thread "Losing minibuffer input", Emacs
should not sacrifice `S-RET' to just inserting a newline char,
as some other, lesser programs do.

Emacs should reserve `S-RET' for behavior similar to Emacs
`RET' behavior.  And depending on the context that can mean
things like choosing a completion candidate.  Like `TAB',
`RET' does more in Emacs than it does in other programs.
As I said:

 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.

Besides which, Emacs already has a perfectly good, canonical
way to insert a newline char: `C-j'.  Make `C-j' self-inserting
in more keymaps and you will not need to waste `S-RET' for that,
nor will you need a `C-q C-j' workaround.  You are making things
complicated for nothing.

>   *** `electric-indent-mode' is now enabled by default.
>   Typing RET reindents the current line and indents the new
>   line.  `C-j' inserts a newline but does not indent.
> 
> But e.g. in *scratch* typing `C-j' evaluates the last expression.
> S-RET could help here as well, after agreeing on its universal
> meaning of inserting a newline.

There is no such "universal meaning".  For Emacs use, this is
backward.  `C-j' in *scratch* should self-insert (newline char).
If anything should, it is `S-RET' that should have a special
behavior here, such as evaluating.

Are you going to be consistent, and swap `C-j' with `S-RET'
for specifying a newline char everywhere?  Will users who want
to search for a newline char now need to use `S-RET' during
Isearch? [*]  No?  So users will sometimes use `C-j' to insert
a newline, and sometimes use `S-RET'?  So much for "universal"
consistency.

What would be gained by that, besides a supposed consistency
with a few simplistic text-editing contexts?  Why not keep
Emacs consistent with itself instead - and with UNIX, GNU/Linux,...

Let newline (`C-j') be newline - across Emacs, by default.
Save `S-RET' for more complex behavior, just as we do (but
other, simpler edit contexts do not) for `RET' and `TAB'.


[*] Yes, FWIW, I would be in favor of having `C-j' self-insert
in Isearch also, instead of needing to use `C-q C-j'.  Just as
for a character such as `b' or `?', `C-j' would behave the same
within search and outside search: it would self-insert.  But
`C-q C-j' is anyway better than `S-RET' during search - it makes
clear that you are, well, inserting a `C-j' (newline) character.

Re: Multi-line input

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > On a graphics window, C-M and RET can be distinguished.
  > > Maybe it is possible to make C-q C-m insert ^M and make
  > > C-q RET insert newline.

  > Huh?  Why a newline?

Users associate Return with a newline, so they will find this natural.

  Control J *is* a newline char.

You know that, and I know that, but most users don't know that.

  > You can distinguish the key `C-m' from the key `<return>',
  > but you cannot distinguish the character Control M from
  > the character CR (carriage return) - by definition.

That's equivalent to what I said.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.

RE: Multi-line input

[Drew Adams]

>   Control J *is* a newline char.
> 
> You know that, and I know that, but most users don't know that.

Which is why I said:

* "Make `C-j' self-inserting in more keymaps" - users will
  find it and use it.  (They already do so for search.)

* "Instead of treating that as an aberration or some secret
  incantation, we should (and we do, for the most part)
  simply make the Control J <=> newline relationship, and
  hence `C-q C-j' for insertion, known from the outset.

  Emacs users, like GNU/Linux users in general, should be
  aware of this, if they make explicit use of newline chars."

IOW, making `C-j' self-insert generally, pretty much
everywhere, and documenting it prominently, will take it
out of the closet.