Re: [PATCH] local history support, take 2

[Wayne Davison <wayned@xxxxxxxxxxxxxxxxxxxxx>]

On Fri, May 21, 2004 at 10:15:41AM +0100, Peter Stephenson wrote:
> Is this going to be optional eventually?

Yeah, I think that it should be optional just to be more flexible -- I
can imagine someone wanting to call a push in a function without the
auto-pop being forced upon them.  I've added your earlier suggestion of
the option "-a" to indicate that an automatic pop is desired.

> You can also reject attempts to use `fc -P' if the history is marked
> for automatic restoration which gets around the other problem.

Actually, manually popping an automatic history doesn't cause any
problems in the current code (the auto-pop of the history list happens
prior to the restoration of local variables, so the early pop causes no
problems that aren't present for the auto-pop).

> I think it needs to be documented that if you're using commands you
> shouldn't touch the variables by hand, otherwise confusion like this
> is inevitable.

It's fine if the user tweaks the values after a history push because
they're just manipulating the current history buffer.  The only problem
comes in if they declare a variable to be local in a way that conflicts
with the restoration order.  I'm advising users to either omit marking
the variables as local, or to declare them local at the top of the
function and use the automatic-pop form of fc.  (The other sequence that
works fine is calling a non-automatic `fc -p' prior to localization, and
then calling `fc -P' from outside the function, but I don't think we
need to tell the user that.)

I've checked in my updated version.  We can continue to improve it, as
desired, but I think it works quite well now.

..wayne..