On Sun, Dec 09, 2001 at 05:46:41PM +1100, Doug Kearns wrote: > On Tue, Dec 04, 2001 at 09:06:42AM +0100, Cliff Sarginson wrote: > > On Tue, Dec 04, 2001 at 04:20:03PM +1100, Doug Kearns wrote: > > > I've just noticed that if you are cycling through the command history > > > and abort with a ^G, the next time you invoke the line editor you are > > > placed at the point in history list at which you aborted. > > > > > > example: > > > > > > :command 1 > > > :command 2 > > > :command 3 > > > :command 4 > > > :command 5 > > > > > > cycle up the history to 'command 3', abort and invoke the line editor > > > again. Hit the <Up> key and you are at 'command 2' which is not the last > > > command you entered. > > > > > Well, in a sense you are at the last line you entered are you not ? > > Not really. I'm at the last line I scrolled to in the history buffer, > not the last line I 'entered'. > > > You "entered" it through cycling to it+1. You aborted the current action > > which leaves the history pointer at current-action -1 . > > Surely an aborted operation should not change the state of the history > buffer. > > > It seems strange, but if you think about it then it is logical. > > Not to me :-) > Well, and I am guessing here, it may be that the logic of mutt is such that it does not actually "know" you are aborting the scrolling back, since each scroll back is a seperate operation, what you are aborting is the last scroll back, not the last "n" scroll backs. It is probable that mutt also treats the redisplayed line from the scrolling by the exact same logic as if you had just typed it in (that would be sensible, in my view).
> I've also noticed that the history is cleared when the history buffer is > full, rather than just deleting the least recent item. > > I'm curious if this is the desired behaviour. > Well that depends on how the list is implemented in the code. -- Regards Cliff
