Re: Rewrite of zsh-newuser-install

[Oliver Kiddle <opk@xxxxxxx>]

Marlon Richert wrote:
> 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.

zsh-newuser-install could also check $XDG_DATA_HOME and handle the mkdir
if the user agrees. Then leave it hardcoded in the fresh .zshrc. There's
benefits to leaving people with a simpler config file.

If we do end up asking questions in zsh-newuser-install, I'd prefer
less text initially. I see it just often enough (with empty accounts)
that I have to skim the text to work out how to tell it to just go away
and give me a prompt. Currently, the wording can leave you unsure as
to whether q quits zsh completely. Escape or Ctrl-C should work and I
wouldn't mind if only one key continues with setup and anything else
goes to print -z.

> I personally don't use truncation, because I use a multi-line prompt.

I do actually use the conditional newline that the oliver theme
demonstrates even though I don't otherwise use that theme. I like
having a complete path that can be selected with the mouse and pasted
elsewhere. Most of the time my prompt remains single-line.

> 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.

As I think Bart mentioned, if you use zstyle after compinit it should
definitely be safe.

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

With a matcher, you'll only complete one of them unless you have
_all_matches. _extensions preserves the all sense by leaving the initial
*. or ^*. alone. It is mostly less useful because most extensions are
short - but it is generally fairly harmless too.

> > > # m:{[:lower:]-}={[:upper:]_} does foo-bar -> FOO_BAR
> > but not vice versa.
>
> Yes, that is intentional. :)

I realise. I mentioned it as a suggested addition to the comment because
it might not be obvious to a new user.

> > > # 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.

What I was alluding to there is that there are times when I'll type an
initial prefix to limit the sort of matches I get. So with this,
completion after the following does not give me only completion functions:
  which _<tab>
Any command with an underscore gets matched while completion functions
remain ignored.

Otherwise it is sometimes quite aggressive and transforms what you've typed
considerably. I've known people to complain about _approximate for that.
I'm personally not keen on the ** forms with r:

If you like it that way, don't mind me. I've probably built up habits
over the years that would never be intuitive to a new user anyway.

> > 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.

That's fine. The generic solution is probably more appropriate here just
perhaps not quite so aggressive. I wasn't suggesting that style just
using it as an example. Certainly I would also be hesitant to include
it and dozens like it. (Though your following one for options is along
similar lines.)

> > > # 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. :)

It only applies at the beginning of a word. So typeset -<tab> will still
list all the + options which I assume is the intent. The m: form matches
any - to any +, b: only at the beginning. Removing the curly brackets has
no effect on the behaviour, they're superfluous when you only have one
character.

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

That's already yank, unfortunately.

> > > 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:

> Should that text be changed?

The text appears to be correct - I didn't know that. So no change
needed.

Oliver