GNU bug report logs - #22544
25.0.90; Long history items cause surprising positioning of cursor in minibuffer

Previous Next

Full log

Message #23 received at 22544 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juri Linkov <juri <at> linkov.net>
Cc: 22544 <at> debbugs.gnu.org
Subject: Re: 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 <at> linkov.net>
> Cc: 22544 <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.