From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 03 11:33:33 2016 Received: (at submit) by debbugs.gnu.org; 3 Feb 2016 16:33:33 +0000 Received: from localhost ([127.0.0.1]:58273 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR0N2-0004Gm-UG for submit@debbugs.gnu.org; Wed, 03 Feb 2016 11:33:33 -0500 Received: from eggs.gnu.org ([208.118.235.92]:60669) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR0N1-0004GY-C0 for submit@debbugs.gnu.org; Wed, 03 Feb 2016 11:33:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aR0Mu-0007mP-IW for submit@debbugs.gnu.org; Wed, 03 Feb 2016 11:33:26 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:42707) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR0Mu-0007mL-FZ for submit@debbugs.gnu.org; Wed, 03 Feb 2016 11:33:24 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:51588) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR0Mq-0006uv-1N for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 11:33:24 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aR0Mm-0007kG-Mn for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 11:33:19 -0500 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:32945) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aR0Mm-0007kC-Is for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 11:33:16 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3155 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aR0Ml-0006J6-UI for bug-gnu-emacs@gnu.org; Wed, 03 Feb 2016 11:33:16 -0500 Date: Wed, 03 Feb 2016 18:32:58 +0200 Message-Id: <83a8nhycsl.fsf@gnu.org> From: Eli Zaretskii To: bug-gnu-emacs@gnu.org Subject: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -5.5 (-----) 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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.5 (-----) emacs -Q Paste the following into *scratch* and evaluate it with "C-x C-e" after the closing parenthesis: (let ((default-file "~/rmail/FOO") (file-name-history '("~/rmail/FOOBAR" "~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed" "~/shorter/file/name"))) (read-file-name (concat "Output message to mail file (default " (file-name-nondirectory default-file) "): ") (file-name-directory default-file) (abbreviate-file-name default-file))) You should now see this in the minibuffer: Output message to mail file (default FOO): ~/rmail/! where ! shows the cursor position. Now press once. The result is as expected: Output message to mail file (default FOO): ~/rmail/FOOBAR! with the cursor at the end of the history item. Press one more time, which results in this: Output message to mail file (default FOO): ~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed! Still as expected. Press once more, resulting in: Output message to mail file (default FOO): ~/foo/ba!r/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed This is somewhat unexpected, because the column of the cursor looks random -- it is neither the same as in previous display, nor related to anything else I can think of. Now press one more time, and observe this result: Output message to mail file (default FOO): ~/shorte!r/file/name This is even less expected -- why isn't the cursor at the end of the file name, even though it is short enough to display entirely on a single screen line? If the longish history item is removed before evaluating the above, then the behavior is as expected -- Emacs places the cursor at the end of each history item. Clearly, the bug is not a catastrophe, but it's quite annoying to see the cursor jump to these unexpected positions. The test case is synthesized, but it faithfully emulates what happens to me every time I use 'o' in Rmail to file a message in my archives. The archive folders are just mbox files, so the 'o' command in Rmail uses file-name-history, where I have long file names as well as short ones. In GNU Emacs 25.0.90.2 (i686-pc-mingw32) of 2016-01-31 built on HOME-C4E4A596F7 Windowing system distributor 'Microsoft Corp.', version 5.1.2600 Configured using: 'configure --prefix=/d/usr --enable-checking=yes,glyphs --with-wide-int --with-modules 'CFLAGS=-Og -gdwarf-4 -g3'' Configured features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS MODULES Important settings: value of $LANG: ENU locale-coding-system: cp1255 Major mode: RMAIL Minor modes in effect: shell-dirtrack-mode: t diff-auto-refine-mode: t desktop-save-mode: t save-place-mode: t show-paren-mode: t display-time-mode: t tooltip-mode: t global-eldoc-mode: t electric-indent-mode: t mouse-wheel-mode: t tool-bar-mode: t menu-bar-mode: t file-name-shadow-mode: t global-font-lock-mode: t font-lock-mode: t blink-cursor-mode: t auto-composition-mode: t auto-encryption-mode: t auto-compression-mode: t temp-buffer-resize-mode: t buffer-read-only: t line-number-mode: t Recent messages: Showing message 2138...done Showing message 2139...done Added to d:/usr/eli/rmail/GIT.rmail Showing message 2140...done Showing message 2141...done Showing message 2142...done Showing message 2143...done No following nondeleted message command-execute: Command attempted to use minibuffer while in minibuffer Mark set Load-path shadows: d:/usr/share/emacs/site-lisp/soap-inspect hides d:/usr/share/emacs/25.0.90/lisp/net/soap-inspect d:/usr/share/emacs/site-lisp/soap-client hides d:/usr/share/emacs/25.0.90/lisp/net/soap-client Features: (shadow emacsbug ruby-mode smie shell character-fold misearch multi-isearch rmailout url-util url-parse url-vars rfc2104 network-stream nsm starttls tls gnutls mail-extr smtpmail auth-source eieio eieio-core cl-macs password-cache dabbrev mailalias sendmail shr-color color shr dom subr-x browse-url cl-seq conf-mode arc-mode archive-mode vc-bzr org-element org-rmail org-mhe org-irc org-info org-gnus org-docview doc-view image-mode org-bibtex bibtex org-bbdb org-w3m org advice org-macro org-footnote org-pcomplete pcomplete org-list org-faces org-entities org-version ob-emacs-lisp ob ob-tangle ob-ref ob-lob ob-table ob-exp org-src ob-keys ob-comint comint ansi-color ring ob-core ob-eval org-compat org-macs org-loaddefs find-func cal-menu calendar cal-loaddefs bat-mode make-mode parse-time vc-cvs generic vc-svn texinfo jka-compr noutline outline bug-reference flyspell add-log info vc vc-dispatcher vc-git diff-mode easy-mmode map seq byte-opt gv bytecomp byte-compile cconv cl-extra qp rmailsum rmailmm message dired-x dired format-spec rfc822 mml mml-sec epg epg-config gnus-util mm-decode mm-bodies mm-encode mailabbrev gmm-utils mailheader mail-parse rfc2231 rmail rfc2047 rfc2045 ietf-drums mm-util help-fns help-mode mail-prsvr mail-utils desktop frameset server filecache mairix cus-edit cus-start cus-load wid-edit saveplace midnight ispell generic-x cc-mode cc-fonts easymenu cc-guess cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs cl-loaddefs pcase cl-lib paren battery time time-date mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese charscript case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote w32notify w32 multi-tty make-network-process emacs) Memory information: ((conses 16 1683542 243444) (symbols 56 41206 0) (miscs 48 3561 4743) (strings 16 113909 44473) (string-bytes 1 3147922) (vectors 16 41851) (vector-slots 8 1701426 256664) (floats 8 497 588) (intervals 40 326308 7211) (buffers 856 218)) From debbugs-submit-bounces@debbugs.gnu.org Wed Feb 03 20:15:39 2016 Received: (at 22544) by debbugs.gnu.org; 4 Feb 2016 01:15:39 +0000 Received: from localhost ([127.0.0.1]:58543 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR8WI-0005uA-RH for submit@debbugs.gnu.org; Wed, 03 Feb 2016 20:15:39 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:41728 helo=homiemail-a11.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aR8WH-0005u3-HV for 22544@debbugs.gnu.org; Wed, 03 Feb 2016 20:15:37 -0500 Received: from homiemail-a11.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTP id 0C94F6E070; Wed, 3 Feb 2016 17:15:37 -0800 (PST) Received: from localhost.linkov.net (85.253.168.42.cable.starman.ee [85.253.168.42]) (Authenticated sender: jurta@jurta.org) by homiemail-a11.g.dreamhost.com (Postfix) with ESMTPA id 3DC4B6E06A; Wed, 3 Feb 2016 17:15:36 -0800 (PST) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Organization: LINKOV.NET References: <83a8nhycsl.fsf@gnu.org> Date: Thu, 04 Feb 2016 02:49:04 +0200 In-Reply-To: <83a8nhycsl.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 03 Feb 2016 18:32:58 +0200") Message-ID: <87d1sd1du7.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: -0.7 (/) > Still as expected. Press once more, resulting in: > > Output message to mail file (default FOO): ~/foo/ba!r/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed > > This is somewhat unexpected, because the column of the cursor looks > random -- it is neither the same as in previous display, nor related > to anything else I can think of. 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? > Now press one more time, and observe this result: > > Output message to mail file (default FOO): ~/shorte!r/file/name > > This is even less expected -- why isn't the cursor at the end of the > file name, even though it is short enough to display entirely on a > single screen line? 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. Do you think we should disable line-move-visual in the minibuffer? I tried to do this like below. This might help to avoid these problems, but I'm not sure. (let ((minibuffer-setup-hook (lambda () (setq-local line-move-visual nil))) (default-file "~/rmail/FOO") (file-name-history '("~/rmail/FOOBAR" "~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed" "~/shorter/file/name"))) (read-file-name (concat "Output message to mail file (default " (file-name-nondirectory default-file) "): ") (file-name-directory default-file) (abbreviate-file-name default-file))) From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 04 11:29:22 2016 Received: (at 22544) by debbugs.gnu.org; 4 Feb 2016 16:29:22 +0000 Received: from localhost ([127.0.0.1]:60455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRMmX-0001dZ-Va for submit@debbugs.gnu.org; Thu, 04 Feb 2016 11:29:22 -0500 Received: from eggs.gnu.org ([208.118.235.92]:44627) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRMmV-0001dN-Pc for 22544@debbugs.gnu.org; Thu, 04 Feb 2016 11:29:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRMmM-0007W3-1a for 22544@debbugs.gnu.org; Thu, 04 Feb 2016 11:29:14 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.3 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:53785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRMmL-0007Vz-Uo; Thu, 04 Feb 2016 11:29:09 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4294 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aRMmL-0006Zx-BE; Thu, 04 Feb 2016 11:29:09 -0500 Date: Thu, 04 Feb 2016 18:28:55 +0200 Message-Id: <831t8sxwvs.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-reply-to: <87d1sd1du7.fsf@mail.linkov.net> (message from Juri Linkov on Thu, 04 Feb 2016 02:49:04 +0200) Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer References: <83a8nhycsl.fsf@gnu.org> <87d1sd1du7.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.5 (-----) > From: Juri Linkov > Cc: 22544@debbugs.gnu.org > Date: Thu, 04 Feb 2016 02:49:04 +0200 > > > Still as expected. Press once more, resulting in: > > > > Output message to mail file (default FOO): ~/foo/ba!r/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed > > > > This is somewhat unexpected, because the column of the cursor looks > > random -- it is neither the same as in previous display, nor related > > to anything else I can think of. > > 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. > > Now press one more time, and observe this result: > > > > Output message to mail file (default FOO): ~/shorte!r/file/name > > > > This is even less expected -- why isn't the cursor at the end of the > > file name, even though it is short enough to display entirely on a > > single screen line? > > 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. > Do you think we should disable line-move-visual in the minibuffer? > I tried to do this like below. This might help to avoid these problems, > but I'm not sure. > > (let ((minibuffer-setup-hook (lambda () (setq-local line-move-visual nil))) > (default-file "~/rmail/FOO") > (file-name-history > '("~/rmail/FOOBAR" > "~/foo/bar/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed" > "~/shorter/file/name"))) > (read-file-name > (concat "Output message to mail file (default " > (file-name-nondirectory default-file) > "): ") > (file-name-directory default-file) > (abbreviate-file-name default-file))) This helps to avoid the problem, but doesn't it defeat the new feature whereby moves by visual rather than by logical lines? The above simply reverts to pre-Emacs 25 behavior, AFAICS. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Feb 04 20:28:56 2016 Received: (at 22544) by debbugs.gnu.org; 5 Feb 2016 01:28:56 +0000 Received: from localhost ([127.0.0.1]:60756 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRVCi-0002Ad-Dw for submit@debbugs.gnu.org; Thu, 04 Feb 2016 20:28:56 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:45440 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRVCg-0002AP-Qz for 22544@debbugs.gnu.org; Thu, 04 Feb 2016 20:28:55 -0500 Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id 99A80150074; Thu, 4 Feb 2016 17:28:51 -0800 (PST) Received: from localhost.linkov.net (85.253.170.183.cable.starman.ee [85.253.170.183]) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPA id C95C715006D; Thu, 4 Feb 2016 17:28:50 -0800 (PST) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Organization: LINKOV.NET References: <83a8nhycsl.fsf@gnu.org> <87d1sd1du7.fsf@mail.linkov.net> <831t8sxwvs.fsf@gnu.org> Date: Fri, 05 Feb 2016 02:42:12 +0200 In-Reply-To: <831t8sxwvs.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 04 Feb 2016 18:28:55 +0200") Message-ID: <87fux82bp7.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: -0.7 (/) >> > Still as expected. Press once more, resulting in: >> > >> > Output message to mail file (default FOO): ~/foo/ba!r/very/long/file/name/that/overflows/minibuffer/window/line/when/displayed >> > >> > This is somewhat unexpected, because the column of the cursor looks >> > random -- it is neither the same as in previous display, nor related >> > to anything else I can think of. >> >> 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: diff --git a/lisp/simple.el b/lisp/simple.el index 72e87a4..079eb93 100644 --- a/lisp/simple.el +++ b/lisp/simple.el @@ -2041,6 +2041,7 @@ next-line-or-history-element ;; the end of the line when it fails to go to the next line. (goto-char old-point) (next-history-element arg) + (setq temporary-goal-column 0) ;; Restore the original goal column on the last line ;; of possibly multi-line input. (goto-char (point-max)) @@ -2071,6 +2072,7 @@ previous-line-or-history-element ;; the beginning of the line when it fails to go to the previous line. (goto-char old-point) (previous-history-element arg) + (setq temporary-goal-column 0) ;; Restore the original goal column on the first line ;; of possibly multi-line input. (goto-char (minibuffer-prompt-end)) >> > Now press one more time, and observe this result: >> > >> > Output message to mail file (default FOO): ~/shorte!r/file/name >> > >> > This is even less expected -- why isn't the cursor at the end of the >> > file name, even though it is short enough to display entirely on a >> > single screen line? >> >> 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 05 04:54:03 2016 Received: (at 22544) by debbugs.gnu.org; 5 Feb 2016 09:54:03 +0000 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 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 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 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 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 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 Date: Fri, 05 Feb 2016 11:53:44 +0200 Message-Id: <83h9hnv5xz.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-reply-to: <87fux82bp7.fsf@mail.linkov.net> (message from Juri Linkov on Fri, 05 Feb 2016 02:42:12 +0200) Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer References: <83a8nhycsl.fsf@gnu.org> <87d1sd1du7.fsf@mail.linkov.net> <831t8sxwvs.fsf@gnu.org> <87fux82bp7.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.5 (-----) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.5 (-----) > 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. From debbugs-submit-bounces@debbugs.gnu.org Fri Feb 05 20:13:37 2016 Received: (at 22544) by debbugs.gnu.org; 6 Feb 2016 01:13:37 +0000 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 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 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) 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) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Organization: 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> Date: Sat, 06 Feb 2016 02:52:18 +0200 In-Reply-To: <83h9hnv5xz.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 05 Feb 2016 11:53:44 +0200") Message-ID: <878u2yps6d.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: -0.7 (/) >> >> 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 06 02:46:33 2016 Received: (at 22544) by debbugs.gnu.org; 6 Feb 2016 07:46:33 +0000 Received: from localhost ([127.0.0.1]:35070 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRxZg-0006AA-SB for submit@debbugs.gnu.org; Sat, 06 Feb 2016 02:46:33 -0500 Received: from eggs.gnu.org ([208.118.235.92]:56131) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aRxZf-00069v-Ft for 22544@debbugs.gnu.org; Sat, 06 Feb 2016 02:46:31 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aRxZS-0003GG-If for 22544@debbugs.gnu.org; Sat, 06 Feb 2016 02:46:23 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:57472) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aRxZS-0003GC-FX; Sat, 06 Feb 2016 02:46:18 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2612 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aRxZR-0001P5-QQ; Sat, 06 Feb 2016 02:46:18 -0500 Date: Sat, 06 Feb 2016 09:45:55 +0200 Message-Id: <83k2mith70.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-reply-to: <878u2yps6d.fsf@mail.linkov.net> (message from Juri Linkov on Sat, 06 Feb 2016 02:52:18 +0200) Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.4 (-----) > From: Juri Linkov > Cc: 22544@debbugs.gnu.org > Date: Sat, 06 Feb 2016 02:52:18 +0200 > > >> 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? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sat Feb 06 20:11:17 2016 Received: (at 22544) by debbugs.gnu.org; 7 Feb 2016 01:11:17 +0000 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 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 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) 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) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Organization: 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> Date: Sun, 07 Feb 2016 02:49:15 +0200 In-Reply-To: <83k2mith70.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Feb 2016 09:45:55 +0200") Message-ID: <87wpqh498k.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: -0.7 (/) >> >> 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. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 07 14:29:39 2016 Received: (at 22544) by debbugs.gnu.org; 7 Feb 2016 19:29:39 +0000 Received: from localhost ([127.0.0.1]:37491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSV1f-00067g-5I for submit@debbugs.gnu.org; Sun, 07 Feb 2016 14:29:39 -0500 Received: from eggs.gnu.org ([208.118.235.92]:45655) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSV1d-00067T-Jv for 22544@debbugs.gnu.org; Sun, 07 Feb 2016 14:29:37 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSV1V-00019j-EX for 22544@debbugs.gnu.org; Sun, 07 Feb 2016 14:29:32 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43327) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSV1V-00019f-BP; Sun, 07 Feb 2016 14:29:29 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4519 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aSV1Q-00063I-Cg; Sun, 07 Feb 2016 14:29:27 -0500 Date: Sun, 07 Feb 2016 21:29:04 +0200 Message-Id: <831t8os4jj.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-reply-to: <87wpqh498k.fsf@mail.linkov.net> (message from Juri Linkov on Sun, 07 Feb 2016 02:49:15 +0200) Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer 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> <87wpqh498k.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Juri Linkov > Cc: 22544@debbugs.gnu.org > Date: Sun, 07 Feb 2016 02:49:15 +0200 > > I tested the implementation of 1 below, and it seems to solve the problem: With or without the previous change you proposed? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Feb 07 20:35:03 2016 Received: (at 22544) by debbugs.gnu.org; 8 Feb 2016 01:35:03 +0000 Received: from localhost ([127.0.0.1]:37762 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSajG-0001M3-RN for submit@debbugs.gnu.org; Sun, 07 Feb 2016 20:35:02 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:58898 helo=homiemail-a39.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSajF-0001LT-5l for 22544@debbugs.gnu.org; Sun, 07 Feb 2016 20:35:01 -0500 Received: from homiemail-a39.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTP id 7D75B150074; Sun, 7 Feb 2016 17:34:59 -0800 (PST) Received: from localhost.linkov.net (62.65.226.75.cable.starman.ee [62.65.226.75]) (Authenticated sender: jurta@jurta.org) by homiemail-a39.g.dreamhost.com (Postfix) with ESMTPA id 9F9E915006D; Sun, 7 Feb 2016 17:34:58 -0800 (PST) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Organization: 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> <87wpqh498k.fsf@mail.linkov.net> <831t8os4jj.fsf@gnu.org> Date: Mon, 08 Feb 2016 02:40:57 +0200 In-Reply-To: <831t8os4jj.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 07 Feb 2016 21:29:04 +0200") Message-ID: <87bn7sovku.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: -0.7 (/) >> I tested the implementation of 1 below, and it seems to solve the problem: > > With or without the previous change you proposed? This patch is without the previous change for the first problem. Actually, it makes the first problem less likely to occur. But still there is no harm in installing the first patch as well to avoid other possible problems. From debbugs-submit-bounces@debbugs.gnu.org Mon Feb 08 13:23:56 2016 Received: (at 22544) by debbugs.gnu.org; 8 Feb 2016 18:23:56 +0000 Received: from localhost ([127.0.0.1]:60397 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSqTc-0000yw-Db for submit@debbugs.gnu.org; Mon, 08 Feb 2016 13:23:56 -0500 Received: from eggs.gnu.org ([208.118.235.92]:48315) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aSqTb-0000yg-JE for 22544@debbugs.gnu.org; Mon, 08 Feb 2016 13:23:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1aSqTS-0003ii-E4 for 22544@debbugs.gnu.org; Mon, 08 Feb 2016 13:23:50 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_20,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34857) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1aSqTS-0003ie-Ae; Mon, 08 Feb 2016 13:23:46 -0500 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1573 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1aSqTR-0006qn-H9; Mon, 08 Feb 2016 13:23:46 -0500 Date: Mon, 08 Feb 2016 20:23:29 +0200 Message-Id: <83twljoyce.fsf@gnu.org> From: Eli Zaretskii To: Juri Linkov In-reply-to: <87bn7sovku.fsf@mail.linkov.net> (message from Juri Linkov on Mon, 08 Feb 2016 02:40:57 +0200) Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer 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> <87wpqh498k.fsf@mail.linkov.net> <831t8os4jj.fsf@gnu.org> <87bn7sovku.fsf@mail.linkov.net> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -5.3 (-----) X-Debbugs-Envelope-To: 22544 Cc: 22544@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -5.3 (-----) > From: Juri Linkov > Cc: 22544@debbugs.gnu.org > Date: Mon, 08 Feb 2016 02:40:57 +0200 > > >> I tested the implementation of 1 below, and it seems to solve the problem: > > > > With or without the previous change you proposed? > > This patch is without the previous change for the first problem. > Actually, it makes the first problem less likely to occur. > But still there is no harm in installing the first patch as well > to avoid other possible problems. LGTM, I'm fine with having these patches as the solution to the issue. Please go ahead and commit. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Tue Feb 09 19:32:47 2016 Received: (at 22544-done) by debbugs.gnu.org; 10 Feb 2016 00:32:48 +0000 Received: from localhost ([127.0.0.1]:34034 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aTIi7-0005FX-OR for submit@debbugs.gnu.org; Tue, 09 Feb 2016 19:32:47 -0500 Received: from sub3.mail.dreamhost.com ([69.163.253.7]:49819 helo=homiemail-a13.g.dreamhost.com) by debbugs.gnu.org with esmtp (Exim 4.84) (envelope-from ) id 1aTIi5-0005FP-Bx for 22544-done@debbugs.gnu.org; Tue, 09 Feb 2016 19:32:45 -0500 Received: from homiemail-a13.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTP id B179E334072; Tue, 9 Feb 2016 16:32:41 -0800 (PST) Received: from localhost.linkov.net (85.253.171.40.cable.starman.ee [85.253.171.40]) (Authenticated sender: jurta@jurta.org) by homiemail-a13.g.dreamhost.com (Postfix) with ESMTPA id D16C033406C; Tue, 9 Feb 2016 16:32:40 -0800 (PST) From: Juri Linkov To: Eli Zaretskii Subject: Re: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Organization: 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> <87wpqh498k.fsf@mail.linkov.net> <831t8os4jj.fsf@gnu.org> <87bn7sovku.fsf@mail.linkov.net> <83twljoyce.fsf@gnu.org> Date: Wed, 10 Feb 2016 02:32:28 +0200 In-Reply-To: <83twljoyce.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 08 Feb 2016 20:23:29 +0200") Message-ID: <878u2t9zhf.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.90 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 22544-done Cc: 22544-done@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: -0.7 (/) > LGTM, I'm fine with having these patches as the solution to the > issue. Please go ahead and commit. Done. From unknown Mon Jun 23 16:46:57 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Wed, 09 Mar 2016 12:24:04 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator