GNU bug report logs -
#27191
26.0.50; Long history items in minibuffer (again)
Previous Next
Full log
View this message in rfc822 format
[Message part 1 (text/plain, inline)]
On Thu, 01 Jun 2017 22:46:15 +0200 Stephen Berman <stephen.berman <at> gmx.net> wrote:
> 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)
Oops, I did. Here's the corrected patch:
[Message part 2 (text/x-patch, inline)]
diff --git a/lisp/simple.el b/lisp/simple.el
index ea3a495fbc..5c7dab8f74 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.
@@ -2157,15 +2166,12 @@ previous-line-or-history-element
(if (= (line-number-at-pos) 1)
(move-to-column (+ old-column (1- (minibuffer-prompt-end))))
(move-to-column old-column))
- ;; Put the cursor at the end of the visual line instead of the
- ;; logical line, so the next `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)))))))
+ ;; Put the cursor at the end of the logical line, even if it extends
+ ;; beyond window-width, since that is the natural target for editing
+ ;; history elements (bug#27191). The condition above makes sure the
+ ;; next `previous-line-or-history-element' will move to the previous
+ ;; history element in either case.
+ (end-of-line))))))
(defun next-complete-history-element (n)
"Get next history element which completes the minibuffer before the point.
[Message part 3 (text/plain, inline)]
Steve Berman
This bug report was last modified 4 years and 299 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.