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

[Mikael Magnusson <mikachu@xxxxxxxxx>]

On 8/26/22, Felipe Contreras <felipe.contreras@xxxxxxxxx> wrote:
> 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?

Not really, I haven't had great experiences arguing with you before.
You gave these examples earlier:

  sect(Why is my history not being saved?)
  label(321)

    In zsh you need to specifically enable history:
    verb(
      setopt SAVE_HISTORY
    )

vs

  sect(Why is my history not being saved?)
  label(321)

    In zsh, you need to set three variables to make sure your history is
    written out when the shell exits.  For example,
    verb(
      HISTSIZE=200
      HISTFILE=~/.zsh_history
      SAVEHIST=200
    )

But realistically the former actually has to be

autoload is-at-least
if is-at-least 5.8; then
  setopt SAVE_HISTORY
else
  HISTSIZE=200
  HISTFILE=~/.zsh_history
  SAVEHIST=200
fi

which isn't really a win. Besides that, the whole thing is way too
disruptive just for you to save 2 lines in your .zshrc.

-- 
Mikael Magnusson