bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#22544: 25.0.90; Long history items cause surprising positioning of c


From: Eli Zaretskii
Subject: bug#22544: 25.0.90; Long history items cause surprising positioning of cursor in minibuffer
Date: Sat, 06 Feb 2016 09:45:55 +0200

> From: Juri Linkov <juri@linkov.net>
> Cc: 22544@debbugs.gnu.org
> Date: Sat, 06 Feb 2016 02:52:18 +0200
> 
> >> 1. Put the cursor at the end of the top visual line, not logical line.
> >>    Drawback: the cursor will be in the middle of the logical line.
> >>
> >> 2. Go to the previous history element when the cursor is anywhere
> >>    on any of the several visual lines of the top logical line,
> >>    not just the top visual line.
> >>    Drawback: can't move the cursor to the top visual line to edit text in 
> >> it.
> >>
> >> 3. When moving the cursor from one visual line to another visual line of
> >>    the logical line, keep the cursor at the end of the visual line.
> >>    The problem is that this behavior should be implemented in 
> >> previous-line.
> >>
> >> 4. Set temporary-goal-column like in the patch above, but instead of 0,
> >>    set it to the column of the end of the top visual line, so <UP>
> >>    will put the cursor at the end of the top visual line in your test case.
> >
> > Can't we special-case a line that isn't broken into several visual
> > lines, and put the cursor at the end of such lines only?  That'd be
> > the best.
> 
> The problem here is that like bash and other shells with histories do,
> we need to put the cursor at the end of the previous history element
> so the user can start editing it immediately (usually deleting the chars
> from the end of the logical line).  OTOH, a subsequent <UP> should
> continue navigating the history and put the next previous element to the
> minibuffer.  But then <UP> can't be used to move between visual lines.
> This is a lose-lose situation, unless we'll find some clever DWIM.
> 
> > If that is too hard, I guess 1 is the second best.  (I'm not really
> > sure how 1 is different from 4, so maybe I actually mean 4 here.)
> 
> 4 doesn't allow <UP> to navigate to the next previous element immediately
> after arriving to the current previous element.

Sorry, I still don't understand.  Can you give an example showing the
difference between 1 and 4?

Thanks.





reply via email to

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