Received: (at 27191) by debbugs.gnu.org; 2 Jun 2017 21:17:36 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 02 17:17:36 2017
Received: from localhost ([127.0.0.1]:51975 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1dGtwt-0000iS-VT
for submit <at> debbugs.gnu.org; Fri, 02 Jun 2017 17:17:36 -0400
Received: from mout.gmx.net ([212.227.15.15]:49974)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stephen.berman@HIDDEN>) id 1dGtwq-0000iD-Be
for 27191 <at> debbugs.gnu.org; Fri, 02 Jun 2017 17:17:34 -0400
Received: from rosalinde ([83.135.25.240]) by mail.gmx.com (mrgmx002
[212.227.17.190]) with ESMTPSA (Nemesis) id 0MZCUG-1dbjeT109c-00KufP for
<27191 <at> debbugs.gnu.org>; Fri, 02 Jun 2017 23:17:25 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
To: 27191 <at> debbugs.gnu.org
Subject: Re: bug#27191: 26.0.50; Long history items in minibuffer (again)
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
X-Provags-ID: V03:K0:pSJYWK4e1ZZ1POOpf7UClnl3mQZwjaWzboKCqTFhTt+7qQlL+Dh
HvEuyr7nZQ6Tx+1a15UKis3BFXm1NHakk5DUA1VIPBFEgvKoErpmy50rVEyLPvTQ5yP5JXO
K1K7J3KR3m4M3LXE9bLQ4Gk5bthIjcxQGY0lDM1GESAVYT87/LGZ/ICdOQl9ordP8mApXAB
4p2I631RPZGAJHRX05ZRg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:O0XS17Oa+Jo=:QRXDDnd3cC7Ve62arDmUjv
jLZglFOzrZY0N0LnC10BU0x94ZSSt9rOtCOQoVrsEUatdhAQDeM8MOHIs7nBQchJmpW+sCmKz
owgVZXKWKq3/5u7/kSh7Ix31XJ+6KBdmvFsWOdKnBR1o8cDfvYsXmwRYxsanZObmAAk1gz9gi
3StOvKUK45YeAhCFkqg4fRP2iZ5U/mTlc0/nuOuZD1NFAfjjM2EXK5DhSrW2uilroPq7KGtlr
u0rBcGbmweAQh6Mf/wuwHF7NZqMrkLprKmMD5UlGN+YvSzdpeZ7srP9alYgf+gYsrVfkWLJWa
r2GNpomZEwTyl5TJoOIKZ+xp9BNm/cVCssM56fRkE6DCyd123hOg+VzzLPeVvzOdDYCUkVAcG
HpUBGbQ/KeHpfnMvbJ2q2jUp/HA77rIFM9WJt6Un0RKIKzEMppm0T5BgfLeBJSMH1k2CfM/Qy
8yzl+Vgy3KWUso5b3+EZlwDmcWa8wriTF3L9suUw6L9hxJ+qrnTWDEN/IilvGG2XeFIz02qpQ
Jzu0J+T8T4eRnp+K8LEBBuUOOqZky2QHWNtI/6n9UR5hDfHit/HFvgNeXpVxbSJ+JQT1n+jGX
vf1s4xC0l7rg99nb+r0aywmP+yhXjkGCnJ3xRqZiGyoYQ8Kta7LH219Q1pclMT09zn5dTnnIo
H4RMuKaVZYyzfV3eoYoeV8uHISyR80/ynYOuJk9NLXY7zXIM2a+x/kqvjXjRjN8aza4lVzlyV
b9MbbySG6Ubas7pACOBPAMK/VPx/r/sil0UGf/abkKn7ysZCwGXq6fy/CZ3adL9xoS7hApl70
2rthoKm
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 27191
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.0 (---)
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
bug-gnu-emacs@HIDDEN:bug#27191; Package emacs.
Full text available.
Received: (at 27191) by debbugs.gnu.org; 2 Jun 2017 08:01:14 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Jun 02 04:01:14 2017
Received: from localhost ([127.0.0.1]:50395 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1dGhWE-0003ab-4k
for submit <at> debbugs.gnu.org; Fri, 02 Jun 2017 04:01:14 -0400
Received: from mout.gmx.net ([212.227.15.19]:57219)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stephen.berman@HIDDEN>) id 1dGhWC-0003aO-Ij
for 27191 <at> debbugs.gnu.org; Fri, 02 Jun 2017 04:01:13 -0400
Received: from rosalinde ([83.135.25.240]) by mail.gmx.com (mrgmx001
[212.227.17.190]) with ESMTPSA (Nemesis) id 0LdpcB-1dhXl42MxH-00iyKl for
<27191 <at> debbugs.gnu.org>; Fri, 02 Jun 2017 10:01:05 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
To: 27191 <at> debbugs.gnu.org
Subject: Re: bug#27191: 26.0.50; Long history items in minibuffer (again)
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="=-=-="
X-Provags-ID: V03:K0:/ebnoWIaNSz5LkmWdX8JV0SOgd5Q2pyIxGvqnQ37pFMLRqBVXD6
DFADPvMdskmyhELUQ5To0Z/vDgvymW2e/jCw/jGRqiEpEOsURC9a4T2aDBS4KPw0oaw2WKn
EysZbGkXMlQ8/BbVMwcSaNVtS/1iAKobkkp9yOAbowUzsIYE7sfe4mSG/zLQEKT5chsTfIt
+yHu7eoeXjy/cB0ysWb2g==
X-UI-Out-Filterresults: notjunk:1;V01:K0:A16NIp3TEgU=:hcnKNa4Ud/ah0VUJlKrfyj
VI6nDJh9EBu5K7fAAje80EtilDE/fEQdiVEKcPfE2WVO8WW4csLje38uCgFqX+7qZTd1Fz9X1
gQXHT4VdLPb4P/bhqY470bH4zi7qoUgqRTQj7DkeZZuxU75OG/PZKe6RH8UWglqBUc0nWXFqG
ZDJyS2p4oZNN08vF13fr1THYNhmvx/mmEERoyls6J6TNG44b43xf+uGkj9GQaORxgZKeBMg1a
N+nBOaidKUtJtWW5lyUdnPapMgs2ZlihDNkJ2ZeZ4jF4pNljwBoXQiAuDReTQNlCrGNDPRiLK
eoklTBtevGJSTpqFHmKI0GNdvwNUT01jhu8CImqPL/Eikf5irIIS6BMB6Mo8Rii1ZHj5IRqt+
BrpIO8c3ZFOFlu81nm568f4inos741a78zYqmHjHwnB1SFAHXLqDKpoL3A/VC8gNPKzPie6bQ
F9Z6d0q7I/+/GFkDP1JVpSE4C5LKBcGmGutshU6ZSt/hzeC8hXsVEwNGpVP3flnJ6FNVbkxz9
vW3UKgRq+9SMXmbRCVXeVROsCWnMJHkPlhy6HiLiotJBherxpItBSBM9qRzI997gP7n+lXNty
Z5AfSLfTvwpjyF6napgWmg27wu6s//e3r0/771+gYjOLeISO8a+RtJ9gf9W3QbuYdtBq32Aht
at5l1WIqoEy9X3FRql2T/z6kolvyBRgapXtf1QZEqEwZSsCEIDxCE2YvpGUmb53HuwFJtzbO5
3J0gzlClDzXpOvnupVtX+LRtLp4qcVNsCi48Jbr5GaFt9pmkY7T0TOLmIMc=
X-Spam-Score: -3.0 (---)
X-Debbugs-Envelope-To: 27191
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.0 (---)
--=-=-=
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
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#27191; Package emacs.
Full text available.
Received: (at submit) by debbugs.gnu.org; 1 Jun 2017 20:46:34 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 01 16:46:34 2017
Received: from localhost ([127.0.0.1]:50022 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1dGWzJ-0007qq-Tx
for submit <at> debbugs.gnu.org; Thu, 01 Jun 2017 16:46:34 -0400
Received: from eggs.gnu.org ([208.118.235.92]:52222)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stephen.berman@HIDDEN>) id 1dGWzH-0007qe-9x
for submit <at> debbugs.gnu.org; Thu, 01 Jun 2017 16:46:32 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stephen.berman@HIDDEN>) id 1dGWzA-0000ei-KF
for submit <at> debbugs.gnu.org; Thu, 01 Jun 2017 16:46:26 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM,
RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:37092)
by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
(Exim 4.71) (envelope-from <stephen.berman@HIDDEN>)
id 1dGWzA-0000ec-H3
for submit <at> debbugs.gnu.org; Thu, 01 Jun 2017 16:46:24 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:43171)
by lists.gnu.org with esmtp (Exim 4.71)
(envelope-from <stephen.berman@HIDDEN>) id 1dGWz8-0007SW-RR
for bug-gnu-emacs@HIDDEN; Thu, 01 Jun 2017 16:46:24 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
(envelope-from <stephen.berman@HIDDEN>) id 1dGWz5-0000cv-LZ
for bug-gnu-emacs@HIDDEN; Thu, 01 Jun 2017 16:46:22 -0400
Received: from mout.gmx.net ([212.227.15.15]:60717)
by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16)
(Exim 4.71) (envelope-from <stephen.berman@HIDDEN>)
id 1dGWz5-0000cE-AS
for bug-gnu-emacs@HIDDEN; Thu, 01 Jun 2017 16:46:19 -0400
Received: from rosalinde ([83.135.25.157]) by mail.gmx.com (mrgmx003
[212.227.17.190]) with ESMTPSA (Nemesis) id 0MX1dc-1dLuG402E8-00Vvx0 for
<bug-gnu-emacs@HIDDEN>; Thu, 01 Jun 2017 22:46:16 +0200
From: Stephen Berman <stephen.berman@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 26.0.50; Long history items in minibuffer (again)
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="=-=-="
X-Provags-ID: V03:K0:+Ew1LLOha+Zitq6Q8/j7q6QQq9PiZVoALgyhnJXvNS/UB70tAdv
m67O992qC+FntYQ+Nfci1t7eA+YwCfY19Bi2JPoZdALIOzQrbDJ1SrIKttWObY9/gYaxI2T
D8cmSeCFbPdsxKDpCvHK7PORrg4BjY/neIWLRmQMZrpfMOoopBG3gwdYVHvMJuvYdCOh1cY
L9wB49RUIJCmisw7w0xjg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:EJaViKljWzk=:CeZIAyBtMt9qLyAnwepp1v
omUJ9snAwV84ucRr5czE8+DqN7aNeJtU4blVZ4J4HQ65oAGaN1fluhFpEc+9O+4rV4rh3M2rC
6d28J/OKXKD8JmGae6OgWArPlUsNcvffuyduCrvVbMnzzoJpmhUI7Rbqo1FhpMQ7+HMnjWN6U
XOfiwpAgiNfAbS0nmgtviT9W7O6iZeNcEE8lD2dgQkjAQQdEChhb53dVTRfB108vM1N0Jv6z3
vre4h8+jWDDxQqETqkGg/KTE6Y2Y8iqdZKjt7EuoaAL6Ms73ShCdiRR1sbUY1PEag/mtXK6e5
Wp3PcVNxE4tDasFATCar4O9Fm/xVleoZvIYwuPgn4XBg3FTs0ySO89Hb7H7wZai3VI4A2cSJh
w0AhKNf4aj74dZ2IWvK6FeEYbyeOGbb4aFJIlJWVk9YmA5DFRBQrcS1cE3KZGB/at3/HaUPxY
mfBAN/h2dMdV2wMZpdzo8PNdsL5TgIKTptljHacS6+HG5f5tbVGkpoCDPWKIwyhx3Rl0j85KU
czK219PgLCO37MIRd0urwcN4jNIcezQSboODGdnG7jrm+uBPc3fUHe/HmBe6zBsF3U6x+juym
UHm12FohYmCxBcnR4Io2ezlJ8W6vd7LMk9VpaFeKCPri0ARaISEOFRNFyCPi53y8tB1otuO4R
fLnFxACCtwUMn3Wv/34dtQhzn+txSOmnJb9kNoHtRyRz8lUGVtEVIA0X7GTR12Y+Sdg6fTTq8
9xOggmPGB8JtlV1Ix3dhfuwzccjX/ElM+KPxTe+2NbnM0rMI+VBxEfo0y4k=
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
[fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -3.6 (---)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.6 (---)
--=-=-=
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.
--=-=-=--
Stephen Berman <stephen.berman@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#27191; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.