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

[Juri Linkov]

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

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

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