From: Stephen Berman <stephen.berman@gmx.net>
To: 27191@debbugs.gnu.org
Subject: bug#27191: 26.0.50; Long history items in minibuffer (again)
Date: Thu, 01 Jun 2017 22:46:15 +0200 [thread overview]
Message-ID: <874lvzh1wo.fsf@rosalinde> (raw)
[-- Attachment #1: Type: text/plain, Size: 2505 bytes --]
0. emacs -Q
1. C-x C-f ~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed <RET>
2. C-x C-f <up>
=> The file name entered in step 1 appears in the minibuffer, with point
on the "w" of "when" (i.e., column 80, the end of the visual line).
If at step 2 instead of <up> you type `M-p', then point is at the end of
the file name in the minibuffer. This is what I expected for <up> too.
The result with <up> is due to the fix for bug#22544. In the bug thread
(http://lists.gnu.org/archive/html/bug-gnu-emacs/2016-02/msg00357.html),
the above problem was noted:
> > Can't we special-case a line that isn't broken into several visual
> > lines, and put the cursor at the end of such lines only? That'd be
> > the best.
>
> The problem here is that like bash and other shells with histories do,
> we need to put the cursor at the end of the previous history element
> so the user can start editing it immediately (usually deleting the chars
> from the end of the logical line). OTOH, a subsequent <UP> should
> continue navigating the history and put the next previous element to the
> minibuffer. But then <UP> can't be used to move between visual lines.
> This is a lose-lose situation, unless we'll find some clever DWIM.
The attached patch isn't particularly clever, but (unless I've
overlooked something) DWIM: it puts point at the end of a history
element longer than window-width, and if such an element is a single
line, the next <up> displays the previous history element. Otherwise,
<up> moves by visual lines (specifically also in multi-line history
elements, including those with lines longer than window-width).
(I wanted to add tests for this, but I haven't been able to figure out
how to emulate minibuffer history navigation non-interactively.)
In GNU Emacs 26.0.50 (build 30, x86_64-pc-linux-gnu, GTK+ Version 3.22.8)
of 2017-05-29 built on rosalinde
Repository revision: c503188f8079ae73d95abd0bce0f53d104b03205
Windowing system distributor 'The X.Org Foundation', version 11.0.11901000
2017-06-01 Stephen Berman <stephen.berman@gmx.net>
Improve navigation through minibuffer history
* lisp/simple.el (previous-line-or-history-element): If the
element extends beyond window-width, go to its logical end,
since that is the natural target for editing history elements.
If it consists of a single line, move by logical lines to hit
beginning-of-buffer immediately and get the previous history
element. Otherwise, move by visual lines.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: previous-line-or-history-element patch --]
[-- Type: text/x-patch, Size: 1632 bytes --]
diff --git a/lisp/simple.el b/lisp/simple.el
index ea3a495fbc..1b96bce773 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2140,7 +2140,16 @@ previous-line-or-history-element
(current-column)))))
(condition-case nil
(with-no-warnings
- (previous-line arg))
+ ;; If the history element consists of a single line longer
+ ;; than window-width, move by logical lines to hit
+ ;; beginning-of-buffer immediately and get the previous
+ ;; history element. Otherwise, move by visual lines.
+ (if (and (save-excursion
+ (end-of-line)
+ (> (current-column) (window-width)))
+ (= (line-number-at-pos) 1))
+ (previous-logical-line arg)
+ (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.
@@ -2162,10 +2171,9 @@ previous-line-or-history-element
;; would move to the previous history element, not to a possible upper
;; visual line from the end of logical line in `line-move-visual' mode.
(end-of-visual-line)
- ;; Since `end-of-visual-line' puts the cursor at the beginning
- ;; of the next visual line, move it one char back to the end
- ;; of the first visual line (bug#22544).
- (unless (eolp) (backward-char 1)))))))
+ ;; If the line extends beyond window-width, go to its logical end,
+ ;; since that is the natural target for editing history elements.
+ (unless (eolp) (end-of-line)))))))
(defun next-complete-history-element (n)
"Get next history element which completes the minibuffer before the point.
next reply other threads:[~2017-06-01 20:46 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-01 20:46 Stephen Berman [this message]
2017-06-02 8:01 ` bug#27191: 26.0.50; Long history items in minibuffer (again) Stephen Berman
2017-06-02 21:17 ` Stephen Berman
2020-08-24 14:38 ` Lars Ingebrigtsen
2020-08-25 18:01 ` Stephen Berman
2020-08-25 19:17 ` 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=874lvzh1wo.fsf@rosalinde \
--to=stephen.berman@gmx.net \
--cc=27191@debbugs.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 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).