bug#42862: 28.0.50; {previous,next}-line-or-history-element ignores line-move-visual

[Michael Welsh Duggan]

Juri Linkov <juri@linkov.net> writes:

>> Run:
>>
>>     emacs -Q --exec "(setq-default line-move-visual nil)"
>>
>> Visit a file in a directory where the directory name is not long enough
>> to wrap in the minibuffer, but the filename is long enough that,
>> appended to that directory, the minibuffer would wrap.
>>
>> Example:
>> /tmp/this-is-a-very-long-directory-name-that-will-not-wrap/but-this-file-name-will-make-it-wrap
>>
>> Specifically, visit this file such that it will enter the minibuffer
>> history for file visiting.
>>
>> Type `C-h f'.
>
> I can't reproduce your bug report with `C-h f', but with `C-x C-f' I see
> where is the problem.

That was a glitch between my head and my fingers.  (Or maybe in my
head.   The jury is out.)

>> It is my belief that if `line-move-visual' is nil,
>> `previous-line-or-history-element' should move to the end of the first
>> logical line instead of the first visual line.
>
> The patch below should fix this.
>
>> (Similarly for `next-line-or-history-element'.)
>
> Are you sure that `next-line-or-history-element' needs the same fix?
>
> diff --git a/lisp/simple.el b/lisp/simple.el
> index 1cb93c5722..9f3b131a11 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -2402,7 +2402,7 @@ previous-line-or-history-element
>         (setq temporary-goal-column 0)
>         ;; Restore the original goal column on the first line
>         ;; of possibly multi-line input.
> -       (goto-char (minibuffer-prompt-end))
> +       (goto-char (minibuffer-prompt-end)) ; FIXME: maybe remove this line?
>         (if old-column
>          (if (= (line-number-at-pos) 1)
>              (move-to-column (+ old-column
> @@ -2410,15 +2410,17 @@ previous-line-or-history-element
>                                   (goto-char (1- (minibuffer-prompt-end)))
>                                   (current-column))))
>            (move-to-column old-column))
> -      ;; Put the cursor at the end of the visual line instead of the
> -      ;; logical line, so the next `previous-line-or-history-element'
> -      ;; would move to the previous history element, not to a possible upper
> -      ;; visual line from the end of logical line in `line-move-visual' mode.
> -      (end-of-visual-line)
> -      ;; Since `end-of-visual-line' puts the cursor at the beginning
> -      ;; of the next visual line, move it one char back to the end
> -      ;; of the first visual line (bug#22544).
> -      (unless (eolp) (backward-char 1)))))))
> +      (if (not line-move-visual)     ; (bug#42862)
> +             (goto-char (point-max))

I would recommend (end-of-line) instead, for when the prompt (in
history) is actually a multi-line prompt, otherwise it will fall prey to
the same problem that `end-of-visual-line' is attempting to solve here.

> +        ;; Put the cursor at the end of the visual line instead of the
> +        ;; logical line, so the next `previous-line-or-history-element'
> +        ;; would move to the previous history element, not to a possible 
> upper
> +        ;; visual line from the end of logical line in `line-move-visual' 
> mode.
> +        (end-of-visual-line)
> +        ;; Since `end-of-visual-line' puts the cursor at the beginning
> +        ;; of the next visual line, move it one char back to the end
> +        ;; of the first visual line (bug#22544).
> +        (unless (eolp) (backward-char 1))))))))
>  
>  (defun next-complete-history-element (n)
>    "Get next history element that completes the minibuffer before the point.
>

-- 
Michael Welsh Duggan
(md5i@md5i.com)