From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Date: Sun, 07 Feb 2016 02:49:15 +0200 Organization: LINKOV.NET Message-ID: <87wpqh498k.fsf@mail.linkov.net> References: <83a8nhycsl.fsf@gnu.org> <87d1sd1du7.fsf@mail.linkov.net> <831t8sxwvs.fsf@gnu.org> <87fux82bp7.fsf@mail.linkov.net> <83h9hnv5xz.fsf@gnu.org> <878u2yps6d.fsf@mail.linkov.net> <83k2mith70.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454807541 10047 80.91.229.3 (7 Feb 2016 01:12:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 7 Feb 2016 01:12:21 +0000 (UTC) Cc: 22544@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Feb 07 02:12:10 2016 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1aSDtZ-0008UB-Ls for geb-bug-gnu-emacs@m.gmane.org; Sun, 07 Feb 2016 02:12:09 +0100 Original-Received: from localhost ([::1]:58083 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSDtY-0001bp-Iy for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Feb 2016 20:12:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60916) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSDtV-0001bX-9W for bug-gnu-emacs@gnu.org; Sat, 06 Feb 2016 20:12:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSDtS-0007mp-2J for bug-gnu-emacs@gnu.org; Sat, 06 Feb 2016 20:12:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:55828) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSDtR-0007mh-Uy for bug-gnu-emacs@gnu.org; Sat, 06 Feb 2016 20:12:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aSDtR-00012u-QK for bug-gnu-emacs@gnu.org; Sat, 06 Feb 2016 20:12:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 07 Feb 2016 01:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22544 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 22544-submit@debbugs.gnu.org id=B22544.14548074773969 (code B ref 22544); Sun, 07 Feb 2016 01:12:01 +0000 Original-Received: (at 22544) by debbugs.gnu.org; 7 Feb 2016 01:11:17 +0000 Original-Received: from localhost ([127.0.0.1]:36184 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSDsj-00011x-Kh for submit@debbugs.gnu.org; Sat, 06 Feb 2016 20:11:17 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:58354 helo=homiemail-a19.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSDsh-00011p-LZ for 22544@debbugs.gnu.org; Sat, 06 Feb 2016 20:11:16 -0500 Original-Received: from homiemail-a19.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTP id 0C667604069; Sat, 6 Feb 2016 17:11:14 -0800 (PST) Original-Received: from localhost.linkov.net (62.65.224.80.cable.starman.ee [62.65.224.80]) (Authenticated sender: jurta@jurta.org) by homiemail-a19.g.dreamhost.com (Postfix) with ESMTPA id 42701604061; Sat, 6 Feb 2016 17:11:13 -0800 (PST) In-Reply-To: <83k2mith70.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Feb 2016 09:45:55 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (x86_64-pc-linux-gnu) 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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:112586 Archived-At: >> >> 1. Put the cursor at the end of the top visual line, not logical line. >> >> Drawback: the cursor will be in the middle of the logical line. >> >> >> >> 2. Go to the previous history element when the cursor is anywhere >> >> on any of the several visual lines of the top logical line, >> >> not just the top visual line. >> >> Drawback: can't move the cursor to the top visual line to edit text in it. >> >> >> >> 3. When moving the cursor from one visual line to another visual line of >> >> the logical line, keep the cursor at the end of the visual line. >> >> The problem is that this behavior should be implemented in previous-line. >> >> >> >> 4. Set temporary-goal-column like in the patch above, but instead of 0, >> >> set it to the column of the end of the top visual line, so >> >> will put the cursor at the end of the top visual line in your test case. >> > >> > 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. >> >> > If that is too hard, I guess 1 is the second best. (I'm not really >> > sure how 1 is different from 4, so maybe I actually mean 4 here.) >> >> 4 doesn't allow to navigate to the next previous element immediately >> after arriving to the current previous element. > > Sorry, I still don't understand. Can you give an example showing the > difference between 1 and 4? 4 is like 1, but requires additional keystrokes from the user to arrive to the top visual line from the end of the logical line. Whereas 1 puts the cursor at the end of the visual line immediately after . I tested the implementation of 1 below, and it seems to solve the problem: diff --git a/lisp/simple.el b/lisp/simple.el index 72e87a4..957f2f7 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -2078,7 +2078,15 @@ 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)) - (goto-char (line-end-position))))))) + ;; 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. + (unless (eolp) (backward-char 1))))))) (defun next-complete-history-element (n) "Get next history element which completes the minibuffer before the point.