Re: [RFC PATCH 3/3] FAQ: sync newuser-install

[Bart Schaefer <schaefer@brasslantern.com>]

On Thu, Aug 25, 2022 at 10:27 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
> >
> > Unless there's an important behavior that it's simply not possible to
> > accomplish with the existing configuration controls,
>
> Does "enable saving of history without specifying the history file's name" qualify?

Has anyone other than Felipe asserted that this behavior is important?
 IMO it qualifies on the second clause but not on the first.

> What I had in mind was a new option, HIST_RECORD, and have it implicitly
> setopt'd by assignment to $HISTFILE and implicitly unsetopt'd by «unset
> HISTFILE«»;

I am not sanguine about the idea of linking an option and a parameter
together that way.

> If that's nevertheless undersirable, then we could go the deprecation
> route: leave $HISTFILE as is; add an entirely new way to specify the
> history file's name and whether writing to it is enabled (perhaps a
> couple of zstyles);

Also not excited about deprecating the current settings nor about
tying built-in shell behavior to zstyle.  Currently zstyles only
affect operations that are provided via scripts or shell functions.

> Any other alternatives?

I haven't worked through all the details yet, but perhaps a zmodload
module?  The boot routine could assign to the three variables and then
(I think) even unload the module again.  Felipe's zshrc would do
"zmodload zsh/default_history" (or whatever).  The module could be
compiled for all but the most ancient of older versions of zsh if a
packager wanted to do so.