From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,UNPARSEABLE_RELAY autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 30722 invoked from network); 13 Feb 2021 10:27:40 -0000 Received: from zero.zsh.org (2a02:898:31:0:48:4558:7a:7368) by inbox.vuxu.org with ESMTPUTF8; 13 Feb 2021 10:27:40 -0000 ARC-Seal: i=1; cv=none; a=rsa-sha256; d=zsh.org; s=rsa-20200801; t=1613212060; b=MgF9Jxzp/+KwPLd54sg+CqnIbf99Np3FIjHJ5lqb9KSyHYpItSpdtY3/6BimQ+4slN0Y0Mj9B+ dIzxEGuFP9wv+I9/tALu4iYglPoof7+7HYFoAhb4/MdZFurFhtlSxDKB0yQqiDh8+ftDK91Vii jOXPLfHtPRPZYFi4bNfyKhhG6qCQ3mf8BpQ+VRcj0qnqSL/naDEZLlknBX+Um7YZiQyQkiv49n rti4f+Sgo+StBauuErQr0Q2h5lKSD+FForrtW8DdzTyAOVabYPxb+C/plwmVWkD8TaKHaBNibH IszS0HlvCKKsRlm1otCPiXn2+W2PoEXPXawRoAdElPObrg==; ARC-Authentication-Results: i=1; zsh.org; iprev=pass (mail-lj1-f177.google.com) smtp.remote-ip=209.85.208.177; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed; d=zsh.org; s=rsa-20200801; t=1613212060; bh=CNbG7J8YzgRWg/XF/QAdIcY5xIr89PABJ5PGknrLf5U=; h=List-Archive:List-Owner:List-Post:List-Unsubscribe:List-Subscribe:List-Help: List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID:Date:From:In-Reply-To: References:MIME-Version:DKIM-Signature:DKIM-Signature; b=RVyvnTOCssgy7HTxRBjwEFTjWrnNVBSDDIQJKBYUqpGnycDcZ2EKWQf+e++3fjKSy+faHamEMm lDkQrOrfvwQxQrZ71/6N7GU2Yvk3xlUL6LsQvQmP1kYTKb8HuffU/pL4DQDsDEHFfnmfKWPkzA yxILi4wqiEkjHnSCiRJHrvmYAje+8JT2xzBIYhag4F/84qA94w1aOP7GcCcN2vEYPKunBw65Fa 9JXbBvnihsAtniufjbzpiPPfSmBv8lxUwu2ANs30EM4JGfhOrRERUJv25D8m+xouX5Vmne9qTi dPwdsznA9FuGIL9G0SyKz8hbo1DCamG1rNB/QJCS1yNoFw==; DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=zsh.org; s=rsa-20200801; h=List-Archive:List-Owner:List-Post:List-Unsubscribe: List-Subscribe:List-Help:List-Id:Sender:Content-Type:Cc:To:Subject:Message-ID :Date:From:In-Reply-To:References:MIME-Version:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=bb1CAZ4DPsf9WaDCfUTQ9aSa+p3VkHDIoF8qZM5OBmc=; b=ad+D/rRdadOM4flfeJMoecPJ2b H2jhuZvupUja2KG4GlwUT7n9ZpV1D4Eg7UhbIUVdkQ/+ITthMA0Q78TMWlTIY6UYxbg6QpdF05UXx erGltbKGARVAckpDhkLY+uJoa21PxI+bIJgZcHGjI6qN0kaDuVZscxTc6ybVnKlK8+Gy4949CVV3q w6fpLoRmgSIf6CaXIqqWf4n9XsfmobOHGygxzeXm9gmiU+kCc+wr3fT/FXsct/tE29FqdEOMJ1Lld zla7fVLOfh+/TZTyf+RelGrODCLqJVguyh4Ao9p/mQ8UDv8FRZXD/K1SnvAdDpBDUWhRjuxmJl1No T9ITHGYQ==; Received: from authenticated user by zero.zsh.org with local id 1lAs9J-0002dc-LD; Sat, 13 Feb 2021 10:27:37 +0000 Authentication-Results: zsh.org; iprev=pass (mail-lj1-f177.google.com) smtp.remote-ip=209.85.208.177; dkim=pass header.d=gmail.com header.s=20161025 header.a=rsa-sha256; dmarc=pass header.from=gmail.com; arc=none Received: from mail-lj1-f177.google.com ([209.85.208.177]:33712) by zero.zsh.org with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) id 1lAs8z-0002UO-Gs; Sat, 13 Feb 2021 10:27:18 +0000 Received: by mail-lj1-f177.google.com with SMTP id c17so951086ljn.0; Sat, 13 Feb 2021 02:27:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=bb1CAZ4DPsf9WaDCfUTQ9aSa+p3VkHDIoF8qZM5OBmc=; b=opPaNgO1yr3XuR60YKPLXPRZ5otpyT2h5LOZtfGw4SsACVTdy4oB4UoCKRPrsj88+S Dy0Psj76SmUzZjdclrdUe55Pkl9OKgFGMW2c5Xa8Hm2KUR1nL1lINfzu2ts+sLxtpedh QB4Uu8uAQy+L2yotHhS7S4bUpaUVM/wfM+rhzErOd6mXDRDF8jPcnpu366vTw3PxCC9i VWgYxHuDrXpsvNvNUqSAp9gkrpNMcEsA7mFptqBsc3rQiu1laQEIWdX6pOhbt2Hvswbh XRSga8QaGCR/pfSvlxm13+g5fg1yomeKelKs6N9cuxKHFWHOHS5nd3J8PDJfa0vQWyrx 2i5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=bb1CAZ4DPsf9WaDCfUTQ9aSa+p3VkHDIoF8qZM5OBmc=; b=mbrch+970kXNrQRLFcXhr6jjBKJns+5s3qYcQuWDXdwxpUetEeuPZWdPBOyfE9sWVB XBvpthHpa5vGjZ8Eh9yokUhwRZUh0iCijb7baoWVztlHwTLfjeqQyA8Aa+qKVcGtnEm8 UUsEx3d2/FB7JCKssoqQJP5ol3vCWoe/kAiOkREKc9/VvnTR33JNrn6haJlMbjmuUXWz 5QUg7Q78IzxFF3Bfmd6ndW8Bs1BZ0pVAvYt5SVdROaIO0Y4pro11GSErcw9Cu9KvsbNz 0Gb0mCAiDftYozAv2nMbrcKCe1mnv/VsSkHkDuhdJfH2gs/2D2P/0gBxMXCPUe5wHP1W 2SLQ== X-Gm-Message-State: AOAM533zr8zfI2L8wOGN1Kmv1vQTuT7MyO3IQploSs0l3Xju8IW1Uxje at2u58+1GIgLNLNcQOmXm+/zahCEkhtE0Ldeh3rKtSrLZMIPKQ== X-Google-Smtp-Source: ABdhPJzgYeOUlKi5LUpZrNavN0zKQUNZJmZTQBMiJ8i81Z8YcokMCp2gVDTbqGAPBer0iuNDsxDJADACtCYh1jpbFyQ= X-Received: by 2002:a2e:8986:: with SMTP id c6mr4061061lji.82.1613212036113; Sat, 13 Feb 2021 02:27:16 -0800 (PST) MIME-Version: 1.0 References: <0102017778f35f33-a962e4d3-83e9-4d3b-a0d7-45701bb40b11-000000@eu-west-1.amazonses.com> <8BA25288-0FFB-4FF4-9799-541D6A3C52DA@dana.is> <19996A10-103F-4054-AD57-FCED8E406687@dana.is> <86782FA5-6EBB-4FCD-90AD-D33F352455F1@dana.is> <63124-1613172369.335393@kj4H.lfui.ly3G> <67415-1613180201.366561@nSDd.R0ox.wLYA> In-Reply-To: <67415-1613180201.366561@nSDd.R0ox.wLYA> From: Marlon Richert Date: Sat, 13 Feb 2021 12:26:39 +0200 Message-ID: Subject: Re: Rewrite of zsh-newuser-install To: Oliver Kiddle , Bart Schaefer , dana Cc: Zsh hackers list Content-Type: multipart/alternative; boundary="0000000000005c294e05bb353225" X-Seq: 48040 Archived-At: X-Loop: zsh-workers@zsh.org Errors-To: zsh-workers-owner@zsh.org Precedence: list Precedence: bulk Sender: zsh-workers-request@zsh.org X-no-archive: yes List-Id: List-Help: List-Subscribe: List-Unsubscribe: List-Post: List-Owner: List-Archive: Archived-At: --0000000000005c294e05bb353225 Content-Type: text/plain; charset="UTF-8" Thank you all for your input! :) Since there's a lot of overlap and redundancy by now, I'll reply to everything in one email. On Sat, Feb 13, 2021 at 2:23 AM dana wrote: > it doesn't seem like creating an > up-stream config that does less than what people are already getting for zsh > defaults in the real world will be very useful to anyone. It may be nice for > completeness's sake to have something 'official', but presumably neither those > distributors nor their users will be very interested in it if they already > have something that does the same job or better. > > I'm not sure about the others, but my personal desire with a config like this > was to reduce the perceived need that people have to immediately go out and > install something like OMZ. We can't make much of a dent in that if it's *too* > minimal. I just want to say that I completely agree with all of the above. > That said, i do think there are plenty of things that are outside the > scope of that goal, like fancy Unicode characters and clocks in the prompt. > (Looks like those aren't in the current revision, but just for example i > mean.) I'm starting to agree that XDGBDS is excessive too. Maybe some other > things. I definitely don't think it needs to be 'the best'... just nice enough > that people might actually use it. Yes, I can get behind that. On Sat, Feb 13, 2021 at 3:11 AM Bart Schaefer wrote: > That shouldn't be true either. zstyle is an autoloaded builtin. Is there a list of which modules and their builtins get autoloaded? I cannot find this documented anywhere. On Sat, Feb 13, 2021 at 3:28 AM Bart Schaefer 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. > > zsh -l && exit > > perhaps? Also, check for minimal correctness with > > zsh -nf .zshrc Should we perhaps add a function that does that, to save the user from having to remember this? Something like this: zrestart() { zsh -nf .zshrc && zsh -l && exit } Not sure about the name. On Sat, Feb 13, 2021 at 3:33 AM Bart Schaefer wrote: > > I already saw one error where add-zle-hook-widget > > failed, because zsh/zle wasn't loaded yet. > > That's an entirely different thing, and might be happening because > zsh/newuser is loaded too early in the startup. No, this was with the code copy-pasted directly into a .zshrc file. No zsh/newuser involved. > > > I'd be inclined to bind Ctrl-Z to undo. > > > > Sure. And then Ctrl-Y to redo? Seems reasonable to me. > > No, ^Y is already bound to "yank", don't change that. The point is ^Z > isn't bound, so it's harmless to bind it. What about using ^Z for undo and ^[z for redo? That's similar to Cmd-Z for undo and Cmd-Shift-Z for redo in macOS. Although, I'm starting to think, given the amount of custom key bindings the new .zshrc includes by now, would it make more sense to introduce a completely new keymap in the C code? As Oliver stated: > Forget Emacs and Vi - Ctrl-Z is what the rest of the world uses for undo. Well, the rest of the world also uses Ctrl-V for paste, plus a whole bunch of other standardized keyboard shortcuts that are nothing like those used in shells, some of which I added in this new user .zshrc. However, that part of the file is getting quite long. If we would introduce an entirely new keymap for this, then we would both make this new user .zshrc more simple _and_ give an easy way for all the other users to get the same keybindings, without having to maintain them individually in their .zshrc files. On Sat, Feb 13, 2021 at 3:36 AM Oliver Kiddle wrote: > 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. Yes, if we already ask this in zsh-newuser-install, then there's no need to also check for this in the .zshrc file. > If we do end up asking questions in zsh-newuser-install, I'd prefer > less text initially. Oh yes, completely agree. KISS. > 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. > > PS1="$pcolr$user$host%~%"'$((COLUMNS-12))'"(l.$prompt_newline. )[%h%1(j.%%%j.)%0(?..:%?)]%# %b%f%k" I used PROMPT_SUBST with $((COLUMNS)) earlier, but Dana & Bart were against it: > > > > setopt PROMPT_SUBST > > > > > > I think most of the devs discourage PROMPT_SUBST. If nothing else it feels a > > > bit advanced for what we're trying to achieve here > > > > Why exactly do you discourage the use of PROMPT_SUBST? Why is it a problem? > > Here's one reason: > > zsh% P='${(%%)P}' > zsh% setopt promptsubst > zsh% print -P $P > zsh: segmentation fault (core dumped) Src/zsh -f > > Do that accidentally once with PS1 or RPS1, and you're locked out of your shell. > > The main thing, though, is that it encourages the prompt to contain > $(fork something expensive). If you have to think about when/where > you're capturing that output, you write better code. > As I think Bart mentioned, if you use zstyle after compinit it should > definitely be safe. Sure, but compinit actually checks the completer style to decide whether to rebind ^I to complete-word or leave it at expand-or-complete. So, then at least that style needs to come before compinit and then we have to zmodload zstyle before compinit anyway. Should then perhaps that piece of code in compinit be changed, so all zstyle calls can occur after compinit? > > _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. If I want multiple files with an extension, then _expand handles *.foo just fine. I still don't see the point of _extensions. :) > > > > # 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 _ > 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: But r:|?=** is part only of the second matcher. When you type _, it will get matched already by the first matcher in matcher-list. > > > 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.) I feel like options are common enough to warrant an exception, especially because they won't get shown until you type a dash. Without the additional matcher below, you might never realize that `set` and `functions` (for example) also have + options, because they will not get listed. > > > > # 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 - 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. Thanks, I didn't know that. That wasn't clear to me from the way it's described in the documentation: http://zsh.sourceforge.net/Doc/Release/Completion-Widgets.html#Completion-Matching-Control > The b and B forms are similar to l and L with an empty anchor, but need to match only the beginning of the word on the command line or trial completion, respectively. --0000000000005c294e05bb353225 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you all for your input= ! :) Since there's a lot of overlap and redundancy by now, I'll rep= ly to everything in one email.


<= /font>
On Sat, Feb 13, 2021 at 2:23 AM dana <dana@dana.is> wrote:
> it doesn't seem like crea= ting an
> up-stream config that does less than what people are alread= y getting for zsh
> defaults in the real world will be very useful to= anyone. It may be nice for
> completeness's sake to have somethi= ng 'official', but presumably neither those
> distributors no= r their users will be very interested in it if they already
> have so= mething that does the same job or better.
>
> I'm not sure = about the others, but my personal desire with a config like this
> wa= s to reduce the perceived need that people have to immediately go out and> install something like OMZ. We can't make much of a dent in that= if it's *too*
> minimal.

I just want to say that I comple= tely agree with all of the above.


> That said, i do think the= re are plenty of things that are outside the
> scope of that goal, li= ke fancy Unicode characters and clocks in the prompt.
> (Looks like t= hose aren't in the current revision, but just for example i
> mea= n.) I'm starting to agree that XDGBDS is excessive too. Maybe some othe= r
> things. I definitely don't think it needs to be 'the best= '... just nice enough
> that people might actually use it.
Yes, I can get behind that.


On Sat, Feb 13, 2021 at 3:11 AM Bar= t Schaefer <schaefer@brassl= antern.com> wrote:
> That shouldn't be true either. =C2=A0= zstyle is an autoloaded builtin.

Is there a list of which modules an= d their builtins get autoloaded? I cannot find this documented anywhere.

On Sat, Feb 13, 2021 at 3:28 AM Bart Schaefer <schaefer@brasslantern.com> wrote:
&g= t; > > # Use `exec zsh` to apply changes after editing this file.
= > >
> > Not sure I'd recommend that because if you misty= pe "zsh", your shell+terminal
> > disappears. And if the= y've broken .zshrc, that can leave them unable to log
> > back= in.
>
> zsh -l && exit
>
> perhaps?=C2=A0 = Also, check for minimal correctness with
>
> zsh -nf .zshrc
=
Should we perhaps add a function that does that, to save the user from = having to remember this? Something like this:

zrestart() {
=C2=A0= zsh -nf .zshrc && zsh -l && exit
}

Not sure abou= t the name.


On Sat, Feb 13, 2021 at 3:33 AM Bart Schaefer <schaefer@brasslantern.com>= ; wrote:
> > I already saw one error where add-zle-hook-widget
= > > failed, because zsh/zle wasn't loaded yet.
>
> Th= at's an entirely different thing, and might be happening because
>= ; zsh/newuser is loaded too early in the startup.

No, this was with = the code copy-pasted directly into a .zshrc file. No zsh/newuser involved.<= br>

> > > I'd be inclined to bind Ctrl-Z to undo.
&g= t; >
> > Sure. And then Ctrl-Y to redo? Seems reasonable to me.=
>
> No, ^Y is already bound to "yank", don't cha= nge that.=C2=A0 The point is ^Z
> isn't bound, so it's harmle= ss to bind it.

What about using ^Z for undo and ^[z for redo? That&#= 39;s similar to Cmd-Z for undo and Cmd-Shift-Z for redo in macOS.

A= lthough, I'm starting to think, given the amount of custom key bindings= the new .zshrc includes by now, would it make more sense to introduce a co= mpletely new keymap in the C code? As Oliver stated:

>=C2= =A0Forget Emacs and Vi - Ctrl-Z is what the rest of the world uses f= or undo.

Well, the rest of the world also uses Ctr= l-V for paste, plus a whole bunch of other standardized keyboard shortcuts = that are nothing like those used in shells,=C2=A0some of which I added in t= his new=C2=A0user .zshrc. However, that part of the file is getting quite l= ong. If we would introduce an entirely new keymap for this, then we would b= oth make this new user .zshrc more simple _and_ give an easy way for all th= e other users to get the same keybindings, without having to maintain them = individually in their .zshrc files.

On Sat, Feb 13, 2021 at 3:36 AM Oliver Kiddle <opk@zsh.org> wrote:
> zsh-newuser-install could also c= heck $XDG_DATA_HOME and handle the mkdir
> if the user agrees. Then l= eave it hardcoded in the fresh .zshrc. There's
> benefits to leav= ing people with a simpler config file.

Yes, if we already ask this i= n zsh-newuser-install, then there's no need to also check for this in t= he .zshrc file.


> If we do end up asking questions in zsh-new= user-install, I'd prefer
> less text initially.

Oh yes, co= mpletely agree. KISS.


> I do actually use the conditional new= line that the oliver theme
> demonstrates even though I don't oth= erwise use that theme. I like
> having a complete path that can be se= lected with the mouse and pasted
> elsewhere. Most of the time my pro= mpt remains single-line.
>
> PS1=3D"$pcolr$user$host%~%&qu= ot;'$((COLUMNS-12))'"(l.$prompt_newline. )[%h%1(j.%%%j.)%0(?..= :%?)]%# %b%f%k"

I used PROMPT_SUBST with $((COLUMNS)) earlier, = but Dana & Bart were against it:

> > > > setopt PROM= PT_SUBST
> > >
> > > I think most of the devs disco= urage PROMPT_SUBST. If nothing else it feels a
> > > bit advanc= ed for what we're trying to achieve here
> >
> > Why = exactly do you discourage the use of PROMPT_SUBST? Why is it a problem?
= >
> Here's one reason:
>
> zsh% P=3D'${(%%)P}&= #39;
> zsh% setopt promptsubst
> zsh% print -P $P
> zsh: = segmentation fault (core dumped) =C2=A0Src/zsh -f
>
> Do that a= ccidentally once with PS1 or RPS1, and you're locked out of your shell.=
>
> The main thing, though, is that it encourages the prompt t= o contain
> $(fork something expensive).=C2=A0 If you have to think a= bout when/where
> you're capturing that output, you write better = code.


> As I think Bart mentioned, if you use zstyle after co= mpinit it should
> definitely be safe.

Sure, but compinit actu= ally checks the completer style to decide whether to rebind ^I to complete-= word or leave it at expand-or-complete. So, then at least that style needs = to come before compinit and then we have to zmodload zstyle before compinit= anyway. Should then perhaps that piece of code in compinit be changed, so = all zstyle calls can occur after compinit?


> > _extensions= feels rather useless when you can get the same effect
> > through= matchers, but without requiring the leading *.
>
> With a matc= her, you'll only complete one of them unless you have
> _all_matc= hes. _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.

If I want multiple = files with an extension, then _expand handles *.foo just fine. I still don&= #39;t see the point of _extensions. :)


> > > > # r:|= ?=3D** does fbr -> foo-bar and bar -> foo-bar
> > > > = zstyle ':completion:*:complete:*' matcher-list \
> > > = > =C2=A0 'r:|[.]=3D** r:?|[-_]=3D** l:?|=3D[-_] m:{[:lower:]-}=3D{[:= upper:]_}' \
> > > > =C2=A0 'r:|?=3D** m:{[:lower:]}= =3D{[:upper:]}'
> > >
> > > I'd be signific= antly more conservative on these. They really can cause
> > > s= urprises for new users and break some things completely like trying to forc= e
> > > the type of listed matches with punctuation prefixes.> >
> > I've used something like this for quite a whil= e now. I'm unsure what
> > kind of breakage you are referring = to.
>
> What I was alluding to there is that there are times wh= en I'll type an
> initial prefix to limit the sort of matches I g= et. So with this,
> completion after the following does not give me o= nly completion functions:
> =C2=A0 which _<tab>
> Any com= mand with an underscore gets matched while completion functions
> rem= ain ignored.
>
> Otherwise it is sometimes quite aggressive and= transforms what you've typed
> considerably. I've known peop= le to complain about _approximate for that.
> I'm personally not = keen on the ** forms with r:

But r:|?=3D** is part only of the secon= d matcher. When you type _<tab>, it will get matched already by the f= irst matcher in matcher-list.


> > > I mostly use genero= us matchers with more specific contexts.
> > > To give one exam= ple, 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:%|=3D*'= ;
> >
> > I'm hesitant to do this kind of tweaking. I= 'd rather apply the Pareto
> > principle and have a generic so= lution that's good enough for most
> > cases. If there's a= nything 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 j= ust
> using it as an example. Certainly I would also be hesitant to i= nclude
> it and dozens like it. (Though your following one for option= s is along
> similar lines.)

I feel like options are common e= nough to warrant an exception, especially because they won't get shown = until you type a dash. Without the additional matcher below, you might neve= r realize that `set` and `functions` (for example) also have + options, bec= ause they will not get listed.


> > > > # For options= only, add - -> + for each item in the list above.
> > > >= ; zstyle ':completion:*:options' matcher 'm:{-}=3D{+}'
&= gt; > >
> > > Isn't the more limited 'b:-=3D+'= ; 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 whi= ch I assume is the intent. The m: form matches
> any - to any +, b: o= nly at the beginning. Removing the curly brackets has
> no effect on = the behaviour, they're superfluous when you only have one
> chara= cter.

Thanks, I didn't know that. That wasn't clear to me fr= om the way it's described in the documentation:

http://zsh.sourceforge.net/Doc/Release/Completion-Widgets.html#= Completion-Matching-Control
> The b and B forms are similar to l = and L with an empty anchor, but need to match only the beginning of the wor= d on the command line or trial completion, respectively.

--0000000000005c294e05bb353225--