From: Juri Linkov <juri@linkov.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 22544@debbugs.gnu.org
Subject: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
Date: Sun, 07 Feb 2016 02:49:15 +0200 [thread overview]
Message-ID: <87wpqh498k.fsf@mail.linkov.net> (raw)
In-Reply-To: <83k2mith70.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 06 Feb 2016 09:45:55 +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?
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.
next prev parent reply other threads:[~2016-02-07 0:49 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87wpqh498k.fsf@mail.linkov.net \
--to=juri@linkov.net \
--cc=22544@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.