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

[Juri Linkov <juri@linkov.net>]

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