From: Mikael Magnusson <mikachu@gmail.com>
To: zsh-workers@zsh.org
Subject: Re: Proposed feature: Selectively avoid adding to history (with code)
Date: Tue, 23 Feb 2010 08:57:43 +0100 [thread overview]
Message-ID: <237967ef1002222357x44b0c891m60d483a06d788df4@mail.gmail.com> (raw)
In-Reply-To: <100222184752.ZM26580@torch.brasslantern.com>
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
next prev parent reply other threads:[~2010-02-23 7:57 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-02-22 17:42 Richard Hartmann
2010-02-23 2:47 ` Bart Schaefer
2010-02-23 7:57 ` Mikael Magnusson [this message]
2010-02-23 9:42 ` Richard Hartmann
2010-02-23 9:41 ` Richard Hartmann
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=237967ef1002222357x44b0c891m60d483a06d788df4@mail.gmail.com \
--to=mikachu@gmail.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).