[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: UP and DOWN with multi-line minibuffer history

From: Eli Zaretskii
Subject: Re: UP and DOWN with multi-line minibuffer history
Date: Sun, 13 Dec 2015 17:24:15 +0200

> From: Juri Linkov <address@hidden>
> Cc: address@hidden
> 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?

reply via email to

[Prev in Thread] Current Thread [Next in Thread]