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: Sat, 06 Feb 2016 02:52:18 +0200 Organization: LINKOV.NET Message-ID: <878u2yps6d.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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1454721271 24545 80.91.229.3 (6 Feb 2016 01:14:31 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Feb 2016 01:14:31 +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 Sat Feb 06 02:14:14 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 1aRrS0-0002N8-B5 for geb-bug-gnu-emacs@m.gmane.org; Sat, 06 Feb 2016 02:14:12 +0100 Original-Received: from localhost ([::1]:51186 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRrRw-00045y-C3 for geb-bug-gnu-emacs@m.gmane.org; Fri, 05 Feb 2016 20:14:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40767) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRrRr-00044A-UX for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 20:14:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRrRq-0004gm-VN for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 20:14:03 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:54596) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRrRq-0004gi-Sn for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 20:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84) (envelope-from ) id 1aRrRq-0004zq-Q2 for bug-gnu-emacs@gnu.org; Fri, 05 Feb 2016 20:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 06 Feb 2016 01:14:02 +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.145472121719150 (code B ref 22544); Sat, 06 Feb 2016 01:14:02 +0000 Original-Received: (at 22544) by debbugs.gnu.org; 6 Feb 2016 01:13:37 +0000 Original-Received: from localhost ([127.0.0.1]:34948 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRrRR-0004yo-Af for submit@debbugs.gnu.org; Fri, 05 Feb 2016 20:13:37 -0500 Original-Received: from sub3.mail.dreamhost.com ([69.163.253.7]:33652 helo=homiemail-a76.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRrRP-0004yf-LD for 22544@debbugs.gnu.org; Fri, 05 Feb 2016 20:13:36 -0500 Original-Received: from homiemail-a76.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTP id BD16245807C; Fri, 5 Feb 2016 17:13:34 -0800 (PST) Original-Received: from localhost.linkov.net (62.65.227.106.cable.starman.ee [62.65.227.106]) (Authenticated sender: jurta@jurta.org) by homiemail-a76.g.dreamhost.com (Postfix) with ESMTPA id F25B445807B; Fri, 5 Feb 2016 17:13:33 -0800 (PST) In-Reply-To: <83h9hnv5xz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Feb 2016 11:53:44 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (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:112539 Archived-At: >> >> 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. OK, will do this together with the second part once we'll find out how to do it. >> >> 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. 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. So maybe 1 is not that bad after all to lose the least.