From: Juri Linkov <juri@jurta.org>
To: emacs-devel@gnu.org
Subject: Losing minibuffer input
Date: Sun, 09 Nov 2014 19:57:27 +0200 [thread overview]
Message-ID: <87fvds2r5i.fsf@mail.jurta.org> (raw)
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
next reply other threads:[~2014-11-09 17:57 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-09 17:57 Juri Linkov [this message]
2014-11-09 18:17 ` Losing minibuffer input Ó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
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fvds2r5i.fsf@mail.jurta.org \
--to=juri@jurta.org \
--cc=emacs-devel@gnu.org \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.