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

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 8/26/22, Daniel Shahaf <d.s@xxxxxxxxxxxxxxxxxx> wrote:
> Bart Schaefer wrote on Thu, 25 Aug 2022 23:08 +00:00:
>> On Thu, Aug 25, 2022 at 3:44 PM Felipe Contreras
>> <felipe.contreras@xxxxxxxxx> wrote:
>>>
>>> This is *less* complicated:
>>
>> Every addition of an option to change the way something works is
>> making the shell as a whole more complicated and the interactions
>> among the settings more difficult to explain and understand.
>>
>> 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?
>
>> adding magical interdependencies and switches to enable same is not
>> IMO a good plan.
>
> 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«»; and then the default (zsh -f) could be to have HISTFILE set to
> some
> value but HIST_RECORD off.
>
> This design:
>
> - would not change the default behaviour.
>
> - would be compatible with existing dotfiles, since assigning to
>   HISTFILE would set HIST_RECORD implicitly.
>
> - would provide the ability to enable history without particularly
>   caring about the filename it's saved in, which would put us on par
>   with most other programs.  Most programs don't require the user
>   to name files the user doesn't interact with directly.  (cc(1) goes even
>   further with its default output filenames, such as foo.o and a.out.)
>
> - /would/ be an action at a distance.  However, in this case,
>   considering a user who unsets $HISTFILE in a universe in which
>   HIST_RECORD exists,  I don't immediately see what alternative
>   behaviour that user might expect.  As to a user who sets $HISTFILE and
>   expects HIST_RECORD to remain off, that's backwards compatibility.
>
> 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); in 5.10 recommend that people transition to the new
> way; starting 5.11 issue a warning if the old way is used, saying it's
> deprecated and will be removed no sooner than ${date or version number}.
>
> Any other alternatives?
>
> [The option's proposed name was chosen for consistency with other
> options and for avoidance of ambiguity with $SAVEHIST.]

My vote is to do nothing.

-- 
Mikael Magnusson