Re: Patches item #1729825 ready to go.

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

Ethan Merritt wrote:
> On Monday 04 June 2007 13:31, Daniel J Sebald wrote:
> 
>>1) Help now resolves keywords individually as opposed to a whole line of text 
>>(i.e., things like "help se ter post" are understood).  The algorithm goes with 
>>most matching characters as the "winning" help line, and if there is a tie then 
>>it is the most number of whole matches.
> 
> 
> Sounds good. Let's see if it survives stress-testing.
>  
> 
>>2) History is much more robust to recursion detection.  I went with an algorithm 
>>that will complain if every a command off the history stack is run more than 
>>once in a series of history recalls.  For example
>>
>>plot x; hist !plot
>>plot x; hist !plot
> 
> 
> I cannot imagine anyone having a legitimate reason for issuing such a command.
> Can't we just forbid commands of the form "hist !command" unless they are the
> first and only thing on the line?
> 
> In fact, I can't think of a reason to ever allow a "hist" command except
> at the beginning of a line.  Why would you want to do this? 

Well, you're changing the target then.  Before it was suggested to ignore 
"history !hist" if it is in the middle, so that the rest of the line could be 
executed.  Limiting history in that way, i.e., just first command, seems like 
unnecessary conditional code.  That is, there's little difference between

myparam=50; hist !plot

and

myparam=50
hist !plot

Why should the user be restricted from using the first syntax and not the second?

Even still, once we put conditional restrictions in this way, all of a sudden 
the coding becomes worse than this general, more robust idea.  The general 
approach just simply identifies an recursive behavior and lets the user figure 
out what it was.


> 
> 
>>3) History now has recall by number, e.g., "hist !123".  A bit tricky to 
>>implement given the shuffling behavior we have, but I think I've got it.  (No 
>>sense in numbering the stack if we can't recall by number.)
> 
> 
> Does that number stay constant?

Yes (but no), it tries to maintain the same numbered sequence, and it would if 
not for the shuffling.

   I.e., if I go to the trouble of figuring
> out that some complicated upstream command was "!123",  will that still be
> true 10 minutes later after various intervening commands?   If not, then
> this option is a non-starter.


> >>Note, as far as shuffling it would be easy to make an option for that.  I point 
>>this out because if someone is using recall by number, shuffling of the stack 
>>can cause a problem.
> 
> 
> Er, why are we shuffling the stack?

I'm not a fan of it, but the idea was to condense the stack by removing 
redundancy.  ("shuffling" is my expression for taking out redundant history.) 
The stack stays more condensed that way so one can see more non-redundant commands.

Actually, another way of doing this, rather than shuffling around the stack, 
would be to rewright the "write_history_n" routine so that it keeps all 
numbering the same, but doesn't display those numbers in the stack that are the 
same as some command higher than it.  (Wish I would have thought of that 
sooner.)  To keep it from being an order N^2 sort of thing, we'd simply search 
the stack in history_add() for similar commands and keep a pointer along as part 
of the data for the history entry.

Would that work better?  (I like it.)

Dan