UP and DOWN with multi-line minibuffer history

UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

This new feature is convenient, IMO, but its behavior when going UP is
somewhat inconsistent: when you get past the first line of a history
item, you end up in the _first_ line of the previous item, not in its
_last_ line.  You then get to press DOWN all the way to the last line
of that.

I think it would be more consistent, including with how
line-move-visual behaves in normal buffers, if UP ended up in the last
line of the previous item.  WDYT?

Re: UP and DOWN with multi-line minibuffer history

[Dmitry Gutov]

On 12/12/2015 04:19 PM, Eli Zaretskii wrote:

> I think it would be more consistent, including with how
> line-move-visual behaves in normal buffers, if UP ended up in the last
> line of the previous item.  WDYT?

Sounds good to me.

Re: UP and DOWN with multi-line minibuffer history

[John Wiegley]

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

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

> On 12/12/2015 04:19 PM, Eli Zaretskii wrote:
>> I think it would be more consistent, including with how
>> line-move-visual behaves in normal buffers, if UP ended up in the last
>> line of the previous item.  WDYT?

> Sounds good to me.

To me as well.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 629 bytes --]

Re: UP and DOWN with multi-line minibuffer history

[Eric Hanchrow]

Eli Zaretskii <eliz@gnu.org> writes:

> I think it would be more consistent, including with how
> line-move-visual behaves in normal buffers, if UP ended up in the last
> line of the previous item.  WDYT?

Sounds good to me, too.

Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov]

> This new feature is convenient, IMO, but its behavior when going UP is
> somewhat inconsistent: when you get past the first line of a history
> item, you end up in the _first_ line of the previous item, not in its
> _last_ line.  You then get to press DOWN all the way to the last line
> of that.
>
> I think it would be more consistent, including with how
> line-move-visual behaves in normal buffers, if UP ended up in the last
> line of the previous item.  WDYT?

The initial implementation of this feature was like you described above.
But later I received complaints off-list that convinced me to open
bug#19824 with better implementation to address the inconvenience of
navigating through the multi-line minibuffer history: for backward-compatible
behavior we need every UP in the sequence move to a previous history item.
This can be achieved when UP places the cursor at the top line of a
multi-line history item, ready for going to the next previous item with
successive UP.

Re: UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Sun, 13 Dec 2015 01:20:49 +0200
> 
> > I think it would be more consistent, including with how
> > line-move-visual behaves in normal buffers, if UP ended up in the last
> > line of the previous item.  WDYT?
> 
> The initial implementation of this feature was like you described above.
> But later I received complaints off-list that convinced me to open
> bug#19824 with better implementation to address the inconvenience of
> navigating through the multi-line minibuffer history: for backward-compatible
> behavior we need every UP in the sequence move to a previous history item.
> This can be achieved when UP places the cursor at the top line of a
> multi-line history item, ready for going to the next previous item with
> successive UP.

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?

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?

Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov]

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

Re: UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Mon, 14 Dec 2015 02:07:45 +0200
> 
> So the question at hand can be considered as Consistency vs. Convenience,
> i.e. trying to achieve consistency at the cost of losing convenience.

Yes, it's consistency vs minor inconvenience in certain use cases.  I
think consistency should win big time.

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

I think we should install such a change and see if there are any
complaints.  Several people already agreed with my suggestion for how
it should work.

Thanks.

Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov]

>> So the question at hand can be considered as Consistency vs. Convenience,
>> i.e. trying to achieve consistency at the cost of losing convenience.
>
> Yes, it's consistency vs minor inconvenience in certain use cases.  I
> think consistency should win big time.

It's not minor inconvenience, it renders navigating multi-line items unusable.

>> I invite you and everyone interested to try this change for a few days
>> to see its real effect.
>
> I think we should install such a change and see if there are any
> complaints.  Several people already agreed with my suggestion for how
> it should work.

This change sounds good in theory, but fails in practice.
We already have sevaral complaints against this change,
and no complaints about the current behavior.
So why change what is working well?

Re: UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

> From: Juri Linkov <juri@linkov.net>
> Cc: emacs-devel@gnu.org
> Date: Tue, 15 Dec 2015 01:45:20 +0200
> 
> >> So the question at hand can be considered as Consistency vs. Convenience,
> >> i.e. trying to achieve consistency at the cost of losing convenience.
> >
> > Yes, it's consistency vs minor inconvenience in certain use cases.  I
> > think consistency should win big time.
> 
> It's not minor inconvenience, it renders navigating multi-line items unusable.

I think "unusable" is a great exaggeration.  We have that in a normal
buffer, don't we?

> We already have sevaral complaints against this change,
> and no complaints about the current behavior.

Where are the complaints against the change?  I didn't see them.  By
contrast, several people said they agreed with my proposal.

> So why change what is working well?

Because it doesn't work well, its effect is surprising and unexpected.

Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov]

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

Re: UP and DOWN with multi-line minibuffer history

[Dmitry Gutov]

On 12/16/2015 02:32 AM, Juri Linkov wrote:

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

Not in Firefox, though. It puts the cursor on the last line.

Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov]

>> 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.
>
> Not in Firefox, though. It puts the cursor on the last line.

Still Firefox jumps to the last line when navigating downwards
with the <DOWN> key exactly like Chromium does.

Re: UP and DOWN with multi-line minibuffer history

[Yuri Khan]

On Wed, Dec 16, 2015 at 6:32 AM, Juri Linkov <juri@linkov.net> wrote:
> 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.

However, if <up> at the first line moves point to the first line of
the previous item, you end up with another annoyance — <down> is no
longer an inverse of <up>.

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

Other software also has pull-down histories, so one doesn’t have to
scroll the history while looking at it through a mailbox slit. You
pull down the history, select an item you want, press Enter, and it
gets copied into the input box where you can edit it before executing
again.

In Emacs UI conventions, it might work like this:

* Pressing some special key while in minibuffer would open a temporary
buffer showing the history and place the point in it.
* The item containing the point would be optionally highlighted with a face.
* The user would then move the point to the desired item.
* Pressing Enter would copy the item containing the point into the
minibuffer and bury or kill the history buffer.
* Attempting any editing command would copy the item containing the
point into the minibuffer, bury or kill the history buffer, and
perform the editing command in the minibuffer.
* Pressing C-g would just bury or kill the history buffer without
modifying the minibuffer contents.

RE: UP and DOWN with multi-line minibuffer history

[Drew Adams]

> Other software also has pull-down histories, so one doesn’t have to
> scroll the history while looking at it through a mailbox slit. You
> pull down the history, select an item you want, press Enter, and it
> gets copied into the input box where you can edit it before executing
> again.

Yes, it is too bad that in Emacs the history is invisible that way
(seeing at most one item at a time).  It's a peep show.

> In Emacs UI conventions, it might work like this:
> 
> * Pressing some special key while in minibuffer would open a temporary
>   buffer showing the history and place the point in it.
> * The item containing the point would be optionally highlighted with a face.
> * The user would then move the point to the desired item.
> * Pressing Enter would copy the item containing the point into the
>   minibuffer and bury or kill the history buffer.
> * Attempting any editing command would copy the item containing the
>   point into the minibuffer, bury or kill the history buffer, and
>   perform the editing command in the minibuffer.
> * Pressing C-g would just bury or kill the history buffer without
>   modifying the minibuffer contents.

FWIW, that's pretty much how completing against the input history works
in Icicles.

> * Pressing some special key while in minibuffer would open a temporary
>   buffer showing the history and place the point in it.

`M-o' does that (for any minibuffer input, not just for input read with 
completion).  It opens temporary buffer *Completions* with the list of
past inputs.  You can sort them in various orders, including latest use.

`M-o' lets you use completion or cycling to insert a history item (or
several) in the minibuffer.
  
> * The item containing the point would be optionally highlighted with
>   a face.

Yes, the "current" history item is highlighted.  (You can think of point
in *Completions* as being at the current item, but it is not.  Point in
*Completions* is really irrelevant.)

> * The user would then move the point to the desired item.

You can cycle among the items.  Or complete to one.  Or combine
completing (to narrow the candidates) and cycling.  Or choose one
withthe mouse.  Current-item highlighting tracks when you cycle
(like "moving point").

> * Pressing Enter would copy the item containing the point into the 
>   minibuffer

Yes, `RET' appends the current candidate to the current minibuffer
content.  (`M-k' erases the minibuffer.)

An inserted history item is followed by a space, by default.
 With a prefix arg <= 0, no space is appended.
 With a prefix arg >=0, each inserted item is wrapped in "...".

(You can also use `M-o' as a multi-command, so one invocation lets
you insert any number of history items, even multiple times, and
in this case you can also use a prefix arg on individual items, to
append them individually with or without spaces and "..." wrappers.)

> * Attempting any editing command would copy the item containing the
>   point into the minibuffer, bury or kill the history buffer, and
>   perform the editing command in the minibuffer.

Nah.  Any editing command/key acts normally in the minibuffer, to
edit its contents.  (Icicles is even more vanilla than vanilla, in
preserving editing keys.  `?', `SPC', and `C-j' are self-inserting,
for instance.)

> * Pressing C-g would just bury or kill the history buffer without
>   modifying the minibuffer contents.

Yes.  `C-g' cancels completion.  You can continue to use the minibuffer.

http://www.emacswiki.org/emacs/Icicles_-_History_Enhancements#M-o

Re: UP and DOWN with multi-line minibuffer history

[Juri Linkov]

>> 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.
>
> However, if <up> at the first line moves point to the first line of
> the previous item, you end up with another annoyance — <down> is no
> longer an inverse of <up>.

Yes, you need to go through all the lines of the current history element
with <down> to reach the bottom line before going to the next element -
but only when reversing navigation directions that is less annoying than
doing this always, even when navigating in one direction.

>> 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.
>
> Other software also has pull-down histories, so one doesn’t have to
> scroll the history while looking at it through a mailbox slit. You
> pull down the history, select an item you want, press Enter, and it
> gets copied into the input box where you can edit it before executing
> again.
>
> In Emacs UI conventions, it might work like this:
>
> * Pressing some special key while in minibuffer would open a temporary
> buffer showing the history and place the point in it.
> * The item containing the point would be optionally highlighted with a face.
> * The user would then move the point to the desired item.
> * Pressing Enter would copy the item containing the point into the
> minibuffer and bury or kill the history buffer.
> * Attempting any editing command would copy the item containing the
> point into the minibuffer, bury or kill the history buffer, and
> perform the editing command in the minibuffer.
> * Pressing C-g would just bury or kill the history buffer without
> modifying the minibuffer contents.

This is already possible in Emacs, e.g. typing TAB with

  (completing-read "Minibuffer history: " read-expression-history)

Re: UP and DOWN with multi-line minibuffer history

[Dmitry Gutov]

On 12/14/2015 05:39 AM, Eli Zaretskii wrote:

> Yes, it's consistency vs minor inconvenience in certain use cases.  I
> think consistency should win big time.

I'd say the choice is rather "consistency and inconvenience in some use 
cases" vs "inconvenience in some other use cases".

I've never used the goal column, so that problem sounds fairly obscure, 
personally.

Re: UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 15 Dec 2015 05:43:29 +0200
> 
> On 12/14/2015 05:39 AM, Eli Zaretskii wrote:
> 
> > Yes, it's consistency vs minor inconvenience in certain use cases.  I
> > think consistency should win big time.
> 
> I'd say the choice is rather "consistency and inconvenience in some use 
> cases" vs "inconvenience in some other use cases".

Yes, I agree.

> I've never used the goal column, so that problem sounds fairly obscure, 
> personally.

I think you are using it every time you use C-n/C-p.  I didn't mean
goal-column literally, I meant temporary-goal-column that these
commands use internally to keep point on the same visual column.

Re: UP and DOWN with multi-line minibuffer history

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Juri Linkov <juri@linkov.net>
>> Cc: emacs-devel@gnu.org
>> Date: Sun, 13 Dec 2015 01:20:49 +0200
>> 
>> > I think it would be more consistent, including with how
>> > line-move-visual behaves in normal buffers, if UP ended up in the last
>> > line of the previous item.  WDYT?
>> 
>> The initial implementation of this feature was like you described above.
>> But later I received complaints off-list that convinced me to open
>> bug#19824 with better implementation to address the inconvenience of
>> navigating through the multi-line minibuffer history: for backward-compatible
>> behavior we need every UP in the sequence move to a previous history item.
>> This can be achieved when UP places the cursor at the top line of a
>> multi-line history item, ready for going to the next previous item with
>> successive UP.
>
> 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.

Really?

From simple.el:

(defun line-move (arg &optional noerror to-end try-vscroll)
  "Move forward ARG lines.
If NOERROR, don't signal an error if we can't move ARG lines.
TO-END is unused.
TRY-VSCROLL controls whether to vscroll tall lines: if either
`auto-window-vscroll' or TRY-VSCROLL is nil, this function will
not vscroll."
[...]
      (if (and line-move-visual
               ;; Display-based column are incompatible with goal-column.
               (not goal-column)

A bit of git-blame work reveals that this was introduced by a certain
Eli Zaretskii in:

commit 064f328a6ac90698c719b6eace60d6f4c90e3f08
Author: Eli Zaretskii <eliz@gnu.org>
Date:   Fri Sep 16 20:15:16 2011 +0300

    Fix bug #971 with next/previous-line when goal-column is set.
    
     lisp/simple.el (line-move): If goal-column is set, move by logical
     lines, not by display lines.
     (next-line, previous-line, goal-column, line-move-visual): Doc fix
     to reflect the above change.


We also have

commit 295f6616401967b2fae6671a5d2ae36a287576e9
Author: Kim F. Storm <storm@cua.dk>
Date:   Sun Mar 13 23:20:49 2005 +0000

    (next-line, previous-line): Add optional try-vscroll
    arg to recognize interactive use.  Pass it on to line-move.
    (line-move): Don't perform auto-window-vscroll when defining or
    executing keyboard macro to ensure consistent behaviour.


from a time where people actually bothered about getting consistently
working keyboard macros, which contains the section:

 ;; Perform vertical scrolling of tall images if necessary.
+;; Don't vscroll in a keyboard macro.
 (defun line-move (arg &optional noerror to-end try-vscroll)
-  (if (and auto-window-vscroll try-vscroll)
+  (if (and auto-window-vscroll try-vscroll
+          (not defining-kbd-macro)
+          (not executing-kbd-macro))
       (let ((forward (> arg 0))


-- 
David Kastrup

Re: UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: Juri Linkov <juri@linkov.net>,  emacs-devel@gnu.org
> Date: Mon, 14 Dec 2015 10:25:20 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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.
> 
> Really?
> 
> >From simple.el:
> 
> (defun line-move (arg &optional noerror to-end try-vscroll)
>   "Move forward ARG lines.
> If NOERROR, don't signal an error if we can't move ARG lines.
> TO-END is unused.
> TRY-VSCROLL controls whether to vscroll tall lines: if either
> `auto-window-vscroll' or TRY-VSCROLL is nil, this function will
> not vscroll."
> [...]
>       (if (and line-move-visual
>                ;; Display-based column are incompatible with goal-column.
>                (not goal-column)
> 
> A bit of git-blame work reveals that this was introduced by a certain
> Eli Zaretskii in:
> 
> commit 064f328a6ac90698c719b6eace60d6f4c90e3f08
> Author: Eli Zaretskii <eliz@gnu.org>
> Date:   Fri Sep 16 20:15:16 2011 +0300
> 
>     Fix bug #971 with next/previous-line when goal-column is set.
>     
>      lisp/simple.el (line-move): If goal-column is set, move by logical
>      lines, not by display lines.
>      (next-line, previous-line, goal-column, line-move-visual): Doc fix
>      to reflect the above change.

I said "in the visual-line sense", and I meant it.  You are looking at
the wrong part of the code; you should instead look at how
line-move-visual calls vertical-motion passing it the value of
temporary-goal-column.

Re: UP and DOWN with multi-line minibuffer history

[David Kastrup]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: David Kastrup <dak@gnu.org>
>> Cc: Juri Linkov <juri@linkov.net>,  emacs-devel@gnu.org
>> Date: Mon, 14 Dec 2015 10:25:20 +0100
>>
>> >From simple.el:
>> 
>> (defun line-move (arg &optional noerror to-end try-vscroll)
>>   "Move forward ARG lines.
>> If NOERROR, don't signal an error if we can't move ARG lines.
>> TO-END is unused.
>> TRY-VSCROLL controls whether to vscroll tall lines: if either
>> `auto-window-vscroll' or TRY-VSCROLL is nil, this function will
>> not vscroll."
>> [...]
>>       (if (and line-move-visual
>>                ;; Display-based column are incompatible with goal-column.
>>                (not goal-column)
>> 
>
> I said "in the visual-line sense", and I meant it.  You are looking at
> the wrong part of the code; you should instead look at how
> line-move-visual calls vertical-motion passing it the value of
> temporary-goal-column.

I don't quite see why I should look at `line-move-visual' when
`line-move-visual' is never called by `line-move' when `goal-column' is
set and there is no other caller of `line-move-visual' in the Emacs code
base.

-- 
David Kastrup

Re: UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Cc: juri@linkov.net,  emacs-devel@gnu.org
> Date: Mon, 14 Dec 2015 17:41:21 +0100
> 
> > I said "in the visual-line sense", and I meant it.  You are looking at
> > the wrong part of the code; you should instead look at how
> > line-move-visual calls vertical-motion passing it the value of
> > temporary-goal-column.
> 
> I don't quite see why I should look at `line-move-visual'

Only if you want to understand correctly what I wrote.  Otherwise,
feel free to think (incorrectly) that I meant goal-column.

Re: UP and DOWN with multi-line minibuffer history

[Eli Zaretskii]

> Date: Sat, 12 Dec 2015 22:12:43 +0100
> From: Anders Lindgren <andlind@gmail.com>
> 
> Unfortunately, your suggested scheme has a big drawback. If you want to walk
> past one or more multi-line entries in the minibuffer history, you will need to
> press UP once per line of the entries, not once per entry.

The same happens in any "normal" buffer, right?

>  Of course, a power-user know about M-p, but most people won't.

They'll learn if it annoys them enough.  If not, it's not a
catastrophe.

Re: UP and DOWN with multi-line minibuffer history

[Anders Lindgren]

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

>
> > Unfortunately, your suggested scheme has a big drawback. If you want to
> walk
> > past one or more multi-line entries in the minibuffer history, you will
> need to
> > press UP once per line of the entries, not once per entry.
>
> The same happens in any "normal" buffer, right?
>

Not really, in a normal buffer you have a lot of more navigation power,
like scrolling page by page, clicking at the right spot etc. When stepping
in the minibuffer history, (almost) the only thing you can do is to press
UP.

Of course, I would count this as a minor drawback, not as a showstopper.

    -- Anders

[-- Attachment #2: Type: text/html, Size: 939 bytes --]