bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer

[Juri Linkov <juri@linkov.net>]

>> > 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.