From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Date: Fri, 05 Feb 2016 11:53:44 +0200 Message-ID: <83h9hnv5xz.fsf@gnu.org> References: <83a8nhycsl.fsf@gnu.org> <87d1sd1du7.fsf@mail.linkov.net> <831t8sxwvs.fsf@gnu.org> <87fux82bp7.fsf@mail.linkov.net> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1454666124 32672 80.91.229.3 (5 Feb 2016 09:55:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Feb 2016 09:55:24 +0000 (UTC) Cc: 22544@debbugs.gnu.org To: Juri Linkov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Feb 05 10:55:13 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 1aRd6f-0005t8-2P for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 10:55:13 +0100 Original-Received: from localhost ([::1]:47186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRd6b-0007gF-AQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 04:55:09 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60847) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRd6X-0007eX-Cw for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 04:55:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRd6U-0006LC-7e for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 04:55:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52469) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRd6U-0006L8-4R for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 04:55:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRd6T-0005P4-TG for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 04:55:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 05 Feb 2016 09:55: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.145466604320697 (code B ref 22544); Fri, 05 Feb 2016 09:55:01 +0000 Original-Received: (at 22544) by debbugs.gnu.org; 5 Feb 2016 09:54:03 +0000 Original-Received: from localhost ([127.0.0.1]:32825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRd5W-0005Nl-ND for submit@debbugs.gnu.org; Fri, 05 Feb 2016 04:54:02 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41512) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRd5U-0005NH-TM for 22544@debbugs.gnu.org; Fri, 05 Feb 2016 04:54:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRd5M-00069W-LO for 22544@debbugs.gnu.org; Fri, 05 Feb 2016 04:53:55 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:44903) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRd5M-00069I-Ie; Fri, 05 Feb 2016 04:53:52 -0500 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1390 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aRd5L-0007VC-15; Fri, 05 Feb 2016 04:53:51 -0500 In-reply-to: <87fux82bp7.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 05 Feb 2016 02:42:12 +0200) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] 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:112482 Archived-At: > From: Juri Linkov > Cc: 22544@debbugs.gnu.org > Date: Fri, 05 Feb 2016 02:42:12 +0200 > > >> Sorry, I don't understand: it's unexpected that the cursor jumps > >> to the previous visual line (this is because of line-move-visual), > >> or an invalid column position on the previous visual line? > > > > The latter. > > It was a bug caused by an old value of temporary-goal-column > not re-calculated in previous-line when previous-line fails > by bumping against the top of the minibuffer (and going to the previous > history element with an invalidated value of temporary-goal-column). > It can be fixed by this patch: Thanks, please commit that to emacs-25. > >> This is because it keeps the last column before navigating > >> to the previous history element. The last column was near > >> the beginning of the top visual line. > > > > But if a long line is not in history, then the cursor is not > > positioned on the same column, it is positioned at the end of the > > history item. So this behavior is inconsistent, and depends on > > whether long items are or aren't in the history. > > There are a few other possibilities for alternative behavior: > > 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. 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.) Thanks.