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

[Felipe Contreras <felipe.contreras@xxxxxxxxx>]

On Fri, Aug 26, 2022 at 9:02 AM Mikael Magnusson <mikachu@xxxxxxxxx> wrote:
>
> 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.

That is not an argument. Do you care to explain why?

-- 
Felipe Contreras