Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov <juri@linkov.net>]

[-- Attachment #1: Type: text/plain, Size: 1222 bytes --]

> We have that in a normal buffer, don't we?

I totally agree with you that it makes sense to imagine the
minibuffer history as contiguous sheets of lines with all
history elements concatenated as lines in a normal buffer.

Then it would be natural to assume UP and DOWN operating on
such an imaginary buffer the same way as they currently operate
on a normal buffer when line-move-visual is set to non-nil.

This consistency sounds right in theory and I'd definitely
support your change after reading your description -
if not tried it in real conditions: typing more than N keys UP
to navigate to Nth history element is a huge annoyance.
While in a normal buffer it's possible to mitigate it
by counting lines and using a numeric argument for UP,
or pressing and holding UP, or even resorting to the mouse,
none of which would work in the minibuffer history.

This explains why no other software is doing such awkward thing.
For example, in Chromium and other Webkit-related browsers typing
UP in the Console brings the previous multi-line history element
and puts the cursor on its first line.

This screenshot demonstrates the place on the first line
where Chromium puts the cursor after typing UP in its minibuffer:


[-- Attachment #2: chromium.png --]
[-- Type: image/png, Size: 2891 bytes --]

[-- Attachment #3: Type: text/plain, Size: 89 bytes --]


And here is exactly the same place on the first line where we put the
cursor in Emacs:


[-- Attachment #4: emacs.png --]
[-- Type: image/png, Size: 2943 bytes --]

[-- Attachment #5: Type: text/plain, Size: 269 bytes --]


This is the standard long-standing behavior that users expect from such
feature based on the needs of millions of users of Chromium, Chrome,
Safari, Opera using this feature every day.  So it would be safe for us
to rely on this thoroughly tested and proven behavior.