Re: Rewrite of zsh-newuser-install

[Marlon Richert <marlon.richert@xxxxxxxxx>]

On Sun, Feb 7, 2021 at 3:51 PM Roman Perepelitsa
<roman.perepelitsa@xxxxxxxxx> wrote:
> Previous discussion:
> https://www.zsh.org/mla/workers/2020/msg00043.html and follow-ups.

Thanks, I took the time to read through all of it (and then some
more). Let me respond here to most of it.

I agree with almost all that Roman said there, with some exceptions or
additions as noted:

> I think zshrc recommended by zsh should be very conservative. It should enable users to get started (basic keys must work, prompt must show current directory, completions must work -- this sort of stuff) *and* it must enable average users to take control over their configuration. The danger of too complex starter zshrc is that users won't be able to understand it, and will have worse setup long term because of this.
> To be more specific:
> - no vcs_info. in some environments it makes prompt noticeably slow; it also adds a lot of complexity

Not only that, but I find it less work to figure out how to get the
info I need from Git directly, than to understand how to configure
vcs_info to do it. Not only that, vcs_info from the "too generic tool"
problem: By trying to cater to all VCS systems, it caters to none of
them well.

> - the config itself must not have any configuration options of its own, be it zstyle or parameters; it's a config, not a meta config; users should be encouraged to edit it rather than create another config with parameters for this config and source one from another
> - no prompt_subst or precmd hooks

I disagree with that particular point. Making use of promptsubst and
precmd (or other) hooks is fine by me, as long as we don't go
overboard with it. There is nothing inherently complex about that.

> - no prompt shortening; display directory as %~
> - no syntax highlighting, autosuggestions or any other external plugins; autoloading functions bundled with zsh is OK

While I agree that we shouldn't include external plugins here, I don't
think all Zsh-bundled functions are OK to autoload. While there are
some really good ones, many of them feel like abandonware. In that
respect, I think many of them would be better off being removed from
the Zsh repo and maintained in separate repos as plugins instead.

> - single file (zshrc)
>
> The file should explain through comments what things mean ("%~ is current directory", etc) and should suggest where users should add their aliases and exported variables. Comments should also suggest where more information can be found ("for more information about prompting, see xxx"). Links to web pages here work better than `man` commands, although putting both of them will also work.
> What about the goodies though? Leave that to the market. Anyone can come up with a config template, or even an interactive dialog that creates a config based on your preferences. Let them compete. zsh should be *usable* upon installation but not bloated or opinionated.
> [...]
> - Inline the prompt definition instead of using promptinit. This makes it much easier for users to customize prompt. Abstractions are a serious barrier for beginners.

prompinit is one of those autoloadable functions that in theory feel
like a very good idea, but feels like abandonware in practice. I would
love for it to get the same amount of care as compinit does, but as it
stands, it really doesn't do much at all.


> - Move keybindings (everything, really) from the global zshrc to the user and remove fancy indirection from there as well (don't use terminfo and don't define auxiliary assoc arrays). This will show users how to define bindings. Also get rid of zle-line-begin/end hooks and stop changing terminal mode. Do something like this instead: https://www.reddit.com/r/zsh/comments/eblqvq/d/fb7337q/. This is easier to understand and more robust.

The problem I have with Roman's approach to key bindings is that there
is no central source for rmkx escape codes. You end up hard-coding a
whole lot that might be specific to just the terminals you happen to
use. I don't like that approach. (Not that terminfo is perfect either,
but at least it saves you from reinventing the wheel.)

But the point is kind of moot if Dana's suggestion could just get
implemented, which I think would be preferable:

> Actually, if key bindings don't always work well out of the box, and especially if we can fix that by simply checking terminfo, shouldn't we do that with the default bindings in the shell itself?


Continuing with Roman's comments:

> - More comments explaining what things do and where to find docs. E.g., comments above bindings should say which key is being bound and what the widget does. It should also explain how to figure out escape codes for different keys and where to find the list of builtin widgets.
> - Maybe fewer completion styles. Seems like too much but maybe they are really important, I don't know.

Again, as long as they are low complexity, I don't see a problem
there. I agree with Dana:

> Obviously we shouldn't go crazy with it, but i don't see any reason to specifically limit the use of styles. The style system is an important aspect of configuring zsh. There are very useful settings that can only be changed that way, and it's important for users to know about it if they want to make their own changes.

I like how the zstyle system has namespacing built in and how it makes
the env less polluted with random vars. We should definitely encourage
zstyle to be used more, not less.


Anyway, to finish it off:

> One meta observation based on my experience doing the same with powerlevel10k. 90%+ of users won't ever open the default config file. 90% of those that do, won't read any documentation that isn't included in the file itself.

I have browsed P10k's default config file and it is insanely complex.
Though I agree that most users don't read and we should thus keep the
amount of explanatory text to a minimum, I don't think you can view
your use case as being representative.


Finally, regarding Daniel's pet favorite:

> - a certain syntax highlighting plugin :P

I think it would be great if Zsh would have syntax highlighting out of
the box. It feels silly to have documentation for region_highlight,
but then ship no simple way of using it. However, if syntax
highlighting is going to be included by default, then it should be
maintained in the Zsh repo and not as an external plugin.


Anyway, sorry for the long post. I hope I have at least given you a
good overview of my thoughts and intentions.

Now, if I want to work on this, where should I start? Should I fork
https://gitlab.com/zsh-sensible/zsh-sensible ?