Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov <juri@linkov.net>]

> Sorry, I don't understand why supporting goal-column must have this
> side effect.  In a normal buffer, we do support goal-column (in the
> visual-line sense), and still we don't jump to the firs screen line of
> a long logical line.  Why should the minibuffer behave differently?

Because the minibuffer is different from a normal buffer where you have
a better overview on the content to be able to navigate it freely with
support of more available commands.

Even without mentioning the controversies of the current implementation
of visual-line-mode such as unending flow of reports about broken macros,
this doesn't mean we have to mimic its behavior in the minibuffer,
where the primary purpose of UP is to quickly bring previous history items,
and only as a secondary feature allow editing a multi-line item.

So the question at hand can be considered as Consistency vs. Convenience,
i.e. trying to achieve consistency at the cost of losing convenience.

> I guess the description in bug#19824 lacks some crucial details,
> because I simply don't see why preserving the column should force to
> jump to the first screen line of the previous history item.  Can you
> explain?  Are you interpreting the goal-column in physical, rather
> than visual, sense?

In fact, supporting goal-column is not required to have this side effect.
Jumping to the first screen line was part of complaints that needed addressing.

Jumping to the last screen line can be achieved by exchanging just two lines
in next-line-or-history-element and previous-line-or-history-element:
moving ‘(goto-char (minibuffer-prompt-end))’ to the former, and exchanging
it with ‘(goto-char (point-max))’ from the latter.

I invite you and everyone interested to try this change for a few days
to see its real effect.