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

["Daniel Shahaf" <d.s@daniel.shahaf.name>]

Bart Schaefer wrote on Sat, 27 Aug 2022 02:24 +00:00:
> 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.
>

It's one fewer thing for the user to care about.  I wouldn't go so far
as to call it "important" but I do think it would be nice to have.

From a more theoretical perspective, removing the need to set HISTFILE
would allow us to one day move the history storage to something other
than files without requiring all users of history to change their
dotfiles.  (I'm thinking of, say, someone putting their history in
redis.)  Then again, saving history in files "ought to be enough for
anybody" :-)

>> 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.

OK, then how about a new special variable?  It's precedented for
variables to be magical (e.g., path/PATH, functrace).  We could have a
HIST_RECORD variable with the following semantics:

- getter: returns 1 (mathematical true) if HISTFILE is not empty and 0
  (mathematical false) if HISTFILE is unset.  (If HISTFILE is empty,
  then <handwave/>.)

- setter: If set to zero, unsets HISTFILE (again, that's like the
  connection between path and PATH).  If set to a true value, set
  HISTFILE to... Hmm, I'm not sure.  To a well-known value specified at
  configure time, probably?  Felipe, WDYT?

Net result: HIST_RECORD=1 DTRT's.

Of course, at this point we might as well make it a (possibly module-
provided) builtin, so it's less surprising and more extensible.

>> 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.
>

And moreover, zstyle itself is a module whereas history is not.
Good point.

>> 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.

If it's just this, then, s/zmodload module/$fpath function/, surely,
since this /can/ be implemented as a function?  The function could
unfunction itself, too.

Or if we do a special parameter or a new builtin, that could be done
in a module.

Cheers,

Daniel