[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#27191: 26.0.50; Long history items in minibuffer (again)
From: |
Stephen Berman |
Subject: |
bug#27191: 26.0.50; Long history items in minibuffer (again) |
Date: |
Fri, 02 Jun 2017 23:17:24 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) |
On Fri, 02 Jun 2017 10:01:04 +0200 Stephen Berman <stephen.berman@gmx.net>
wrote:
> On Thu, 01 Jun 2017 22:46:15 +0200 Stephen Berman <stephen.berman@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.
I also overlooked that <down> on such a long line in the minibuffer
moves visually to the overflowing part of the element, rather than
immediately going to the next history element; this is likewise fixed by
the corresponding patch to next-line-or-history-element:
diff --git a/lisp/simple.el b/lisp/simple.el
index ea3a495fbc..7914fc1fae 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2106,7 +2106,16 @@ next-line-or-history-element
(current-column)))))
(condition-case nil
(with-no-warnings
- (next-line arg))
+ ;; If the history element consists of a single line longer
+ ;; than window-width, move by logical lines to hit
+ ;; end-of-buffer immediately and get the next history
+ ;; element. Otherwise, move by visual lines.
+ (if (and (save-excursion
+ (end-of-line)
+ (> (current-column) (window-width)))
+ (= (line-number-at-pos) 1))
+ (next-logical-line arg)
+ (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.
(Unlike with previous-line-or-history-element, with without
next-line-or-history-element I don't see any difference with or without
an explicit call to end-of-line at the end.)
Steve Berman