GNU logs - #27191, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#27191: 26.0.50; Long history items in minibuffer (again)
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 01 Jun 2017 20:47:02 +0000
Resent-Message-ID: <handler.27191.B.149634999430188 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 27191 <at> debbugs.gnu.org
From: Stephen Berman <stephen.berman@HIDDEN>
Date: Thu, 01 Jun 2017 22:46:15 +0200
Message-ID: <874lvzh1wo.fsf@rosalinde>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--=-=-=
Content-Type: text/plain

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@HIDDEN>

	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.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: attachment
Content-Description: previous-line-or-history-element patch

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.

--=-=-=--

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Stephen Berman <stephen.berman@HIDDEN>
Subject: bug#27191: Acknowledgement (26.0.50; Long history items in
 minibuffer (again))
Message-ID: <handler.27191.B.149634999430188.ack <at> debbugs.gnu.org>
References: <874lvzh1wo.fsf@rosalinde>
X-Gnu-PR-Message: ack 27191
X-Gnu-PR-Package: emacs
Reply-To: 27191 <at> debbugs.gnu.org
Date: Thu, 01 Jun 2017 20:47:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 27191 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
27191: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D27191
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#27191: 26.0.50; Long history items in minibuffer (again)
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 02 Jun 2017 08:02:01 +0000
Resent-Message-ID: <handler.27191.B27191.149639047413805 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 27191 <at> debbugs.gnu.org
From: Stephen Berman <stephen.berman@HIDDEN>
References: <874lvzh1wo.fsf@rosalinde>
Date: Fri, 02 Jun 2017 10:01:04 +0200
In-Reply-To: <874lvzh1wo.fsf@rosalinde> (Stephen Berman's message of "Thu, 01
 Jun 2017 22:46:15 +0200")
Message-ID: <87zidqq0n3.fsf@rosalinde>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

--=-=-=
Content-Type: text/plain

On Thu, 01 Jun 2017 22:46:15 +0200 Stephen Berman <stephen.berman@HIDDEN> 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:


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline
Content-Description: previous-line-or-history-element patch

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.

--=-=-=
Content-Type: text/plain


Steve Berman

--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#27191: 26.0.50; Long history items in minibuffer (again)
Resent-From: Stephen Berman <stephen.berman@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 02 Jun 2017 21:18:01 +0000
Resent-Message-ID: <handler.27191.B27191.14964382562760 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 27191 <at> debbugs.gnu.org
From: Stephen Berman <stephen.berman@HIDDEN>
References: <874lvzh1wo.fsf@rosalinde> <87zidqq0n3.fsf@rosalinde>
Date: Fri, 02 Jun 2017 23:17:24 +0200
In-Reply-To: <87zidqq0n3.fsf@rosalinde> (Stephen Berman's message of "Fri, 02
 Jun 2017 10:01:04 +0200")
Message-ID: <87y3tanl7f.fsf@rosalinde>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

On Fri, 02 Jun 2017 10:01:04 +0200 Stephen Berman <stephen.berman@HIDDEN> wrote:

> On Thu, 01 Jun 2017 22:46:15 +0200 Stephen Berman <stephen.berman@HIDDEN> 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

Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.