Re: Rewrite of zsh-newuser-install

[dana <dana@xxxxxxx>]

On 8 Feb 2021, at 15:57, Marlon Richert <marlon.richert@xxxxxxxxx> wrote:
> All right, here is my first draft:
> https://gitlab.com/marlonrichert/zsh-sensible/-/blob/master/zshrc

I want to see more of others' thoughts, but here are some initial comments.
Sorry in advance for how inherently bike-sheddy this whole process will be. :/

(Note: Any time i mention Debian below, you should probably read it as
Debian/Ubuntu/Mint/..., since they're usually all the same.)

> HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history
> zstyle ':completion:*' cache-path "${XDG_CACHE_HOME:-$HOME/.cache}/zcompcache"
> compinit -d ${XDG_CACHE_HOME:-$HOME/.cache}/zcompdump

In Daniel's original zshrc, he had made HISTFILE prefer XDGBDS, but i had put
it back to the more typical ${ZDOTDIR:-$HOME}, because there's a lot of
documentation/history behind it, and storing it in different places on
different OSes could create another support head ache on top of that.

I actually don't feel strongly about whether we respect XDGBDS or not. I'm
sure a lot of Linux users would appreciate it. But in addition to the
documentation/support concerns, there are some things to consider if we do:

* I can't see any reason to respect it in some cases but not others. If we use
  it for completion data, shouldn't we use it for history and anything else?

* How should we handle systems that don't normally use XDGBDS? Should we just
  force the issue and use it everywhere? Or should we have platform-specific
  logic to fall back to ${ZDOTDIR:-$HOME}?

* I think the spec says applications should create the directories if they
  don't exist, right? So shouldn't we `mkdir -pm 0700` them (or the defaults)
  if necessary? This relates to the previous point, since you certainly can't
  assume that e.g. ~/.cache and ~/.local will exist on macOS.

* Daniel had HISTFILE using $XDG_CACHE_HOME, but it should actually be
  $XDG_DATA_HOME, shouldn't it? I think CACHE is meant for unimportant
  'implementation' data, often stuff that'll be regenerated if you delete it,
  stuff that may even be stored in tmpfs — whereas i think of my shell history
  as persistent personal data.

> HISTFILE=${ZDOTDIR:-$HOME}/.zsh_history

I also don't have a strong opinion on .zsh_history vs .zhistory. The former is
the Debian/OMZ default, and i assume it gained popularity originally because
it's consistent with .bash_history, so i lean that way. Bart is right that the
latter is consistent with most of the other zsh files, though.

> setopt HIST_IGNORE_ALL_DUPS

This is a Debian default, which i give strong weight to, but idk, i like
HIST_IGNORE_DUPS instead. It's much less intrusive, it's the default OMZ
behaviour, and it's also the default Debian *bash* behaviour. (Both of those
also use the HIST_IGNORE_SPACE behaviour, which is why i had that in mine and
recommend it.)

> setopt HIST_REDUCE_BLANKS

I don't feel as strongly about this one, but it does feel a little like a
'pet' thing, not sure why it really needs to be there.

> setopt SHARE_HISTORY

This is a Debian/OMZ default, but it can cause issues in some configurations,
like Bart said. Don't feel super strongly, but i do lean against it.

I also think EXTENDED_HISTORY should be considered — i can't really think of
any down sides to it (?), and again it's an OMZ default.

> PS1='
> ...'

I see the appeal of multi-line prompts, but i really don't like one for a
default config. Nobody else does it afaik, and it seems likely to aggravate a
lot of people who are used to the traditional style. Putting the full $PWD in
the prompt makes it more justifiable, but i think we should just not do that.

I personally would suggest either just %1~ ($PWD base name, which is the OMZ
default) or something like %(3~|.../|)%2~ (which is similar to the Debian
default, and also about as close as we can get to the fish default without
adding a bunch of fancy logic).

> RPS1='%F{8}%D %*%f'

A time stamp in the prompt doesn't seem like something most users need, and i
personally find it confusing and unhelpful, since usually what you want to
know is when you ran the command associated with that prompt, not (as this
actually shows) when the command associated with the last prompt finished.

On prompts in general:

* Like Bart says, colours are very subjective. I'm not sure how to pick ones
  that will satisfy everyone. I can only suggest, again, taking inspiration
  from the defaults of Debian (both bash and zsh), OMZ, and fish.

* I like the right-hand prompt and use it myself, but one disadvantage it has
  is that it makes it annoying to copy and paste from your terminal. Not sure
  if it's a huge issue, but i foresee a possible future where heaps of novice
  users are including these long irritating strings of white space in their
  support requests.

* I do like the idea of encoding the return status in the prompt. I don't feel
  strongly about whether it's indicated by a colour, a symbol, and/or a
  number. I'm pretty sure red/green is the most common type of
  colour-blindness, though, so maybe a colour-only approach is not ideal.

* Whatever we pick for our prompt, should we maybe implement it using the
  prompt-theme system? I don't use it myself, so i'm not sure if it has any
  big down sides, but Debian use it in their defaults, and i guess it would
  make it a little easier for people to adopt if they don't want to use the
  rest of the file.

> zstyle ':completion:*:(functions|parameters|users)' ignored-patterns '[[:punct:]]*[[:alnum:]]*'

Not sure about this. I like hiding completion functions (which i did in mine),
because their naming format is pseudo-reserved for zsh by convention, and i've
seen many people confused by their appearance in completion possibilities. But
anything beyond that seems heavy-handed for a default.

> # Don't complete options or files if we have better things to offer.
> # Sort files case-insensitively.
> # Complete executables in command position, but not normal files.

A lot of this stuff seems over-elaborate and i worry that it could have
confusing side-effects in some cases, though i can't think of anything
specifically. One thing i definitely don't like is the _lowercase function,
since as i mentioned that naming convention is pseudo-reserved.

> export -T LS_COLORS ls_colors
> export -T ZLS_COLORS zls_colors=(

Nit-picking, but using export for this initially confused me. You're not
exporting them (and don't want to). I think you should just use typeset.

> unsetopt AUTO_PARAM_SLASH
> setopt AUTO_NAME_DIRS

Again, these seem like kind of 'pet' things, not sure why the average user
would need them.

On completion and key bindings in general, these settings require a lot of
mental energy for me to even process, so i haven't looked too closely at them
aside from what i've mentioned here. Behaviour related to menu completion,
auto-listing, &c., definitely needs some thorough consideration, though, since
i know people have strong feelings about that.

I had some other ideas when i was working on this before, but i can't recall
them at the moment. The only other thing i want to add is that `bindkey -e` is
a Debian/OMZ default, and i've seen a lot of people who had EDITOR=vi(m) but
didn't want vi mode in the shell, so i think it makes sense for a default.
People who use vi mode will know how to get it back.

Thanks for resurrecting this idea btw

dana