Proposed feature: Selectively avoid adding to history (with code)

Proposed feature: Selectively avoid adding to history (with code)

[Richard Hartmann]

Hi all,

I am running this function. It's a bit like HIST_IGNORE_SPACE just without
leading whitespace.

  zshaddhistory(){if [[ -n $FOO ]]; then return 1; fi}

If you set $FOO, you will not save anything to your history. If you unset
it, you will save again.
This allows me to modify my prompt, giving a visual clue that I am in
try-out mode and will not put random testing stuff into my history.

The control variable is deliberately named $FOO because I wanted to ask:

1) If anyone else thinks this is useful and if it should be a _function
2) If "$HIST_NO_STORE" is a good variable name
3) If this would be better handled in an option


Thanks,
Richard

Re: Proposed feature: Selectively avoid adding to history (with code)

[Bart Schaefer]

On Feb 22,  6:42pm, Richard Hartmann wrote:
} 
}   zshaddhistory(){if [[ -n $FOO ]]; then return 1; fi}
} 
} This allows me to modify my prompt, giving a visual clue that I am in
} try-out mode and will not put random testing stuff into my history.
} 
} 1) If anyone else thinks this is useful and if it should be a _function

It'd be more useful if I could retroactively delete the last several
commands from my history, because I never remember to turn this sort
of thing on before I start testing. :-)

I'm not sure what you mean by "should be a _function"?

} 2) If "$HIST_NO_STORE" is a good variable name

Hrm.  The option of that name means not to store commands that are for
history access (and hence was a poor model for all the other "HIST_"
options that came after it, e.g., HIST_NO_FUNCTIONS should really be
FUNC_NO_STORE if the pattern had been properly applied).

HIST_DISABLE or would probably be a better name.  Won't one of the side-
effects be that you can't find those commands in the interactive history
either?  I'd like stuff to remain in the interactive history but somehow
be tagged so they're never written to $HISTFILE, which brings me to ...

} 3) If this would be better handled in an option

A tagging effect probably does need to be controlled by an option, as
the alternative is a builtin you can only call from zshaddhistory() or
some such; but I think for what you've got here, your approach is fine.

Re: Proposed feature: Selectively avoid adding to history (with code)

[Mikael Magnusson]

On 23 February 2010 03:47, Bart Schaefer <schaefer@brasslantern.com> wrote:
> On Feb 22,  6:42pm, Richard Hartmann wrote:
> }
> }   zshaddhistory(){if [[ -n $FOO ]]; then return 1; fi}
> }
> } This allows me to modify my prompt, giving a visual clue that I am in
> } try-out mode and will not put random testing stuff into my history.
> }
> } 1) If anyone else thinks this is useful and if it should be a _function
>
> It'd be more useful if I could retroactively delete the last several
> commands from my history, because I never remember to turn this sort
> of thing on before I start testing. :-)
>
> I'm not sure what you mean by "should be a _function"?
>
> } 2) If "$HIST_NO_STORE" is a good variable name
>
> Hrm.  The option of that name means not to store commands that are for
> history access (and hence was a poor model for all the other "HIST_"
> options that came after it, e.g., HIST_NO_FUNCTIONS should really be
> FUNC_NO_STORE if the pattern had been properly applied).
>
> HIST_DISABLE or would probably be a better name.  Won't one of the side-
> effects be that you can't find those commands in the interactive history
> either?  I'd like stuff to remain in the interactive history but somehow
> be tagged so they're never written to $HISTFILE, which brings me to ...
>
> } 3) If this would be better handled in an option
>
> A tagging effect probably does need to be controlled by an option, as
> the alternative is a builtin you can only call from zshaddhistory() or
> some such; but I think for what you've got here, your approach is fine.

I have a widget that toggles $HISTFILE between empty and ~/.history,
and it used to work fine, but lately it's been writing some entries to
~/.history after i turn it back on that were entered while it was
empty, and i'm sure it used not to. It could be some option i've
fiddled with though, i just haven't felt like experimenting with it
yet. (of course this approach needs at least setopt incappendhistory).

-- 
Mikael Magnusson

Re: Proposed feature: Selectively avoid adding to history (with code)

[Richard Hartmann]

On Tue, Feb 23, 2010 at 03:47, Bart Schaefer <schaefer@brasslantern.com> wrote:

> It'd be more useful if I could retroactively delete the last several
> commands from my history, because I never remember to turn this sort
> of thing on before I start testing. :-)

There is something on the mailing list about that. I used to use it, but
don't need to any more, as I have become better at opening new
shells for testing & doing HISTFILE=''.


> I'm not sure what you mean by "should be a _function"?

A built-in function that can be overriden.


> HIST_DISABLE or would probably be a better name.  Won't one of the side-
> effects be that you can't find those commands in the interactive history
> either?

I wanted to express that the effect is temporary and normal operation can
be resumed with the press of a button, so to speak. Also, that everything
before or after will still be stored.


>  I'd like stuff to remain in the interactive history but somehow
> be tagged so they're never written to $HISTFILE, which brings me to ...

Sounds useful but potentially confusing.


> A tagging effect probably does need to be controlled by an option, as
> the alternative is a builtin you can only call from zshaddhistory() or
> some such; but I think for what you've got here, your approach is fine.

If the topic of tagging comes up, there is other stuff that could be put
into the enhanced history. For example, PWD comes to mind.


Richard

Re: Proposed feature: Selectively avoid adding to history (with code)

[Richard Hartmann]

On Tue, Feb 23, 2010 at 08:57, Mikael Magnusson <mikachu@gmail.com> wrote:

> yet. (of course this approach needs at least setopt incappendhistory).

I know many people who can't work with incappendhistory, myself included.

If you use it, this is a neat solution, though.


Richard