**Not quite ready. Needs documentation and good run through. Will update at later time.**
The attached patch is a consolidation of bugs/patches
[ 1525665 ] help has problems with
[ 1531560 ] recursive history warning instead of error
[ 1534367 ] too much expansion in FindHelp
This patch also solves another just-found bug. In a couple places is this construct:
if (!END_OF_COMMAND && equals(c_token,"?")) {
static char *search_str = NULL; /* string from command line to search for */
/\* find and show the entries \*/ c\_token++; m\_capture\(&search\_str, c\_token, c\_token\); /\* reallocates memory \*/
But note that if there is nothing following the ? the code continues and m_capture is done on an invalid c_token. Often this passes fine, but depending on the memory attempting to access there could be a segfault.
Egad! This is worse than I thought. The following is also an infinite loop:
plot x; history !plot
I've changed things to suit, but oh what a headache shuffling the history around makes when it comes to searching and retrieving. (And I'm not sure if shuffling the history is that beneficial... hi !# is hard to keep track of if the numbers keep changing. Anyway... shuffling it is. It would be easy to turn this off.)
I believe I have a solid concept now for recursive history. Rather than trying to do a "what if this, and then that, and then that..." sort of thing (which undoubtedly fails) there is a recursion history (based on dynarray) and if ever gnuplot finds itself running a history line it already has run, it complaines. Here is some sample output.
Terminal type set to 'x11'
gnuplot> plot x
gnuplot> history
1 plot x
2 history
gnuplot> hist !hist
Executing:
history
1 plot x
2 history
3 hist !hist
gnuplot> hist !hist
Executing:
hist !hist
^
recursive history
gnuplot> hist !1
Executing:
plot x
gnuplot> plot x*x; hist !plot
Executing:
plot x
gnuplot> plot x*x; hist !plot
Executing:
plot x*x; hist !plot
gnuplot> plot x*x; hist !plot
^
recursive history
gnuplot>
Logged In: YES
user_id=704782
Originator: YES
Forgot about the special cases "help" and "help ?".
File Added: helphist_djs_01aug2008.patch
Handle special cases "help" and "help ?"
Logged In: YES
user_id=31505
Originator: NO
Yes, I prefer the condensed mode -- I use history to find fastly previous commands, not for copying exactly a long sequence of previous commands -- for such a work I use script files. Given the new "set history" command, everybody can tune the history behaviour.
The patch seems to work for me.
The patch seems to work. Does somebody have any comment? Otherwise it can go to CVS.
I think this patch can be simplified by the use of do_string() because then there would be no need to set up and manage the histentries array.
AFAICS only the recursion detection would have to be changed... This could be done quite easily with my recent patches 2424198 and 2428104.
Juergen
How is the do_string() a substitute for history management? By not calling lf_pop() the commands that patch 2428104 puts in lf_push() would be retained and could be recalled? There would still be the need for displaying those history commands in various formats, recalling a command from history, etc. None of that can be removed so would have to be integrated with something called 'load file stack' which might get a little confusing. Keeping a modular history list with commands to access, add to and remove from it seems easier to keep track of.
If I'm missing something, please explain.
Dan
I'm sorry, I haven't read your patch thoroughly enough. The only thing that do_string() does is to change gp_input_line and to call do_line() in a clean way (modulo outstanding bugs). AFAICS this would at least remove the gpil related lines of your patch (and of the old code as well). I had the impression that at least one of the dynamic structures had the purpose of just keeping references to the old gp_input_lines.
Juergen