From: Oliver Kiddle <opk@zsh.org>
To: Marlon Richert <marlon.richert@gmail.com>
Cc: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Rewrite of zsh-newuser-install
Date: Sat, 13 Feb 2021 02:36:41 +0100 [thread overview]
Message-ID: <67415-1613180201.366561@nSDd.R0ox.wLYA> (raw)
In-Reply-To: <CAHLkEDtK5n56GjXKhR4VVCXcYUKjPzQb0zoj9E=BecsMsyWkFQ@mail.gmail.com>
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
next prev parent reply other threads:[~2021-02-13 1:36 UTC|newest]
Thread overview: 117+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-02-06 20:03 Marlon Richert
[not found] ` <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com>
2021-02-06 20:19 ` Marlon Richert
2021-02-06 20:33 ` Lawrence Velázquez
2021-02-06 21:54 ` Bart Schaefer
2021-02-07 13:41 ` Marlon Richert
2021-02-07 13:51 ` Roman Perepelitsa
2021-02-07 17:10 ` Marlon Richert
2021-02-07 17:28 ` Marlon Richert
2021-02-07 20:20 ` Bart Schaefer
2021-02-07 21:06 ` dana
2021-02-07 21:15 ` Marlon Richert
2021-02-08 21:57 ` Marlon Richert
2021-02-08 23:33 ` Lawrence Velázquez
2021-02-09 1:42 ` Bart Schaefer
2021-02-09 2:00 ` Bart Schaefer
2021-02-09 8:18 ` Marlon Richert
2021-02-09 23:09 ` Bart Schaefer
2021-02-09 8:17 ` Marlon Richert
2021-02-09 8:29 ` Roman Perepelitsa
2021-02-09 23:16 ` Bart Schaefer
2021-02-12 0:09 ` Bart Schaefer
2021-02-12 5:58 ` Marlon Richert
2021-02-09 4:51 ` dana
2021-02-09 6:00 ` Bart Schaefer
2021-02-09 7:30 ` dana
2021-02-09 7:34 ` dana
2021-02-09 9:55 ` Marlon Richert
2021-02-09 10:01 ` Roman Perepelitsa
2021-02-09 10:04 ` Marlon Richert
2021-02-09 10:56 ` dana
2021-02-09 11:14 ` Roman Perepelitsa
2021-02-09 11:39 ` Marlon Richert
2021-02-09 17:21 ` dana
2021-02-09 21:01 ` Marlon Richert
2021-02-09 21:41 ` Marlon Richert
2021-02-09 23:15 ` dana
2021-02-10 0:02 ` Bart Schaefer
2021-02-10 7:02 ` Marlon Richert
2021-02-10 6:57 ` Marlon Richert
2021-02-12 0:10 ` Bart Schaefer
2021-02-12 5:59 ` Roman Perepelitsa
2021-02-13 0:23 ` dana
2021-02-10 2:30 ` Bart Schaefer
2021-02-10 7:44 ` Marlon Richert
2021-02-10 20:27 ` Marlon Richert
2021-02-11 8:30 ` Bart Schaefer
2021-02-11 21:11 ` Marlon Richert
2021-02-11 22:57 ` Bart Schaefer
2021-02-12 5:49 ` Marlon Richert
2021-02-12 5:47 ` Marlon Richert
2021-02-12 23:43 ` Oliver Kiddle
2021-02-13 1:11 ` Bart Schaefer
2021-02-12 23:26 ` Oliver Kiddle
2021-02-13 0:15 ` Marlon Richert
2021-02-13 1:33 ` Bart Schaefer
2021-02-13 1:36 ` Oliver Kiddle [this message]
2021-02-13 2:53 ` Bart Schaefer
2021-02-13 10:26 ` Marlon Richert
2021-02-13 22:53 ` Marlon Richert
2021-02-14 0:34 ` Bart Schaefer
2021-02-14 8:12 ` Marlon Richert
2021-02-13 22:56 ` Bart Schaefer
2021-02-14 8:01 ` Marlon Richert
2021-02-19 21:38 ` Marlon Richert
2021-02-20 0:30 ` dana
2021-02-20 8:18 ` Marlon Richert
2021-02-20 18:57 ` Bart Schaefer
2021-02-21 19:24 ` Marlon Richert
2021-02-24 22:15 ` dana
2021-02-25 8:05 ` Daniel Shahaf
2021-02-25 16:58 ` dana
2021-02-26 22:31 ` Marlon Richert
2021-02-27 13:21 ` Daniel Shahaf
2021-02-27 13:46 ` Daniel Shahaf
2021-03-19 22:12 ` Marlon Richert
2021-03-24 13:45 ` gi1242+zsh
2021-03-24 14:16 ` Paul
2021-03-24 17:44 ` Bart Schaefer
2021-03-24 20:38 ` Marlon Richert
2021-03-25 3:36 ` Paul
2021-04-05 18:16 ` Daniel Shahaf
2021-04-05 18:52 ` Sorting of <-> (was Re: Rewrite of zsh-newuser-install) Bart Schaefer
2021-04-05 21:31 ` Rewrite of zsh-newuser-install gammafunction
2021-04-07 14:45 ` Marlon
2021-04-09 16:49 ` Marlon
2021-04-09 23:14 ` Daniel Shahaf
2021-04-10 1:17 ` Oliver Kiddle
2021-04-07 18:17 ` Mikael Magnusson
2021-04-07 18:56 ` Daniel Shahaf
2021-03-24 10:00 ` Marlon Richert
2021-03-25 1:15 ` Daniel Shahaf
2021-04-05 14:00 ` Marlon Richert
2021-04-05 18:36 ` Daniel Shahaf
2021-04-05 19:22 ` Daniel Shahaf
2021-02-22 3:54 ` Paul
2021-02-22 8:14 ` Marlon Richert
2021-02-22 16:31 ` Bug in compdescribe with matcher 'b:-=+' Bart Schaefer
2021-06-14 8:28 ` Marlon Richert
2021-08-12 12:03 ` Marlon Richert
2021-08-12 16:15 ` Bart Schaefer
2021-02-19 21:34 ` Rewrite of zsh-newuser-install Marlon Richert
2021-02-13 1:28 ` Bart Schaefer
2021-02-13 1:34 ` Bart Schaefer
2021-04-22 13:57 ` Marlon Richert
2021-02-09 23:05 ` Bart Schaefer
2021-02-09 9:44 ` Marlon Richert
2021-02-09 18:13 ` Greg Klanderman
2021-02-08 9:21 ` Peter Stephenson
2021-02-08 6:35 ` Daniel Shahaf
2021-02-08 8:44 ` Marlon Richert
2021-02-08 8:46 ` Marlon Richert
2021-02-08 10:32 ` Daniel Shahaf
2021-02-08 17:44 ` Marlon Richert
2021-02-08 20:47 ` Bart Schaefer
2021-02-09 21:44 ` Eric Cook
2021-02-09 22:34 ` Bart Schaefer
2021-02-07 20:22 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67415-1613180201.366561@nSDd.R0ox.wLYA \
--to=opk@zsh.org \
--cc=marlon.richert@gmail.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).