Re: Rewrite of zsh-newuser-install

[Marlon Richert <marlon.richert@xxxxxxxxx>]

On Sat, Feb 13, 2021 at 1:26 AM Oliver Kiddle <opk@xxxxxxx> wrote:
> > # Use `exec zsh` to apply changes after editing this file.
>
> Not sure I'd recommend that because if you mistype "zsh", your shell+terminal
> disappears. And if they've broken .zshrc, that can leave them unable to log
> back in.

I got this tip from Roman. We've both seen new users get into all
kinds of trouble by repeatedly doing `source ~/.zshrc`.


> > HISTFILE=${ZDOTDIR:-${XDG_DATA_HOME:-$HOME/.local/share}/zsh}/history
>
> > # Create parent dir, if necessary.
> > if [[ ! -d $HISTFILE:h ]]; then
> >   zmodload -F zsh/files b:zf_mkdir
> >   zf_mkdir -pm 0700 - $HISTFILE:h
> > fi
>
> I'm not sure it helps new users to understand their new setup file if it needs
> this stuff. Should we just keep it simple at the expense of ignoring the XDG stuff.

Bart suggested we could instead, in zsh-newuser-install, ask the users
what they would actually prefer. I think that's reasonable. I put a
suggested text in my reply to him. I will start adding the new version
of zsh-newuser-install to the repo, too.


> > # %x<y<z%<<: if z is wider than x characters, then trim z from the left & insert y
>
> The trunction adds complexity that I'm not sure is needed. Many people want to
> know how to enable vcs_info. I'm not saying it should be included by
> default but perhaps in a comment.

I personally don't use truncation, because I use a multi-line prompt.
Others in this thread, though, insisted that new users should get a
single-line prompt. However, if you use an 80-column terminal that
often means you will run out of horizontal space quickly. I tried
truncating by leaving out segments, but I found the effect of that
undesirable: When the segments are short, it feels like information is
needlessly being hidden from you, whereas when the segments are long,
it still doesn't really save any space. Truncating to a fixed width
proved to be much more pleasant all-round, IMO. This way, it looked
more like the path was scrolling off-screen, which felt more natural.


> > zmodload -F zsh/zutil b:zstyle    # Load `zstyle` builtin.
>
> Is that really needed? I've never bothered.

I guess it depends on your Zsh installation. I thought I'd better be
safe than sorry. I already saw one error where add-zle-hook-widget
failed, because zsh/zle wasn't loaded yet.


> > # These are tried in order until one of them succeeds:
> > # _expand: expansion substitutions (See http://zsh.sourceforge.net/Doc/Release/Expansion.html)
> > # _complete: regular completions
> > # _history: words from history
> > # _correct: spelling corrections
> > # _ignored: any completions that have been ignored so far
> > zstyle ':completion:*' completer _expand _complete _history _correct _ignored
>
> These seem reasonable choices. _extensions wouldn't cause any unpleasant
> surprises for a new user but it does need to come first.

_extensions feels rather useless when you can get the same effect
through matchers, but without requiring the leading *.


> > # m:{[:lower:]-}={[:upper:]_} does foo-bar -> FOO_BAR
> but not vice versa.

Yes, that is intentional. :)


> > # r:|?=** does fbr -> foo-bar and bar -> foo-bar
> > zstyle ':completion:*:complete:*' matcher-list \
> >   'r:|[.]=** r:?|[-_]=** l:?|=[-_] m:{[:lower:]-}={[:upper:]_}' \
> >   'r:|?=** m:{[:lower:]}={[:upper:]}'
>
> I'd be significantly more conservative on these. They really can cause
> surprises for new users and break some things completely like trying to force
> the type of listed matches with punctuation prefixes.

I've used something like this for quite a while now. I'm unsure what
kind of breakage you are referring to.


> I mostly use generous matchers with more specific contexts.
> To give one example, the following helps when suspended jobs are all
> man, less or vim and I want to select on the argument:
> zstyle ':completion:*:(-command-|[fb]g):*:jobs' matcher 'l:%|=*'

I'm hesitant to do this kind of tweaking. I'd rather apply the Pareto
principle and have a generic solution that's good enough for most
cases. If there's anything specific that needs to be done for certain
completion, then it should happen in the completion function IMO.


> > # For options only, add - -> + for each item in the list above.
> > zstyle ':completion:*:options' matcher 'm:{-}={+}'
>
> Isn't the more limited 'b:-=+' sufficient here?

Perhaps, if you can explain to me what it does. :)


> > # Show and insert `man` sections.
> > zstyle ':completion:*' insert-sections yes
>
> I wouldn't bother for section 1:
>   zstyle ':completion:*:manuals.(^1*)' insert-sections true
>
> Not only because it is mostly redundant but it is easier to simplify that to
> all sections than to do the reverse.

Again, I don't see any real gain to adding that. It works fine without.


> I'd be inclined to bind Ctrl-Z to undo. Forget Emacs and Vi - Ctrl-Z is what
> the rest of the world uses for undo. That doesn't disable anything else and too
> few people know the shell has an undo. It's invaluable with completion,
> especially with approximate completion or the fuzzier matching controls such as
> r:|?=**.

Sure. And then Ctrl-Y to redo? Seems reasonable to me.


> > setopt GLOB_STAR_SHORT      # Use `**` for recursive globbing; `***` to include symlinks, too.
>
> Need to say 'without a trailing "/"' **/ is already recursive globbing
> and you don't need this option to enable it.
>
> The comment confused me but like Bart I don't use the option but found
> myself wondering whether I should.

I personally find it quite useful, especially when combined with the
_expand completer. :)


> > typeset -gU PATH path FPATH fpath CDPATH cdpath MANPATH manpath
>
> These are tied, no need to list both forms.

The documentation of typeset -U says otherwise, though:

http://zsh.sourceforge.net/Doc/Release/Shell-Builtin-Commands.html#index-typeset
> -U
> For arrays (but not for associative arrays), keep only the first occurrence of each duplicated value. This may also be set for tied parameters (see -T) or colon-separated special parameters like PATH or FIGNORE, etc. Note the flag takes effect on assignment, and the type of the variable being assigned to is determinative; for variables with shared values it is therefore recommended to set the flag for all interfaces, e.g. ‘typeset -U PATH path’.

Should that text be changed?


> The -g adds nothing either outside of a function.

I know, but I felt like it's good to be consistent, in case the user
ever puts in a function.


Thanks for your input!