From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stephen Berman Newsgroups: gmane.emacs.bugs Subject: bug#27191: 26.0.50; Long history items in minibuffer (again) Date: Fri, 02 Jun 2017 10:01:04 +0200 Message-ID: <87zidqq0n3.fsf@rosalinde> References: <874lvzh1wo.fsf@rosalinde> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Trace: blaine.gmane.org 1496390632 31869 195.159.176.226 (2 Jun 2017 08:03:52 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 2 Jun 2017 08:03:52 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux) To: 27191@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Jun 02 10:03:46 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dGhYg-0007uR-3C for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jun 2017 10:03:46 +0200 Original-Received: from localhost ([::1]:48380 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGhYj-0006Xg-PP for geb-bug-gnu-emacs@m.gmane.org; Fri, 02 Jun 2017 04:03:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52195) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dGhX6-0005IP-E7 for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 04:02:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dGhX0-0004si-Fj for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 04:02:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:47718) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dGhX0-0004sa-Bt for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 04:02:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dGhWz-0003be-UU for bug-gnu-emacs@gnu.org; Fri, 02 Jun 2017 04:02:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stephen Berman Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 02 Jun 2017 08:02:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27191 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 27191-submit@debbugs.gnu.org id=B27191.149639047413805 (code B ref 27191); Fri, 02 Jun 2017 08:02:01 +0000 Original-Received: (at 27191) by debbugs.gnu.org; 2 Jun 2017 08:01:14 +0000 Original-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 Original-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 Original-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 In-Reply-To: <874lvzh1wo.fsf@rosalinde> (Stephen Berman's message of "Thu, 01 Jun 2017 22:46:15 +0200") 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-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:133159 Archived-At: --=-=-= 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 --=-=-=--