* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
@ 2016-02-03 16:32 Eli Zaretskii
2016-02-04 0:49 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-03 16:32 UTC (permalink / raw)
To: 22544
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 <UP> 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 <UP> 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 <UP> 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 <UP> 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))
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-03 16:32 bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Eli Zaretskii
@ 2016-02-04 0:49 ` Juri Linkov
2016-02-04 16:28 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2016-02-04 0:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22544
> Still as expected. Press <UP> 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 <UP> 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)))
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-04 0:49 ` Juri Linkov
@ 2016-02-04 16:28 ` Eli Zaretskii
2016-02-05 0:42 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-04 16:28 UTC (permalink / raw)
To: Juri Linkov; +Cc: 22544
> From: Juri Linkov <juri@linkov.net>
> Cc: 22544@debbugs.gnu.org
> Date: Thu, 04 Feb 2016 02:49:04 +0200
>
> > Still as expected. Press <UP> 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 <UP> 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 <UP> moves by visual rather than by logical lines? The above
simply reverts to pre-Emacs 25 behavior, AFAICS.
Thanks.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-04 16:28 ` Eli Zaretskii
@ 2016-02-05 0:42 ` Juri Linkov
2016-02-05 9:53 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2016-02-05 0:42 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22544
>> > Still as expected. Press <UP> 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 <UP> 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 <UP>
will put the cursor at the end of the top visual line in your test case.
^ permalink raw reply related [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-05 0:42 ` Juri Linkov
@ 2016-02-05 9:53 ` Eli Zaretskii
2016-02-06 0:52 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-05 9:53 UTC (permalink / raw)
To: Juri Linkov; +Cc: 22544
> From: Juri Linkov <juri@linkov.net>
> 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 <UP>
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-05 9:53 ` Eli Zaretskii
@ 2016-02-06 0:52 ` Juri Linkov
2016-02-06 7:45 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2016-02-06 0:52 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22544
>> >> 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 <UP>
>> 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 <UP> should
continue navigating the history and put the next previous element to the
minibuffer. But then <UP> 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 <UP> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-06 0:52 ` Juri Linkov
@ 2016-02-06 7:45 ` Eli Zaretskii
2016-02-07 0:49 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-06 7:45 UTC (permalink / raw)
To: Juri Linkov; +Cc: 22544
> From: Juri Linkov <juri@linkov.net>
> 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 <UP>
> >> 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 <UP> should
> continue navigating the history and put the next previous element to the
> minibuffer. But then <UP> 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 <UP> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-06 7:45 ` Eli Zaretskii
@ 2016-02-07 0:49 ` Juri Linkov
2016-02-07 19:29 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2016-02-07 0:49 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22544
>> >> 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 <UP>
>> >> 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 <UP> should
>> continue navigating the history and put the next previous element to the
>> minibuffer. But then <UP> 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 <UP> 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 <UP>.
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.
^ permalink raw reply related [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-07 0:49 ` Juri Linkov
@ 2016-02-07 19:29 ` Eli Zaretskii
2016-02-08 0:40 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-07 19:29 UTC (permalink / raw)
To: Juri Linkov; +Cc: 22544
> From: Juri Linkov <juri@linkov.net>
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-07 19:29 ` Eli Zaretskii
@ 2016-02-08 0:40 ` Juri Linkov
2016-02-08 18:23 ` Eli Zaretskii
0 siblings, 1 reply; 12+ messages in thread
From: Juri Linkov @ 2016-02-08 0:40 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22544
>> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-08 0:40 ` Juri Linkov
@ 2016-02-08 18:23 ` Eli Zaretskii
2016-02-10 0:32 ` Juri Linkov
0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2016-02-08 18:23 UTC (permalink / raw)
To: Juri Linkov; +Cc: 22544
> From: Juri Linkov <juri@linkov.net>
> 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.
^ permalink raw reply [flat|nested] 12+ messages in thread
* bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
2016-02-08 18:23 ` Eli Zaretskii
@ 2016-02-10 0:32 ` Juri Linkov
0 siblings, 0 replies; 12+ messages in thread
From: Juri Linkov @ 2016-02-10 0:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 22544-done
> LGTM, I'm fine with having these patches as the solution to the
> issue. Please go ahead and commit.
Done.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-02-10 0:32 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-02-03 16:32 bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer Eli Zaretskii
2016-02-04 0:49 ` Juri Linkov
2016-02-04 16:28 ` Eli Zaretskii
2016-02-05 0:42 ` Juri Linkov
2016-02-05 9:53 ` Eli Zaretskii
2016-02-06 0:52 ` Juri Linkov
2016-02-06 7:45 ` Eli Zaretskii
2016-02-07 0:49 ` Juri Linkov
2016-02-07 19:29 ` Eli Zaretskii
2016-02-08 0:40 ` Juri Linkov
2016-02-08 18:23 ` Eli Zaretskii
2016-02-10 0:32 ` Juri Linkov
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).