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