Re: crashes using history

[Daniel J S. <dan...@ie...>]

Petr Mikulik wrote:
>> The problem actually appears to be something that was sitting in the 
>> code for quite a while.
>> SourceForge bugs-report isn't working right now.  I've attached the patch
> 
> 
> I've committed it to cvs.
> 
> 
>> OK, now some comments.
>>
>> 1)  By shuffling around the command line entries when placing them in 
>> the history buffer, the history becomes inaccurate in a significant 
>> sense.  A user, especially a new one, will fret "Now what did I type 
>> to get that to work?".  He or she will look back at the history and 
>> see something that in no way reflects what was typed if there are 
>> repeat commands.
> 
> 
> It reflects all commands he has entered. By means of them, the last plot 
> can be easily reproduced.
> 
> The current behaviour saves his nerves using "up arrow" key to go always 
> through last 10 replot commands, for example.

Yeah, I can see how that would be nice.  Tossing out repeated commands helps, but it doesn't totally rid the issue of the command you want being far back in the history buffer.  That is sort of the reason for displaying the history.  There should be a way to quickly get the one command you see on the displayed list.  (Of course, in linux I can simply use the middle button of the mouse to grab that command.)  "hi 34 get" would be nice.


> Write your commands into a script file.
> Keep interactive editing easy.

That is what I do.  I've always found it easy to do that sort of thing.


>> Would it make sense to have an option for history:
>>
>> gnuplot> history # {linear | condensed}
> 
> 
> Maybe, if some people like the "linear".

How about this?  up-arrow key goes backward through *unique* history entries (current behavior), <SHIFT>-up-arrow key goes backward through all history.  That might be nice.  Is there a precedence for such a thing in readline types of scenarios?

Anyway, post 4.2 discussion...

Dan