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

[Eli Zaretskii <eliz@gnu.org>]

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