From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 01 16:46:34 2017 Received: (at submit) by debbugs.gnu.org; 1 Jun 2017 20:46:34 +0000 Received: from localhost ([127.0.0.1]:50022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGWzJ-0007qq-Tx for submit@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 ) id 1dGWzH-0007qe-9x for submit@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 ) id 1dGWzA-0000ei-KF for submit@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 ) id 1dGWzA-0000ec-H3 for submit@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 ) id 1dGWz8-0007SW-RR for bug-gnu-emacs@gnu.org; Thu, 01 Jun 2017 16:46:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGWz5-0000cv-LZ for bug-gnu-emacs@gnu.org; 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 ) id 1dGWz5-0000cE-AS for bug-gnu-emacs@gnu.org; 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 ; Thu, 01 Jun 2017 22:46:16 +0200 From: Stephen Berman To: bug-gnu-emacs@gnu.org 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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" 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 2. C-x C-f => 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 you type `M-p', then point is at the end of the file name in the minibuffer. This is what I expected for too. The result with 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 should > continue navigating the history and put the next previous element to the > minibuffer. But then 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 displays the previous history element. Otherwise, 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 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. --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 04:01:14 2017 Received: (at 27191) by debbugs.gnu.org; 2 Jun 2017 08:01:14 +0000 Received: from localhost ([127.0.0.1]:50395 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGhWE-0003ab-4k for submit@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 ) id 1dGhWC-0003aO-Ij for 27191@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@debbugs.gnu.org>; Fri, 02 Jun 2017 10:01:05 +0200 From: Stephen Berman To: 27191@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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) --=-=-= Content-Type: text/plain On Thu, 01 Jun 2017 22:46:15 +0200 Stephen Berman wrote: > 0. emacs -Q > 1. C-x C-f > ~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed > > 2. C-x C-f > => 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 you type `M-p', then point is at the end of > the file name in the minibuffer. This is what I expected for too. > > The result with 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 should >> continue navigating the history and put the next previous element to the >> minibuffer. But then 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 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 02 17:17:36 2017 Received: (at 27191) by debbugs.gnu.org; 2 Jun 2017 21:17:36 +0000 Received: from localhost ([127.0.0.1]:51975 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGtwt-0000iS-VT for submit@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 ) id 1dGtwq-0000iD-Be for 27191@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@debbugs.gnu.org>; Fri, 02 Jun 2017 23:17:25 +0200 From: Stephen Berman To: 27191@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@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.0 (---) On Fri, 02 Jun 2017 10:01:04 +0200 Stephen Berman wrote: > On Thu, 01 Jun 2017 22:46:15 +0200 Stephen Berman wrote: > >> 0. emacs -Q >> 1. C-x C-f >> ~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed >> >> 2. C-x C-f >> => 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 you type `M-p', then point is at the end of >> the file name in the minibuffer. This is what I expected for too. >> >> The result with 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 should >>> continue navigating the history and put the next previous element to the >>> minibuffer. But then 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 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 From debbugs-submit-bounces@debbugs.gnu.org Mon Aug 24 10:38:15 2020 Received: (at 27191) by debbugs.gnu.org; 24 Aug 2020 14:38:15 +0000 Received: from localhost ([127.0.0.1]:58794 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kADbz-0001oD-2r for submit@debbugs.gnu.org; Mon, 24 Aug 2020 10:38:15 -0400 Received: from quimby.gnus.org ([95.216.78.240]:58494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kADbx-0001o0-SW for 27191@debbugs.gnu.org; Mon, 24 Aug 2020 10:38:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=bnrEmDp4IOnIrB3oYvB+ZjrP64Ftz/tcdjRftVR45PE=; b=CKHxqz/bEK4uy8m2A2AP6yngrF iHKDeyVtHV29yt9C6mH/mdcvZnTw3CufsGVC08ApCXQrVwQ4vf8SLSmMKwH6FF+ZU/c8WUyW5MPHM 7naZGVyHKWzp2PEtaYPk3ZsIF1Qg6Ruponmpp38tY52D+OTycywBPaOCX1x/+uz1cAZY=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kADbo-0007XQ-74; Mon, 24 Aug 2020 16:38:07 +0200 From: Lars Ingebrigtsen To: Stephen Berman Subject: Re: bug#27191: 26.0.50; Long history items in minibuffer (again) References: <874lvzh1wo.fsf@rosalinde> X-Now-Playing: Sevdaliza's _ISON_: "Amandine Insensible" Date: Mon, 24 Aug 2020 16:38:02 +0200 In-Reply-To: <874lvzh1wo.fsf@rosalinde> (Stephen Berman's message of "Thu, 01 Jun 2017 22:46:15 +0200") Message-ID: <87ft8c9kj9.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stephen Berman writes: > 0. emacs -Q > 1. C-x C-f > ~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed > > 2. C-x C-f > => The file name entered in step 1 appears in the minibuffer [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 27191 Cc: 27191@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stephen Berman writes: > 0. emacs -Q > 1. C-x C-f > ~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed > > 2. C-x C-f > => 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 you type `M-p', then point is at the end of > the file name in the minibuffer. This is what I expected for too. Yes, that's really confusing. I do get a different result than you, though -- point is placed inside the "Find file" prompt when I hit . :-/ That's even worse. > 2017-06-01 Stephen Berman > > 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. > Your change makes sense, I think, but when I tried applying the two patches, they no longer applied to Emacs 28, so I couldn't give it a try. Could you possibly respin the patches? -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 14:01:58 2020 Received: (at 27191) by debbugs.gnu.org; 25 Aug 2020 18:01:58 +0000 Received: from localhost ([127.0.0.1]:35966 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAdGf-0003Kj-MQ for submit@debbugs.gnu.org; Tue, 25 Aug 2020 14:01:58 -0400 Received: from mout.gmx.net ([212.227.15.15]:38985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAdGd-0003KU-LT for 27191@debbugs.gnu.org; Tue, 25 Aug 2020 14:01:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1598378509; bh=at5x4znFVpkJPj0kc9AcuxMhi1hnqTAIvtBijFMi988=; h=X-UI-Sender-Class:From:To:Cc:Subject:References:Date; b=Le3vlQfJ98BpzN9fckl+QF00Xei/rikR+X/5coiUzNrFIo27ED9zSqfKyyU1qhBfp Hk0WmdRbPoL15YNO9SoA7r4+/otRoAXU+jtXZYgTYTF4dx11eQTTgt45RZS2Zbkb3N zjE31w1xieKgB464U3Pv2r1X+u4f5noV4RS7FoUA= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from strobe-jhalfs ([188.109.196.40]) by mail.gmx.com (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MV67o-1k1Fd43c7q-00S39f; Tue, 25 Aug 2020 20:01:49 +0200 From: Stephen Berman To: Lars Ingebrigtsen Subject: Re: bug#27191: 26.0.50; Long history items in minibuffer (again) References: <874lvzh1wo.fsf@rosalinde> <87ft8c9kj9.fsf@gnus.org> Date: Tue, 25 Aug 2020 20:01:47 +0200 Message-ID: <87bliyli44.fsf@gmx.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Provags-ID: V03:K1:lNhOZXX8JaHX8V1G+Vp8+gFzDbeB7psrcDhFTGerxtQ3X8XCLWS LAyVjW+XggAenjENgJ/SSug+E75aMji6GzqYZBuqwf/hUEwAf4DlilnRDxBQQ4GxP7sEZxG JXP1tnC2uK05ynQqzyMmgLP7ukPe0MzM3TTI9UI6Lo4POJdAxg5nqxhHBbeUibnsc896irw 4RZssexXtM/KvAMzuy3jA== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:X4ksLXVRZYY=:47/zhh/1pi1SGYNj7dpBLW joJKWfVTWyXifvodAgj7L68+m7W8xtd39z9oXzZRei43LkwGirm/347svvupAL8PhcsTz+sEQ Uys5SkV5okYLOrmUtSo6OR1kfxtR8bPBzHbxLNAdR7ODOCrWNmiBI/o47IkIy2ZvPIe6gT+QB OycoANsQ8MkD2PCPogicAkSliFrAgqzbA2xmbxb/gWoo4UEHmvufBRdzAEmuhpXVYDuXomQuY 15HC2c3BwaoCPkOyy6HWlsOMhM12GOxCOwLyIdKcnYbg85pi48Xlu9rKqKivhghATvnuabn4R LtETRxRyL70RYtQC4D+OooVQ3Aej+eMfqg4tKGt2sl0ZVtX2IST+K2XF7bPQzbJxupb1hJWce /WW8FuepECp3U8ymZkXguo8eR8dNVSAza2+XERcXMedVIvdBt1BqzCcrBbyfr6B9V98YmNZlV Rzp6x5nW8jY1ROiOh1jWzwu+fKDO8LIuIuL/nVXIRi9dR4aDT7LP52JGZyCbJ1iTXBpO40y4Y 5NRieXDLsFbvIvlI6gV0afE0pnicGrT4dHu1QN4ss5dlUAw1PMG1t4y96y67wpqskMOm9oGKt wB+enZ2jEdtK20lTIIORPzBPT5Y52RHVqyPgwmnM/WzFVA21NW8vlh28T+WnGZwzpyRclv32M ow00tsKlLyCWwf+o2GOvHqMnhJ9m4eoCn3560dmU20yzZuHR5lVsa4kqczJYySkotJObmBcVK bYfo9XCc8pEhYeqXVNQSGWllvyudX6iG548VXXBETOCpMGzk8d2SJ1P7hkwOHBT0hinZ934w1 VFkQy50kVKdHHYr+sxPBUtf2VFFK3/9EBlVG/VYc6q7PA6UpgADJIbOyCQWgF9eO/Lnnz3BJo Iesc1sOJRj/oUzbPQlDetMC6h+X+4LzS3A8WbYhZ1xP6nOn2gTQykb8l48Suejq4JPrvJtTbq q37AvaEp1r7m4DMO1HiLiYkxtkXvhINgt+vappROsF7J5QUmO6U0REWj2ujFayg0jgVoOCMgB bpXlyj5+MVUs0po3xZIRXLA2uYaYRB2QAmp4a2pPp71RpWsaQvQPbH14nFEUWGwPZy6j0Tvcx R9e975+p+Jo675McBaf2JtiIcBUBRLjrCE3QHa9EjXVbZT4Y7ygEOLVUMgmpr987hHAZZQknE 3dUB8Ck2xa8ssHXdJvgbG0hU5HN4aSuny/+2eH9gDV5vOyEQlT/66Jqo9W7N4fVtLMD71j2fp FVkjBCyc3RNYNcW6piArBIyc4chhbXWjsYJfDNg== X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 27191 Cc: 27191@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) --=-=-= Content-Type: text/plain On Mon, 24 Aug 2020 16:38:02 +0200 Lars Ingebrigtsen wrote: > Stephen Berman writes: > >> 0. emacs -Q >> 1. C-x C-f >> ~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed >> >> 2. C-x C-f >> => 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 you type `M-p', then point is at the end of >> the file name in the minibuffer. This is what I expected for too. > > Yes, that's really confusing. I do get a different result than you, > though -- point is placed inside the "Find file" prompt when I hit > . :-/ That's even worse. I see that too, now. That's because at step 2 the current buffer is the one made in step one, so after the prompt includes all parent directory names. When, after step 1, I switch to another buffer and then do step 2, I see what I reported. I don't know if I accidentally left out that intermediate step in my OP or if the behavior has changed since then. As an alternative, replacing all the slashes by dashes, so it's just a long file name in ~/, and doing step 2 also puts point at the end of the visual line. >> 2017-06-01 Stephen Berman >> >> 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. >> > > Your change makes sense, I think, but when I tried applying the two > patches, they no longer applied to Emacs 28, so I couldn't give it a > try. Could you possibly respin the patches? Thanks for taking a look at this. Here are the changes adjusted to apply to current master: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Description: patch 1 Content-Transfer-Encoding: quoted-printable diff --git a/lisp/simple.el b/lisp/simple.el index fa6e154004..96b56815cd 100644 =2D-- a/lisp/simple.el +++ b/lisp/simple.el @@ -2355,7 +2355,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))) + (=3D (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. @@ -2396,7 +2405,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))) + (=3D (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 l= ine. @@ -2416,17 +2434,14 @@ previous-line-or-history-element (goto-char (1- (minibuffer-prompt-end))) (current-column)))) (move-to-column old-column)) - (if (not line-move-visual) ; Handle logical lines (bug#42862) - (end-of-line) - ;; 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 uppe= r - ;; visual line from the end of logical line in `line-move-visual' mod= e. - (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 regardless of the value of + ;; `line-move-visual'. + (end-of-line))))))) (defun next-complete-history-element (n) "Get next history element that completes the minibuffer before the poin= t. --=-=-= Content-Type: text/plain This patch also subsumes the recent change to fix bug#42862. While this seems to work well for file-name-history and buffer-name-history, whose elements typically don't contain a line feed character, that's not the case for e.g. extended-command-history: the above changes don't actually test that the history element consists of a *single* line longer than window-width, but only whether the *first* line of the element was longer than window-width. So if the element contains two or more such lines, as in: M-: (setq bla "A long long long long long long long long long long long long long long long value" bli "Another long long long long long long long long long long long long long long long value") moves by visual lines through the lower ones but by logical lines through the top one, which seems wrong. I tried to accommodate such cases, and came up with this: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Description: patch 2 Content-Transfer-Encoding: quoted-printable diff --git a/lisp/simple.el b/lisp/simple.el index fa6e154004..c2b55997b4 100644 =2D-- a/lisp/simple.el +++ b/lisp/simple.el @@ -2355,7 +2355,21 @@ 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. + (let ((beg (save-excursion + (goto-char (point-min)) + (line-number-at-pos))) + (end (save-excursion + (goto-char (point-max)) + (line-number-at-pos)))) + (if (or (=3D beg end) + (and (=3D (line-end-position) (buffer-end 1)) + (> (current-column) (window-width)))) + (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. @@ -2396,7 +2410,21 @@ 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. + (let ((beg (save-excursion + (goto-char (point-min)) + (line-number-at-pos))) + (end (save-excursion + (goto-char (point-max)) + (line-number-at-pos)))) + (if (or (=3D beg end) + (and (=3D (line-beginning-position) (buffer-end -1)) + (> (current-column) (window-width)))) + (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 l= ine. @@ -2416,17 +2444,14 @@ previous-line-or-history-element (goto-char (1- (minibuffer-prompt-end))) (current-column)))) (move-to-column old-column)) - (if (not line-move-visual) ; Handle logical lines (bug#42862) - (end-of-line) - ;; 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 uppe= r - ;; visual line from the end of logical line in `line-move-visual' mod= e. - (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 regardless of the value of + ;; `line-move-visual'. + (end-of-line))))))) (defun next-complete-history-element (n) "Get next history element that completes the minibuffer before the poin= t. --=-=-= Content-Type: text/plain With this, and move by visual lines through multline history elements like the above example, and then on the first line or on the last brings up the next history element. But going back and forth between history elements changes the goal-column when the elements have different lengths. In fact, the current implementations of next-line-or-history-element and previous-line-or-history-element have the same problem. This can be prevented by setting goal-column: --=-=-= Content-Type: text/x-patch Content-Disposition: attachment Content-Description: patch 2 Content-Transfer-Encoding: quoted-printable diff --git a/lisp/simple.el b/lisp/simple.el index fa6e154004..228924f65a 100644 =2D-- a/lisp/simple.el +++ b/lisp/simple.el @@ -2355,7 +2355,24 @@ 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. + (let ((beg (save-excursion + (goto-char (point-min)) + (line-number-at-pos))) + (end (save-excursion + (goto-char (point-max)) + (line-number-at-pos))) + (col (save-excursion + (goto-char (minibuffer-prompt-end)) + (current-column)))) + (if (or (=3D beg end) + (and (=3D (line-end-position) (buffer-end 1)) + (> (current-column) (window-width)))) + (progn (setq goal-column col) (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. @@ -2396,7 +2413,24 @@ 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. + (let ((beg (save-excursion + (goto-char (point-min)) + (line-number-at-pos))) + (end (save-excursion + (goto-char (point-max)) + (line-number-at-pos))) + (col (save-excursion + (goto-char (minibuffer-prompt-end)) + (current-column)))) + (if (or (=3D beg end) + (and (=3D (line-beginning-position) (buffer-end -1)) + (> (current-column) (window-width)))) + (progn (setq goal-column col) (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 l= ine. @@ -2416,17 +2450,14 @@ previous-line-or-history-element (goto-char (1- (minibuffer-prompt-end))) (current-column)))) (move-to-column old-column)) - (if (not line-move-visual) ; Handle logical lines (bug#42862) - (end-of-line) - ;; 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 uppe= r - ;; visual line from the end of logical line in `line-move-visual' mod= e. - (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 regardless of the value of + ;; `line-move-visual'. + (end-of-line))))))) (defun next-complete-history-element (n) "Get next history element that completes the minibuffer before the poin= t. --=-=-= Content-Type: text/plain However, setting goal-column disables line-move-visual, so and only move by logical lines through the multiline elements. I also tried let-binding goal-column instead of setting it, but that had no effect, i.e., same as the second patch above. One difference between navigating through file-name-history or buffer-name-history and navigating through extended-command-history is that with the former, points is always at the end of the history element (with my proposed change, otherwise at least at the end of a visual line), while with the latter, point starts out at the beginning of the history element. The goal-column problem seems likely to be related to this difference, but I currently don't have a solution for it. So until someone comes up with one, it may be best to stick with the status quo. Steve Berman --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Aug 25 15:17:59 2020 Received: (at 27191) by debbugs.gnu.org; 25 Aug 2020 19:17:59 +0000 Received: from localhost ([127.0.0.1]:36161 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAeS1-0001Dd-Mq for submit@debbugs.gnu.org; Tue, 25 Aug 2020 15:17:59 -0400 Received: from quimby.gnus.org ([95.216.78.240]:44914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kAeRz-0001DP-4k for 27191@debbugs.gnu.org; Tue, 25 Aug 2020 15:17:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=7qkV3fOat3AFn7cLFZ2BTyzjFXVnBbDHeW7Hq/m2DgQ=; b=Cj14raZXkx3r2g4YFUhQHObwv7 seQRIRAw8RKkWTGrcBHr7RQYSJCrzSzjSD2zO4OYuJ1z8WPoKGYi842uZ87te3YoNycViGWdjjBQs VwPLXtTIAEqRPGU1MNS32g3zb40Q9/wO2CDVAht+pLXmWPDNUl/To8xsXokXerq6AXXo=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kAeRq-0000zq-Lr; Tue, 25 Aug 2020 21:17:37 +0200 From: Lars Ingebrigtsen To: Stephen Berman Subject: Re: bug#27191: 26.0.50; Long history items in minibuffer (again) References: <874lvzh1wo.fsf@rosalinde> <87ft8c9kj9.fsf@gnus.org> <87bliyli44.fsf@gmx.net> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAABGdBTUEAALGPC/xhBQAAACBj SFJNAAB6JgAAgIQAAPoAAACA6AAAdTAAAOpgAAA6mAAAF3CculE8AAAAFVBMVEUBAgEnMS1UYls4 SkKcp514hnz///9NkLG6AAAAAWJLR0QGYWa4fQAAAAd0SU1FB+QIGRMLBz+Q8aEAAAF8SURBVDjL vZNBcoMwDEVJMt1jfAGQ0D6WcoBOxuxbat//Kv0Q7ISZtJNu+pmxwc/Slww0zX+p3T8etvloPb2P iT4uzWDHvqO3suHc9722PZ1a0nPnaNhA13+6i7qhG9qRqBtUNuADnTyRtNx47s50OlaztvlVBwet wzPgnoPg/PNUP3mEF0+qevp1MLMNECQxxplW5TxXkDPW43QDJAWoDC4thEpIieCDlyw53fZTmmoq 55W17JdYQSIODsVIXhXj1lfOREqmSJ6nRxABxjiniAqmKcodoM6J1rriiipYlGNR2gN6Bq4JNhLv 2sC0gjBeDW3w0ssG5EpsyhIzfNNEJaLxRgOAjnJFETtwYTKciZnuTtf57kvVNH55ZyrVAxHIg5gE L1xKcwU3KSnPLDKXCLu96IUwAmBWwCaCe6AlcQVwYGMKhqlDk3ewlMlmeFsBm+jBHJmNB7eyChZr LKN/3AFw+eBKUUscgFZQlmG1B4fyn59C69oXP/g/6Bv0wWzDJd3VcAAAABBlWElmSUkqAAgAAAAA AAAAAAAAAJw8uSgAAAAldEVYdGRhdGU6Y3JlYXRlADIwMjAtMDgtMjVUMTk6MTE6MDcrMDA6MDBa KVdIAAAAJXRFWHRkYXRlOm1vZGlmeQAyMDIwLTA4LTI1VDE5OjExOjA3KzAwOjAwK3Tv9AAAAABJ RU5ErkJggg== X-Now-Playing: Tuxedomoon's _Live in San Francisco (1979)_: "7 Years" Date: Tue, 25 Aug 2020 21:17:33 +0200 In-Reply-To: <87bliyli44.fsf@gmx.net> (Stephen Berman's message of "Tue, 25 Aug 2020 20:01:47 +0200") Message-ID: <87sgca4jsi.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Stephen Berman writes: > So until someone comes up with one, it may be best to stick with the > status quo. Hm, yes, this looks like a difficult problem to get just right... Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 27191 Cc: 27191@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stephen Berman writes: > So until someone comes up with one, it may be best to stick with the > status quo. Hm, yes, this looks like a difficult problem to get just right... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no