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 <dana@xxxxxxx> 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 <schaefer@xxxxxxxxxxxxxxxx> 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 <schaefer@xxxxxxxxxxxxxxxx> 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 <schaefer@xxxxxxxxxxxxxxxx> 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 <opk@xxxxxxx> 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 _<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:
But r:|?=** is part only of the second matcher. When you type _<tab>, 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 -<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.
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.