Hi After a brief discussion on IRC, I thought about advantages of an official p-m being available. Maybe it's the right time to glance over them? 1. The example, bootstrapping zshrcs shared on the net would be resulting in feature-complete setups, with e.g.: a feature-rich nice prompt, syntax-highlighting of the command line and e.g.: of the history, etc. 2. This could be actually addressing the issue that zsh-newuser-install aims at solving: to easily bootstrap a new zsh user's setup. 3. It would offload the situation that "you cannot use Zsh without Oh My Zsh" or "... without a plugin manager". Today many Zsh users feel that they "couldn't make it" without Oh My Zsh because Zsh is a complex system that needs a ground of sane settings. With the official p-m, the situation would not have been of "laying a ground of sane settings", but of "loading a well-written prompt", for example, and it's a different-quality situation. 4. The new users wouldn't have to go through the somewhat stressful stage of selecting a framework. The stress comes from having a choice, as there are many p-ms available (antibody, antigen, zgen, zplug, zplugin to name a few). The users could wait with the need of switching to a custom p-m for the moment when they will feel that they're ready to (if they do). 5. Coding such p-m will be a very good time for the people involved (which I hope would involve Peter, Bart, Oliver, Daniel, Mikael, Roman and others). 6. It would allow establishing a way of distributing Zsh scripts in a different way than the autoload functions – by a kind of a package of files in a subdirectory, The method would have been a step forward and it would allow contributing such objects to Zsh as currently, it requires tricks like in the prompt function, which rather closes the way for such new contributions, as they are not fully nice (the prompt function is, however, a nice engineering, but that's a special case). What do you think? Could the official plugin manager project be starting for 5.9? To then gain a full feature set before 6.0? (I'm making a slight point here that the p-m would be a good front-end reason for releasing the next major version). -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On 1/1/20 10:17 PM, Sebastian Gniazdowski wrote:
> Maybe it's the right time to glance over
> them?
nah
Sebastian Gniazdowski wrote on Thu, 02 Jan 2020 03:17 +00:00: > After a brief discussion on IRC, I thought about advantages of an > official p-m being available. http://xyproblem.info/ "Write an official plugin manager" is a solution. You have identified several problems in your mail, so let's talk about those problems and consider all possible solutions to them (not only the one that you hardcoded into the subject line of this thread).
On Thu, 2 Jan 2020 at 12:04, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > http://xyproblem.info/ > > "Write an official plugin manager" is a solution. You have identified > several problems in your mail, so let's talk about those problems and > consider all possible solutions to them (not only the one that you > hardcoded into the subject line of this thread). Okay. I think that the one interesting point was the 3rd one. I think that it harms Zshell's picture out there by making the following thinking common: that you cannot use Zsh without loading a bloated framework like Oh My Zsh. By providing a compact p-m out of the box this would have been pretty much or fully solved: the user could load a decent theme which would also do a few needed setopts, load a syntax highlighting plugin directly without the framework or load just the bits of the framework that he chooses to (this one more as a transition feature than an important one). This way the user would learn that he doesn't need to put large portions of initialization scripts into Zsh, but instead load the desired solutions with out of the box Zsh features. I think that this could lead to a significant decline in OMZ popularity because blog authors could share decent zshrcs which would also include the other needed setopts and zstyles, etc. Right now what they are limited to is "install Oh My Zsh and add X to the plugins=( ... ) array". I honestly cannot come up with a different solution to this problem than the official, compact plugin manager. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On Thu, 2 Jan 2020 at 12:37, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > On Thu, 2 Jan 2020 at 12:04, Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > http://xyproblem.info/ > > > > "Write an official plugin manager" is a solution. You have identified > > several problems in your mail, so let's talk about those problems and > > consider all possible solutions to them (not only the one that you > > hardcoded into the subject line of this thread). > > Okay. I think that the one interesting point was the 3rd one. I think > that it harms Zshell's picture out there by making the following > thinking common: that you cannot use Zsh without loading a bloated > framework like Oh My Zsh. I've decided to slightly elaborate on this without jumping to the Y, i.e.: to the bundled p-m. I think that OMZ has a guilt of spreading of such thinking (that you cannot use Zsh without a framework that's bloated – actually but also by the impression that is given by what's advertised: "(framework) with nearly 1,500 contributors", "includes 200+ optional plugins", etc.). It gives the impression that "if you load OMZ, then all Zsh complex configuration will be done for you" (by the code from the *1500* contributors...), which implies that the configuration is so complex that you cannot get a better outcome on your own, especially if you're a new user. This basically means that Zsh has to be put down under the layer of OMZ and best if untouched directly, but instead relying on "an auto-update tool so that makes it easy to keep up with the latest updates from the community". Hence the thinking-pattern problem. To address this public-image pressure from OMZ: - something has to be added to Zsh, - a simple uncover of it: it should allow easier configuration, - configuration often means: loading a theme and the needed functionality providers (i.e.: plugins), thus this converges to the bundled p-m solution. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On Thu, Jan 2, 2020 at 12:04 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> [...] let's talk about problems
I've switched to Zsh in early 2019. I don't claim to be a typical user
but perhaps my recollection of the transition will illuminate some of
the difficulties new users face.
The only shell I'd used prior to switching to Zsh was Bash. My rc
files were based on the stock configs supplied by the distro. Over the
years I'd added a few `export`, `alias` and `bind` statements, but
other than that I hadn't changed anything. When upgrading my distro I
would transfer over my rc changes to the new stock files.
When I decided to try zsh, my distro of choice was Ubuntu. The
installation of zsh was as easy as I could ask for -- just `sudo apt
install zsh`. When I typed `zsh`, I was greeted by the new user
dialog. This was a pleasant surprise turned sour. I tried going
through all options to see the whole configuration space but gave up
after a few minutes as I was unable to understand the implications of
my answers. I quit the dialog without writing ~/.zshrc. My idea was to
see what the experience is like without a custom config. It was
intimidating. Prompt was missing the information I was used to (the
default Bash prompt in Ubuntu shows user@host and the current
directory in different colors). Basic keys such as home, end or delete
didn't work. I fired zsh again to try the new user dialog once more
and chose the "recommended" option. This hasn't fixed neither prompt
nor key bindings. I deleted ~/.zshrc and gave the new user dialog one
last try. This time I went through every single option to see if it'll
ask me about prompt and key bindings anywhere. No such luck. At this
point I googled "zsh basic config" or something like that. All top
results said to install Oh My Zsh, so I did. This gave me prompt
closer to what I wanted and my keys worked.
I should note that Bash without user rc files is also underwhelming.
While the basic keys still work, prompt is `bash-4.4$`. What makes the
out-of-the-box Bash experience decent on Ubuntu is /etc/skel/.bashrc,
which becomes ~/.bashrc for new users.
Roman.
On Thu, 2 Jan 2020 at 13:01, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > > On Thu, Jan 2, 2020 at 12:04 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > [...] let's talk about problems > > (...) > > Prompt was missing the information I was used to (the > default Bash prompt in Ubuntu shows user@host and the current > directory in different colors). I think that the prompt problem would be solved by the p-m. A simple: "zsh-pm load user/theme" added to the .zshrc would give a theme that's either decent relatively - i.e.: when compared to the default % prompt - or absolutely - in case of the user/plugin being a good theme. > Basic keys such as home, end or delete didn't work. The point 6.: the new way of packaging scripts, not through autoload functions but by sourceables - would allow bundling a few reasonable bindkey setups. I suspect that the unclean impression given by doing this by the autoloads – given because it doesn't feel right to create a set of functions with just a set of bindkey calls in them – could be one of the main reasons of why this isn't currently bundled. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On Thu, Jan 2, 2020 at 1:21 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> I think that the prompt problem would be solved by the p-m.
Perhaps.
Do note that my baseline expectations when switching to Zsh were based
on the out-of-the-box experience with Bash. There is no built-in
plugin manager or auto-loadable functions in Bash.
Roman.
On 2 Jan 2020, at 05:37, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> Okay. I think that the one interesting point was the 3rd one. I think
> that it harms Zshell's picture out there by making the following
> thinking common: that you cannot use Zsh without loading a bloated
> framework like Oh My Zsh.
I agree that zsh provides an underwhelming out-of-box experience for novice
users and that they are funnelled into OMZ in an attempt to address that. It'd
be nice if that wasn't the case. I'm not necessarily opposed to an official
plug-in manager, but i'm not sure it follows that creating one would solve
this specific problem.
Lots of zsh plug-in managers already exist. Any one of them can be used by
blog authors to 'share decent zshrcs which would also include the other needed
setopts and zstyles, etc.' *right now*. The existence of OMZ does not prevent
this. OMZ itself can be used to manage settings like that. The only thing that
would be different about a first-party plug-in manager is that you wouldn't
have to install it first. Beyond that, for *managing plug-ins*, it makes very
little difference.
Novice users don't use OMZ because they want to manage plug-ins. They use it
because they want a command they can just run to get the fancy completion and
prompts they see in screen-shots on dev.to or whatever, and OMZ fulfills that
desire by unconditionally modifying the shell's configuration to enable
whatever its developers consider desirable functionality. I assume that's what
you meant when you said that OMZ is 'bloated'. It *is* bloated, but that's
exactly the selling point. Were we to provide a first-party plug-in manager,
in the absence of other changes, it would simply be used to install OMZ, or
something like it.
When i first started using zsh, i had the same experience with the new-user
wizard that Roman did, and it's my impression that that's not uncommon. It's a
good idea in theory, but I think the success of projects like OMZ and fish
shows that most users now don't really want the degree of control that it
provides. They just want the cool stuff. If that's true, i feel like having
the wizard simply offer to turn on that (pre-determined) cool stuff would be
an easier and more effective way to cut into the OMZ use case than a plug-in
manager.
dana
On Thu, 2 Jan 2020 at 22:28, dana <dana@dana.is> wrote: > I agree that zsh provides an underwhelming out-of-box experience for novice > users and that they are funnelled into OMZ in an attempt to address that. It'd > be nice if that wasn't the case. I'm not necessarily opposed to an official > plug-in manager, but i'm not sure it follows that creating one would solve > this specific problem. I cannot recall my first contact with Zsh as it was ~14 years ago, however, when reconstructing I would say that I was pretty much impressed by the hash table availability, about which I've read in some pros and cons, Bash vs. Zsh article. I've couldn't believe how can you have an "official Linux shell" (i.e.: Bash) without them. Then I recall reading the description of *each* option and turning it on/off in .zshrc. I'm still using the options, like octal_zeros, for example, c_bases, numeric_glob_sort, complete_in_word, no_glob_complete, and others. Noticing: the last one isn't active now when I'm using menu select. Then I've probably searched the net looking for how to make the keys like home, end work, found out the $terminfo trick to notice that it's not working for all keys and then hardcoding cat -v sequences. So my experience was maybe a bit different, I was ready to get the best shell imagined (because of the hash tables) by going close to the detailed configuration from the start. But maybe others were like this too and they are just recalling the literally first contact with Zsh. > Lots of zsh plug-in managers already exist. Any one of them can be used by > blog authors to 'share decent zshrcs which would also include the other needed > setopts and zstyles, etc.' *right now*. I think that this hits a wall of having a choice. "Hey, I just want a *reasonable* p-m to get all the plugins, as that's what actually matters, isn't it? Why do I have to decide on the p-m, if I'm going to do this properly then I'll at least enter 'best zsh plugin manager' in Google, and this means work, work, lost time and large impatience intake. And then the slight discomfort of not diving into the topic enough deep and deciding on a p-m mostly by its cool name - hey, am I really using the p-m that I should?" > The only thing that > would be different about a first-party plug-in manager is that you wouldn't > have to install it first. Yes and I think that this is a significant factor in the first-contact experience. > Novice users don't use OMZ because they want to manage plug-ins. They use it > because they want a command they can just run to get the fancy completion and > prompts they see in screen-shots (...) > Were we to provide a first-party plug-in manager, > in the absence of other changes, it would simply be used to install OMZ, or > something like it. Ok, I can agree with this, although having a theme loaded by a single line in zshrc does contribute very much to fulfilling the expectations of new users that you've mentioned. As for the completion and other things, like properly working home/end keys, the p-m could address this by point 6. in the original post – by allowing sourcables, not only autoloads. For example, Roman shares a decent bindkey setup: https://www.reddit.com/r/zsh/comments/eblqvq/d/fb7337q/ Why not store this snippet into a plugin called 'bindkeys', which would have been a subdirectory in /usr/share/zsh/<VER>/plugins/bindkeys, in a file "translate.zsh" to highlight the bindkey-s-translation property of the setup, to then allow users loading it with: zsh-pm pick=translate.zsh @bindkeys ? > (...) that most users now don't really want the degree of control (...) > They just want the cool stuff. If that's true, i feel like having > the wizard simply offer to turn on that (pre-determined) cool stuff would be > an easier and more effective way to cut into the OMZ use case than a plug-in > manager. OK, however, the sourcables-backend to zsh-newuser-install is IMO needed first. Then the install function could offer to append: zsh-pm pick=nodups.zsh param='size -> 10000' @history to the zshrc. PS. The zsh-pm is just a conservative quasi-idea of the possible name of the function of the p-m. PS2. To illustrate the benefits of sourcables I'm gonna again use Roman's snippet, as it serves well for the possible bundled-plugin example: https://www.reddit.com/r/zsh/comments/dkjp27/bindkey_quest/f4glg6n zsh-pm @meta-cd OR zsh-pm param='back -> ^B; forward -> ^F' @meta-cd Basically, such a plugin would be one other way to spice-up the first contact with Zsh, and it shows the benefits of sourcables-approach. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On 2 Jan 2020, at 18:25, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > I think that this hits a wall of having a choice. "Hey, I just want a > *reasonable* p-m to get all the plugins, as that's what actually > matters, isn't it? Why do I have to decide on the p-m, if I'm going to > do this properly then I'll at least enter 'best zsh plugin manager' in > Google, and this means work, work, lost time and large impatience > intake. And then the slight discomfort of not diving into the topic > enough deep and deciding on a p-m mostly by its cool name - hey, am I > really using the p-m that I should?" Is the problem you're trying to solve 'people don't know which plug-in manager to use' or 'people don't know how to configure zsh so they just install OMZ'? The one you're describing here is the former. Once they *have* a plug-in manager, they can install whatever they want, and they seem to want OMZ. (It's even the first example in the Antigen documentation...) On 2 Jan 2020, at 18:25, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > OK, however, the sourcables-backend to zsh-newuser-install is IMO > needed first. Then the install function could offer to append: > > zsh-pm pick=nodups.zsh param='size -> 10000' @history > > to the zshrc. You've responded to me saying 'instead of providing fine control over the profile set-up it could simply give them some good defaults' with 'OK, but first we need to add more complexity in order to provide finer control over the profile set-up' Also, your example command is about 20 characters longer, and significantly harder to read or to transfer into a broader understanding of how the shell configuration works, than just setting it the normal way. How would this address the difficulty me and Roman described re: not understanding the implications of the wizard? dana
On Fri, 3 Jan 2020 at 02:34, dana <dana@dana.is> wrote: > > Is the problem you're trying to solve 'people don't know which plug-in manager > to use' or 'people don't know how to configure zsh so they just install OMZ'? > The one you're describing here is the former. To be able to configure Zsh people need a p-m (to be able to use the sourcables like @bindkeys, @history, etc. – that would be doing the actual configuration). So it's not A vs. B, but A -> B, where A is "people need a p-m / sourcables" and B is "people are able to configure Zsh". > Once they *have* a plug-in > manager, they can install whatever they want, and they seem to want OMZ. (It's > even the first example in the Antigen documentation...) Well OK, however, there is the obstacle of having a choice. I think that this is also promoting OMZ: "so many frameworks / p-m out there and it's so difficult to choose? well, I better stick to 1500 contributors-backed Oh My Zsh". > On 2 Jan 2020, at 18:25, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > OK, however, the sourcables-backend to zsh-newuser-install is IMO > > needed first. Then the install function could offer to append: > > > > zsh-pm pick=nodups.zsh param='size -> 10000' @history > > > > to the zshrc. > > You've responded to me saying 'instead of providing fine control over the > profile set-up it could simply give them some good defaults' with 'OK, but > first we need to add more complexity in order to provide finer control over > the profile set-up' Well yes, because I suspect that there will be a rough time on establishing what the defaults are supposed to be. And also, the sourcables are a new method of providing the snippets with the defaults. With them, there could have been a few variants of each plugin like @bindkeys, which would ease the problem of establishing the defaults. > Also, your example command is about 20 characters longer, and significantly > harder to read or to transfer into a broader understanding of how the shell > configuration works, than just setting it the normal way. How would this > address the difficulty me and Roman described re: not understanding the > implications of the wizard? I thought about the @history / nodups.zsh to be something like: HISTFILE=${file:-~/.zhistory} HISTFILE=${~HISTFILE} HISTSIZE=${size:-10000} SAVEHIST=$HISTSIZE setopt hist_ignore_dups setopt inc_append_history hist_fcntl_lock # Default-off options setopt ${all+histi_gnore_all_dups} ${find+hist_find_no_dups} setopt ${space+hist_ignore_space} ${copy+hist_save_by_copy} setopt ${verify+hist_verify} ${clobber+hist_allow_clobber} # Default-on options setopt ${nolex-hist_lex_words} ${noblanks-histreduceblanks} These are not all history options considered. So the loading of the sourceable would have been: zsh-pm pick=nodups.zsh @history zsh-pm pick=nodups.zsh param'size -> 2000; file -> ~/.zhist' @history zsh-pm pick=nodups.zsh param'copy; all; nolex' @history And this would allow elastic providing of defaults with an additional layer – the sourceable file. Normally the file contents would have to be hardcoded into the newuser install script (plus the not exactly solvable problem of the option modifiers). Here, only a few keywords will have to be remembered in the installer and then the sourceable could be freely edited. The example sourceable script shows also how difficult will it be to come up with the non-elastic default settings for history. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On Thu, Jan 2, 2020 at 5:34 PM dana <dana@dana.is> wrote:
>
> You've responded to me saying 'instead of providing fine control over the
> profile set-up it could simply give them some good defaults' with 'OK, but
> first we need to add more complexity in order to provide finer control over
> the profile set-up'
It has been our long-standing practice to recommend that package
builders/installers do NOT create /etc/z* files, or make them minimal,
so as not to interfere with users own initialization files. Maybe
it's time to relax that, or at least to provide a suggested skeleton
.zshrc -- which we could connect to zsh-newuser-install to be slurped
in without having to go through all the questions if you just want to
"feel lucky".
I've been noodling with a default completion setup module for a while
(though haven't worked on it in months) and we could certainly do a
better job of exposing the prompt theme system since pretty prompts
apparently are what many people go looking at OMZ to find.
On 2 Jan 2020, at 20:43, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > Well yes, because I suspect that there will be a rough time on > establishing what the defaults are supposed to be. Right, from what i've heard, that has been an issue in the past. But it needs to be done to address this. OMZ did it. I really do think that novice users don't understand the significance of the choices you seem to be proposing (obv), and they don't want to spend 45 minutes tapping through a wizard to have it explained to them, either. When they run zsh for the first time, they just want to see what it can *do* — they can change their history-file path later, if they want. On 2 Jan 2020, at 20:45, Bart Schaefer <schaefer@brasslantern.com> wrote: > It has been our long-standing practice to recommend that package > builders/installers do NOT create /etc/z* files, or make them minimal, > so as not to interfere with users own initialization files. Maybe > it's time to relax that, or at least to provide a suggested skeleton > .zshrc -- which we could connect to zsh-newuser-install to be slurped > in without having to go through all the questions if you just want to > "feel lucky". The latter is what i'm suggesting, yeah. Dumb down the wizard a bit, add a flashy option to the first screen that says 'do the cool things (recommended)' or whatever, and have it install a well-commented .zshrc with the settings that that a novice/casual user would look for. On 2 Jan 2020, at 20:45, Bart Schaefer <schaefer@brasslantern.com> wrote: > I've been noodling with a default completion setup module for a while > (though haven't worked on it in months) and we could certainly do a > better job of exposing the prompt theme system since pretty prompts > apparently are what many people go looking at OMZ to find. I think that would help dana
On Fri, 3 Jan 2020 at 04:24, dana <dana@dana.is> wrote: > > On 2 Jan 2020, at 20:43, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > Well yes, because I suspect that there will be a rough time on > > establishing what the defaults are supposed to be. > > Right, from what i've heard, that has been an issue in the past. But it needs > to be done to address this. OMZ did it. > > I really do think that novice users don't understand the significance of the > choices you seem to be proposing (obv), and they don't want to spend 45 > minutes tapping through a wizard to have it explained to them, either. When > they run zsh for the first time, they just want to see what it can *do* — they > can change their history-file path later, if they want. I've now thought that this might be reminiscent of the difference between package-based Linux distros and Gentoo. When I've switched recently to the second I've noticed how much freedom there is in how the programs are installed and I've had some moments of being puzzled "how do the RPM-based distros actually manage to provide a working software?" or "how did I live without those options?" The answer is, I suppose: - the options (in configure, CMake, etc.) are always aimed at providing all the available features, - in case of a conflict situation (like e.g.: libressl vs libopenssl) a tear-down (of the conflict) decision is being made that e.g.: favors the more popular library and closes the problem and moves on. So the history setup that would follow this guidance could be: HISTFILE=$HOME/.zhistory HISTSIZE=40000 SAVEHIST=$HISTSIZE setopt hist_ignore_dups setopt inc_append_history hist_fcntl_lock setopt hist_ignore_space setopt hist_lex_words That said the param='...' way could be still useful for e.g.: share_history as it's a different kind of setup, not a feature to include. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
Bart wrote: > It has been our long-standing practice to recommend that package > builders/installers do NOT create /etc/z* files, or make them minimal, > so as not to interfere with users own initialization files. Maybe > it's time to relax that, or at least to provide a suggested skeleton A packaged system-wide zshrc is not the same thing as a skeleton zshrc. The recommendation should stand for the former. A skeleton zshrc, meaning a file that is copied from, e.g. /etc/skel/.zshrc to a new user's home directory by useradd is not something I'd discourage. > zshrc -- which we could connect to zsh-newuser-install to be slurped > in without having to go through all the questions if you just want to > "feel lucky". I've never been especially fond of the newuser feature but that's mainly because of the periodic irritation of having to read how to quit it when using a blank account. If it discourages distributions from including skeleton files, then that isn't great. Perhaps it could just print a helpful message, autoload functions for invoking things like setup widgets and prompt theme selectors, do some minimal setup like enabling completion and then give you an actual prompt. For a setup widget, using zcurses and colour for something more visual and interactive might be more approachable. But I wouldn't want that invoked automatically. > I've been noodling with a default completion setup module for a while > (though haven't worked on it in months) and we could certainly do a > better job of exposing the prompt theme system since pretty prompts > apparently are what many people go looking at OMZ to find. We might also want to reconsider the actual themes. They all predate vcs_info and unicode. Meddling with PROMPT_CR and PROMPT_SP seems unhelpful while the state of TRANSIENT_RPROMPT is sooner an aspect of the actual prompt. The prompts do some nice things that are not obvious to a casual observer, e.g. getting signal names from the return status (clint/zefram) and the conditional newline (oliver). What's popular in the OMZ world is whatever looks cool even if you have to install modified fonts to make them work. As for an official plugin manager, I think the idea has merits. I brought the idea up in users/22179 but there was little enthusiasm then. And I had different problems in mind than those outlined by Sebastian: for all its popularity and multitudes of "contributors", OMZ has a quality problem. Contributions are largely forgotten once accepted because ownership is transferred. They don't make good use of autoloading, possibly run compinit more than once with changed $fpath and don't seem to encourage the use of things like add-zsh-hook. The plugin standard and documentation of it determines those things. Oliver
On Thu, 2020-01-02 at 21:26 -0600, dana wrote:
> On 2 Jan 2020, at 20:45, Bart Schaefer <schaefer@brasslantern.com> wrote:
> >
> > It has been our long-standing practice to recommend that package
> > builders/installers do NOT create /etc/z* files, or make them minimal,
> > so as not to interfere with users own initialization files. Maybe
> > it's time to relax that, or at least to provide a suggested skeleton
> > .zshrc -- which we could connect to zsh-newuser-install to be slurped
> > in without having to go through all the questions if you just want to
> > "feel lucky".
> The latter is what i'm suggesting, yeah. Dumb down the wizard a bit, add a
> flashy option to the first screen that says 'do the cool things (recommended)'
> or whatever, and have it install a well-commented .zshrc with the settings
> that that a novice/casual user would look for.
I tend to agree with the thrust of this --- feedback over the years has
been quite strongly people don't want to do anything clever; the difficulty
remaining is what sort of basic set up to copy in instead. But yes,
whatever that is it should probably be something prepared elsewhere and
copying in that should probably be the highlighted / default option.
pws
Peter Stephenson wrote on Fri, Jan 03, 2020 at 15:00:09 +0000:
> On Thu, 2020-01-02 at 21:26 -0600, dana wrote:
> > On 2 Jan 2020, at 20:45, Bart Schaefer <schaefer@brasslantern.com> wrote:
> > >
> > > It has been our long-standing practice to recommend that package
> > > builders/installers do NOT create /etc/z* files, or make them minimal,
> > > so as not to interfere with users own initialization files. Maybe
> > > it's time to relax that, or at least to provide a suggested skeleton
> > > .zshrc -- which we could connect to zsh-newuser-install to be slurped
> > > in without having to go through all the questions if you just want to
> > > "feel lucky".
> > The latter is what i'm suggesting, yeah. Dumb down the wizard a bit, add a
> > flashy option to the first screen that says 'do the cool things (recommended)'
> > or whatever, and have it install a well-commented .zshrc with the settings
> > that that a novice/casual user would look for.
>
> I tend to agree with the thrust of this --- feedback over the years has
> been quite strongly people don't want to do anything clever; the difficulty
> remaining is what sort of basic set up to copy in instead. But yes,
> whatever that is it should probably be something prepared elsewhere and
> copying in that should probably be the highlighted / default option.
I agree: my take-away from the discussion is that there's room for a "sensible
defaults" thingy (be it a zshrc template or a plugin). Shall we create
a github/gitlab repo to work on that in?
Cheers,
Daniel
P.S. Some ideas for what to have there:
- compinit
- PS1
(what to include? %m, %~, $SHLVL, %?, $(tty)? Probably have zstyle's or something to enable/disable parts of that.)
- vcs_info
[Some additional vcs_info settings? E.g., during rebases I show the topmost
applied-patch (= the one that conflicted); I think that's not the default…]
- a certain syntax highlighting plugin :P
On Fri, Jan 3, 2020 at 10:06 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> P.S. Some ideas for what to have there:
>
> - PS1
This is just my personal opinion that I don't hold very strongly and
my voice obviously carries little weight here. 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
- 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
- no prompt shortening; display directory as %~
- no syntax highlighting, autosuggestions or any other external
plugins; autoloading functions bundled with zsh is OK
- 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.
Just my 2 cents. You may notice that my opinions here can be summed up
as "do what Bash does" without much loss of fidelity.
Roman.
Roman Perepelitsa wrote on Fri, 03 Jan 2020 21:51 +00:00: > This is just my personal opinion that I don't hold very strongly and > my voice obviously carries little weight here. I think zshrc > recommended by zsh should be very conservative. It should enable users > to get started (basic keys must work, Debian does something like this: https://salsa.debian.org/debian/zsh/blob/debian/debian/newuser.zshrc.recommended https://salsa.debian.org/debian/zsh/blob/debian/debian/zshrc
On Fri, Jan 3, 2020 at 2:07 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> Roman Perepelitsa wrote on Fri, 03 Jan 2020 21:51 +00:00:
> > This is just my personal opinion that I don't hold very strongly and
> > my voice obviously carries little weight here. I think zshrc
> > recommended by zsh should be very conservative.
My approach with the completion defaults I've been playing with, is to
define a function that installs a zstyle only if there is not already
another competing zstyle, so that the default definitions may safely
be "source"d at any point. However, these could easily be defined
directly instead. Descriptions of some of the styles then defined via
that function:
# Insert all expansions for expand completer
# Allow one error for every three characters typed for _approximate
# Allow two errors elsewhere, e.g. for _correct
# Offer indexes before parameters in subscripts
# Ignore completion functions (until the _ignored completer)
# Matching:
# 1. Try completion with no alterations (i.e., literal match is best)
# 2. Match substrings separated by dashes, dots, underscores, commas
# 3. As (2) but case-insensitively
# 4. As (2) but allow arbitrary stuff at the beginning of the result
On Fri, Jan 3, 2020 at 11:07 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Roman Perepelitsa wrote on Fri, 03 Jan 2020 21:51 +00:00: > > This is just my personal opinion that I don't hold very strongly and > > my voice obviously carries little weight here. I think zshrc > > recommended by zsh should be very conservative. It should enable users > > to get started (basic keys must work, > > Debian does something like this: > > https://salsa.debian.org/debian/zsh/blob/debian/debian/newuser.zshrc.recommended > https://salsa.debian.org/debian/zsh/blob/debian/debian/zshrc This looks along the lines of what I was suggesting and what would make my life easier when I was switching to zsh. I'd suggest a few minor changes. - 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. - 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. - 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. 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. Roman.
On 3 Jan 2020, at 16:37, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > - Move keybindings (everything, really) from the global zshrc to the > user and remove fancy indirection from there as well 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? In either case, *not* using terminfo seems like it will limit what we can actually do, since we risk breaking some terminals otherwise. That's presumably why the Debian configuration uses it in the first place. On 3 Jan 2020, at 16:37, Roman Perepelitsa <roman.perepelitsa@gmail.com> wrote: > - Maybe fewer completion styles. Seems like too much but maybe they > are really important, I don't know. 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 agree that everything should be thoroughly commented, and designed to impart as much general/transferable knowledge as possible to the user. They won't learn from it easily if the file contains too much magic. dana
I've gone ahead and created https://gitlab.com/zsh-sensible/zsh-sensible. Feel free to add content (or remove anything that's too advanced). As pws said, we can bring stuff back from there to the main distribution as it matures/stabilizes.
On Fri, 3 Jan 2020 at 12:15, Oliver Kiddle <okiddle@yahoo.co.uk> wrote: > > As for an official plugin manager, I think the idea has merits. I > brought the idea up in users/22179 but there was little enthusiasm > then. Back then (it was 2016) the number of available plugins wasn't that of today – now there are 492 plugins compared to 125 plugins in that year (the # of themes went from 86 to 498) – according to the awesome-zsh-plugins listing. And the quality of the plugins was very low, I know that well because I've examined ~50 plugins from the list to know for sure that the reporting in Zplugin will work. I cannot tell how it's today with the quality, however, in general, it did improve at least in the sense of having quite a few well-written ones, like e.g.: themes (gitprompt, powerlevel10k, agkozak, zinc, etc.). > And I had different problems in mind than those outlined by > Sebastian: for all its popularity and multitudes of "contributors", > OMZ has a quality problem. Contributions are largely forgotten once > accepted because ownership is transferred. They don't make good use of > autoloading, possibly run compinit more than once with changed $fpath > and don't seem to encourage the use of things like add-zsh-hook. They also return the values from functions not through REPLY/reply but via echo, like here: https://github.com/ohmyzsh/ohmyzsh/blob/master/lib/git.zsh > The plugin standard and documentation of it determines those things. I hope that the standard will be made some use if the bundled p-m project would be to start. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On Sat, 4 Jan 2020 at 06:16, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote: > > They also return the values from functions not through REPLY/reply but > via echo, like here: > > https://github.com/ohmyzsh/ohmyzsh/blob/master/lib/git.zsh PS. Well, in this case, that's actually OK – the functions are to be expanded in prompt. -- Sebastian Gniazdowski News: https://twitter.com/ZdharmaI IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin Blog: http://zdharma.org
On Sat, Jan 4, 2020 at 1:40 AM dana <dana@dana.is> wrote: > 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? If keys such as arrows, home, end and delete just worked, this would be perfect! My comment presupposed the existing zsh, which requires a few bindkey commands to make these keys work. The use of terminfo here results in brittle code. Let me show what I mean. ${terminfo[khome]} expands to the escape sequence for the home key. Let's try using it: autoload -Uz terminfo bindkey ${terminfo[khome]} beginning-of-line Doesn't work. Zsh puts terminal in raw mode (rmkx) when it starts but ${terminfo[khome]} is the escape key for application mode (smkx). Let's manually switch terminal to application mode. echoti smkx This works. Until we run an application that switches terminal back to raw mode. To solve this problem we can hook zle-line-init and switch to application mode from there. function zle-line-init () { echoti smkx; } zle -N zle-line-init It's what Debian does. And Oh My Zsh. And Prezto. This works. Until we source a plugin before setting up bindings and the plugin happens to hook zle-line-init. Our zle-line-init overrides the plugin's, breaking it in the process. Let's fix it by calling the plugin's hook from ours. zle -A zle-line-init orig-zle-line-init function my-zle-line-init () { zle orig-zle-line-init echoti smkx } zle -N zle-line-init my-zle-line-init This works. Until we source a plugin after setting up bindings and the plugin happens to hook zle-line-init without calling our hook. This time it's the plugin breaking our code rather than vise versa. The alternative to this rather complex and brittle approach is to bind beginning-of-line to several escape sequences. bindkey '^[[H' beginning-of-line # home in raw mode bindkey '^[OH' beginning-of-line # home in app mode To avoid having to specify bindings several times, we can translate escape sequences from application mode to their counterparts in raw mode, and bind all keys as if the terminal was always in raw mode. # Translate application mode (smkx) key escape codes, # to raw mode (rmkx). bindkey -s '^[OH' '^[[H' # home bindkey -s '^[OF' '^[[F' # end # etc bindkey '^[[H' beginning-of-line # home bindkey '^[[F' end-of-line # end # etc The same approach works with terminals of different type: # TTY sends different key codes. Translate them to regular. bindkey -s '^[[1~' '^[[H' # home bindkey -s '^[[4~' '^[[F' # end And NumLock: # If NumLock is off, translate keys to make them appear # the same as with NumLock on. bindkey -s '^[OM' '^M' # enter bindkey -s '^[Ok' '+' bindkey -s '^[Om' '-' bindkey -s '^[Oj' '*' bindkey -s '^[Oo' '/' bindkey -s '^[OX' '=' This makes keys such as `/` and `+` on the numpad work in zsh the same way they work everywhere else. The downside of such shotgun-type translation is the possibility of clashes. It's possible in theory that one terminal's escape code for the home key is another terminal's code for the end key. This can be dealt with with some conditionals. I don't have any in my own zshrc as none of the terminals I use produce clashes on any key sequences. I imagine not everyone is so lucky. > 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. Oh yeah, I've nothing against styles. I wanted (but failed) to make a point that the basic config shouldn't attempt to provide the best possible shell experience at the expense of config complexity. If 12 completion style lines give you only slightly better completion that 2 lines, it may be preferable to go with 2 lines. When the user's complexity threshold is exceeded by the config, the whole thing becomes opaque. A slightly worse but simpler config may result in better long term user experience as the user will be able to customize it. Roman.
Roman Perepelitsa wrote on Sat, 04 Jan 2020 15:46 +00:00: > zle -N zle-line-init my-zle-line-init > > This works. Until we source a plugin after setting up bindings and the > plugin happens to hook zle-line-init without calling our hook. This > time it's the plugin breaking our code rather than vise versa. That plugin is broken. Plugins shouldn't overwrite whatever had been hooked to zle-line-init before they were sourced. That's no more acceptable than for a plugin to rm(1) files that it didn't create. I know of two solutions. One, plugins can wrap my-zle-line-init (using ${widgets} to discover it). Two, add-zle-hook-widget may be used. > The alternative to this rather complex and brittle approach is to bind > beginning-of-line to several escape sequences. "Hard cases make bad law." Don't design the system to DTRT even when plugins remove random files; just fix those plugins, or don't use them. > > 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. > > Oh yeah, I've nothing against styles. I wanted (but failed) to make a > point that the basic config shouldn't attempt to provide the best > possible shell experience at the expense of config complexity. If 12 > completion style lines give you only slightly better completion that 2 > lines, it may be preferable to go with 2 lines. When the user's > complexity threshold is exceeded by the config, the whole thing > becomes opaque. A slightly worse but simpler config may result in > better long term user experience as the user will be able to customize > it. Well, yes and no. You're right that new users shouldn't be overwhelmed with complexity right off the bat, but that doesn't mean we can't have any complexity at all; we just have to label it appropriately so new users won't try to dive into it on their first day. For example, in zsh-sensible we could, say, create a "zshrc.history_options" file that walks the reader through the 25 (!) history-related options, and have zshrc point to it as a "further reading" resource. [It may very well be that few readers will ever open that file. That'll be an indication that it's working as designed. :)] I've done this sort of thing before in presentations (put the table of contents in the margin of each slide, with chapter titles being hyperlinks, and click them to skip past entire chapters). It's even been done in print: for example, The TeXbook called this "dangerous bends". Cheers, Daniel
On Sat, Jan 4, 2020 at 5:28 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > Roman Perepelitsa wrote on Sat, 04 Jan 2020 15:46 +00:00: > > zle -N zle-line-init my-zle-line-init > > > > This works. Until we source a plugin after setting up bindings and the > > plugin happens to hook zle-line-init without calling our hook. This > > time it's the plugin breaking our code rather than vise versa. > > That plugin is broken. Before crossing a road on green light, I first check if there are cars speeding through the intersection. It's illegal for them to do so, but I'd rather turn my head than die being right. I don't know of a downside to key translation I mentioned earlier, so I'm not even paying the price of turning my head when I use it (or maybe I do and just don't know it?). If I were using terminfo to fetch the escape codes for home and end keys, I would still have to hardcode escape codes for other keys or key combinations as terminfo is rather sparse in this regard, and I would still have to handle NumLock the same way I do now. Am I missing something? > Well, yes and no. You're right that new users shouldn't be overwhelmed > with complexity right off the bat, but that doesn't mean we can't have > any complexity at all; I think we are on the same page here. Roman.
On Sat, Jan 4, 2020 at 7:47 AM Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> If keys such as arrows, home, end and delete just worked, this would be perfect!
I tried to solve this a long time ago with Functions/Misc/zkbd, which
allows one to interactively create a terminal profile. The problem is
with knowing how to save/select the correct profile once it has been
created -- I can remote-login to the same home directory from 3
different places with terminals that all identify themselves as the
same terminal type and yet require 3 different profiles to get the key
bindings right depending on the hardware+OS+terminal-emulator from
which I am connecting.
If zkbd could be updated with a better scheme than just using the
value of $TERM to identify the context, it's the sort of thing that
could be invoked from newuser-install.
Roman Perepelitsa wrote on Sat, 04 Jan 2020 16:41 +00:00: > On Sat, Jan 4, 2020 at 5:28 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > > > > Roman Perepelitsa wrote on Sat, 04 Jan 2020 15:46 +00:00: > > > zle -N zle-line-init my-zle-line-init > > > > > > This works. Until we source a plugin after setting up bindings and the > > > plugin happens to hook zle-line-init without calling our hook. This > > > time it's the plugin breaking our code rather than vise versa. > > > > That plugin is broken. > > Before crossing a road on green light, I first check if there are cars > speeding through the intersection. It's illegal for them to do so, but > I'd rather turn my head than die being right. The plugin is something you installed in your own home directory of your own free will; the hypothesized driver was not placed on the road by you of your own free will. The two are not analogous. Complaining about not being able to do something because of a plugin you had installed is like complaining that you have to sleep with earplugs after inviting someone to practice playing the trumpet in the guest bedroom. > I don't know of a downside to key translation I mentioned earlier, so > I'm not even paying the price of turning my head when I use it (or > maybe I do and just don't know it?). If I were using terminfo to fetch > the escape codes for home and end keys, I would still have to hardcode > escape codes for other keys or key combinations as terminfo is rather > sparse in this regard, and I would still have to handle NumLock the > same way I do now. Am I missing something? Your argument boils down to saying you won't use the zle-line-init feature for anything because some plugin has appropriated it for itself. It seems that it was concluded under the constraint that the plugin must be installed. Just throw that constraint out and use the obvious solution: deinstall the plugin and use zle-line-init however you like. (That's the entire point of this thread: that users should be able to customize their configurations to their liking.) (Or fix the plugin, as I pointed out in the part of the mail you had snipped.) As to making home and end work, that's not zshrc's job. There is very little about the problem of mapping escape sequences to zle widgets that varies per user.
On Sat, Jan 4, 2020 at 6:36 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote: > Your argument boils down to saying you won't use the zle-line-init > feature for anything because some plugin has appropriated it for > itself. My argument is that binding keys the way I do it appears to me strictly better than the alternative even if there were no plugins, broken or otherwise. The fact that it's more robust in the fact of misbehaving plugins is a bonus. It's possible that I'm missing a downside of my approach, or an upside of the alternative. > As to making home and end work, that's not zshrc's job. I was suspecting that everyone already knows the right solution to this problem and I'm making a fool of myself describing my silly setup. What's the right way of doing it? Roman.
Bart wrote:
> > If keys such as arrows, home, end and delete just worked, this would be perfect!
>
> I tried to solve this a long time ago with Functions/Misc/zkbd, which
> allows one to interactively create a terminal profile. The problem is
> with knowing how to save/select the correct profile once it has been
My own approach generally consists of binding all the common sequences
without regard for whether they are right for the exact terminal in use.
Zsh's C code is binding both raw and application mode sequences for the
cursor keys which is similar.
Clashes are fairly rare and where I have come across them, it has only
been for terminals that set $TERM to something unique. To matter, the
clash has to be between two keys we want to bind which is rare. Del
producing ^? (which other terminals have for Backspace) is one case.
In my view, we should add bindings as best we can in the C code. It may
not be perfect but will work for the vast majority of users and likely
be harmless for the rest.
Oliver
Daniel Shahaf <d.s@daniel.shahaf.name> writes: > Peter Stephenson wrote on Fri, Jan 03, 2020 at 15:00:09 +0000: >> On Thu, 2020-01-02 at 21:26 -0600, dana wrote: >> > On 2 Jan 2020, at 20:45, Bart Schaefer <schaefer@brasslantern.com> wrote: >> > > >> > > It has been our long-standing practice to recommend that package >> > > builders/installers do NOT create /etc/z* files, or make them minimal, >> > > so as not to interfere with users own initialization files. Maybe >> > > it's time to relax that, or at least to provide a suggested skeleton >> > > .zshrc -- which we could connect to zsh-newuser-install to be slurped >> > > in without having to go through all the questions if you just want to >> > > "feel lucky". >> > The latter is what i'm suggesting, yeah. Dumb down the wizard a bit, add a >> > flashy option to the first screen that says 'do the cool things >> > (recommended)' >> > or whatever, and have it install a well-commented .zshrc with the settings >> > that that a novice/casual user would look for. >> >> I tend to agree with the thrust of this --- feedback over the years has >> been quite strongly people don't want to do anything clever; the difficulty >> remaining is what sort of basic set up to copy in instead. But yes, >> whatever that is it should probably be something prepared elsewhere and >> copying in that should probably be the highlighted / default option. > > I agree: my take-away from the discussion is that there's room for a "sensible > defaults" thingy (be it a zshrc template or a plugin). Shall we create > a github/gitlab repo to work on that in? What I once made for our local student users (ignore the last three functions and the prompt if you want): http://leahneukirchen.org/dotfiles/.zshrc.sensible -- Leah Neukirchen <leah@vuxu.org> https://leahneukirchen.org/