zsh-workers
 help / color / mirror / Atom feed
* Official plugin manager?
@ 2020-01-02  3:17 Sebastian Gniazdowski
  2020-01-02  4:28 ` Eric Cook
  2020-01-02 11:03 ` Daniel Shahaf
  0 siblings, 2 replies; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-02  3:17 UTC (permalink / raw)
  To: Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02  3:17 Official plugin manager? Sebastian Gniazdowski
@ 2020-01-02  4:28 ` Eric Cook
  2020-01-02 11:03 ` Daniel Shahaf
  1 sibling, 0 replies; 34+ messages in thread
From: Eric Cook @ 2020-01-02  4:28 UTC (permalink / raw)
  To: zsh-workers

On 1/1/20 10:17 PM, Sebastian Gniazdowski wrote:
> Maybe it's the right time to glance over
> them?

nah


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02  3:17 Official plugin manager? Sebastian Gniazdowski
  2020-01-02  4:28 ` Eric Cook
@ 2020-01-02 11:03 ` Daniel Shahaf
  2020-01-02 11:37   ` Sebastian Gniazdowski
  2020-01-02 12:00   ` Roman Perepelitsa
  1 sibling, 2 replies; 34+ messages in thread
From: Daniel Shahaf @ 2020-01-02 11:03 UTC (permalink / raw)
  To: Sebastian Gniazdowski, Zsh hackers list

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).

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02 11:03 ` Daniel Shahaf
@ 2020-01-02 11:37   ` Sebastian Gniazdowski
  2020-01-02 11:55     ` Sebastian Gniazdowski
  2020-01-02 21:30     ` dana
  2020-01-02 12:00   ` Roman Perepelitsa
  1 sibling, 2 replies; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-02 11:37 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02 11:37   ` Sebastian Gniazdowski
@ 2020-01-02 11:55     ` Sebastian Gniazdowski
  2020-01-02 21:30     ` dana
  1 sibling, 0 replies; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-02 11:55 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02 11:03 ` Daniel Shahaf
  2020-01-02 11:37   ` Sebastian Gniazdowski
@ 2020-01-02 12:00   ` Roman Perepelitsa
  2020-01-02 12:21     ` Sebastian Gniazdowski
  1 sibling, 1 reply; 34+ messages in thread
From: Roman Perepelitsa @ 2020-01-02 12:00 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Sebastian Gniazdowski, Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02 12:00   ` Roman Perepelitsa
@ 2020-01-02 12:21     ` Sebastian Gniazdowski
  2020-01-02 12:27       ` Roman Perepelitsa
  0 siblings, 1 reply; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-02 12:21 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02 12:21     ` Sebastian Gniazdowski
@ 2020-01-02 12:27       ` Roman Perepelitsa
  0 siblings, 0 replies; 34+ messages in thread
From: Roman Perepelitsa @ 2020-01-02 12:27 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02 11:37   ` Sebastian Gniazdowski
  2020-01-02 11:55     ` Sebastian Gniazdowski
@ 2020-01-02 21:30     ` dana
  2020-01-03  0:25       ` Sebastian Gniazdowski
  1 sibling, 1 reply; 34+ messages in thread
From: dana @ 2020-01-02 21:30 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh hackers list

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-02 21:30     ` dana
@ 2020-01-03  0:25       ` Sebastian Gniazdowski
  2020-01-03  1:36         ` dana
  0 siblings, 1 reply; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-03  0:25 UTC (permalink / raw)
  To: dana; +Cc: Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03  0:25       ` Sebastian Gniazdowski
@ 2020-01-03  1:36         ` dana
  2020-01-03  2:43           ` Sebastian Gniazdowski
  2020-01-03  2:45           ` Bart Schaefer
  0 siblings, 2 replies; 34+ messages in thread
From: dana @ 2020-01-03  1:36 UTC (permalink / raw)
  To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh hackers list

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03  1:36         ` dana
@ 2020-01-03  2:43           ` Sebastian Gniazdowski
  2020-01-03  2:45           ` Bart Schaefer
  1 sibling, 0 replies; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-03  2:43 UTC (permalink / raw)
  To: dana; +Cc: Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03  1:36         ` dana
  2020-01-03  2:43           ` Sebastian Gniazdowski
@ 2020-01-03  2:45           ` Bart Schaefer
  2020-01-03  3:26             ` dana
  2020-01-03 11:15             ` Oliver Kiddle
  1 sibling, 2 replies; 34+ messages in thread
From: Bart Schaefer @ 2020-01-03  2:45 UTC (permalink / raw)
  To: dana; +Cc: Sebastian Gniazdowski, Daniel Shahaf, Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03  2:45           ` Bart Schaefer
@ 2020-01-03  3:26             ` dana
  2020-01-03  5:13               ` Sebastian Gniazdowski
  2020-01-03 15:00               ` Peter Stephenson
  2020-01-03 11:15             ` Oliver Kiddle
  1 sibling, 2 replies; 34+ messages in thread
From: dana @ 2020-01-03  3:26 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Sebastian Gniazdowski, Daniel Shahaf, Zsh hackers list

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03  3:26             ` dana
@ 2020-01-03  5:13               ` Sebastian Gniazdowski
  2020-01-03 15:00               ` Peter Stephenson
  1 sibling, 0 replies; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-03  5:13 UTC (permalink / raw)
  To: dana; +Cc: Bart Schaefer, Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03  2:45           ` Bart Schaefer
  2020-01-03  3:26             ` dana
@ 2020-01-03 11:15             ` Oliver Kiddle
  2020-01-04  5:16               ` Sebastian Gniazdowski
  1 sibling, 1 reply; 34+ messages in thread
From: Oliver Kiddle @ 2020-01-03 11:15 UTC (permalink / raw)
  To: Bart Schaefer
  Cc: dana, Sebastian Gniazdowski, Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03  3:26             ` dana
  2020-01-03  5:13               ` Sebastian Gniazdowski
@ 2020-01-03 15:00               ` Peter Stephenson
  2020-01-03 20:48                 ` Daniel Shahaf
  1 sibling, 1 reply; 34+ messages in thread
From: Peter Stephenson @ 2020-01-03 15:00 UTC (permalink / raw)
  To: zsh-workers

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 15:00               ` Peter Stephenson
@ 2020-01-03 20:48                 ` Daniel Shahaf
  2020-01-03 21:51                   ` Roman Perepelitsa
  2020-01-06 17:47                   ` Leah Neukirchen
  0 siblings, 2 replies; 34+ messages in thread
From: Daniel Shahaf @ 2020-01-03 20:48 UTC (permalink / raw)
  To: zsh-workers

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 20:48                 ` Daniel Shahaf
@ 2020-01-03 21:51                   ` Roman Perepelitsa
  2020-01-03 22:06                     ` Daniel Shahaf
  2020-01-06 17:47                   ` Leah Neukirchen
  1 sibling, 1 reply; 34+ messages in thread
From: Roman Perepelitsa @ 2020-01-03 21:51 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 21:51                   ` Roman Perepelitsa
@ 2020-01-03 22:06                     ` Daniel Shahaf
  2020-01-03 22:26                       ` Bart Schaefer
  2020-01-03 22:37                       ` Roman Perepelitsa
  0 siblings, 2 replies; 34+ messages in thread
From: Daniel Shahaf @ 2020-01-03 22:06 UTC (permalink / raw)
  To: zsh-workers

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 22:06                     ` Daniel Shahaf
@ 2020-01-03 22:26                       ` Bart Schaefer
  2020-01-03 22:37                       ` Roman Perepelitsa
  1 sibling, 0 replies; 34+ messages in thread
From: Bart Schaefer @ 2020-01-03 22:26 UTC (permalink / raw)
  To: zsh-workers

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 22:06                     ` Daniel Shahaf
  2020-01-03 22:26                       ` Bart Schaefer
@ 2020-01-03 22:37                       ` Roman Perepelitsa
  2020-01-04  0:42                         ` dana
  1 sibling, 1 reply; 34+ messages in thread
From: Roman Perepelitsa @ 2020-01-03 22:37 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 22:37                       ` Roman Perepelitsa
@ 2020-01-04  0:42                         ` dana
  2020-01-04  1:06                           ` Daniel Shahaf
  2020-01-04 15:46                           ` Roman Perepelitsa
  0 siblings, 2 replies; 34+ messages in thread
From: dana @ 2020-01-04  0:42 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: Daniel Shahaf, Zsh hackers list

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


^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04  0:42                         ` dana
@ 2020-01-04  1:06                           ` Daniel Shahaf
  2020-01-04 15:46                           ` Roman Perepelitsa
  1 sibling, 0 replies; 34+ messages in thread
From: Daniel Shahaf @ 2020-01-04  1:06 UTC (permalink / raw)
  To: zsh-workers

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 11:15             ` Oliver Kiddle
@ 2020-01-04  5:16               ` Sebastian Gniazdowski
  2020-01-04  6:00                 ` Sebastian Gniazdowski
  0 siblings, 1 reply; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-04  5:16 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Bart Schaefer, dana, Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04  5:16               ` Sebastian Gniazdowski
@ 2020-01-04  6:00                 ` Sebastian Gniazdowski
  0 siblings, 0 replies; 34+ messages in thread
From: Sebastian Gniazdowski @ 2020-01-04  6:00 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Bart Schaefer, dana, Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04  0:42                         ` dana
  2020-01-04  1:06                           ` Daniel Shahaf
@ 2020-01-04 15:46                           ` Roman Perepelitsa
  2020-01-04 16:27                             ` Daniel Shahaf
  2020-01-04 17:11                             ` Bart Schaefer
  1 sibling, 2 replies; 34+ messages in thread
From: Roman Perepelitsa @ 2020-01-04 15:46 UTC (permalink / raw)
  To: dana; +Cc: Daniel Shahaf, Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04 15:46                           ` Roman Perepelitsa
@ 2020-01-04 16:27                             ` Daniel Shahaf
  2020-01-04 16:41                               ` Roman Perepelitsa
  2020-01-04 17:11                             ` Bart Schaefer
  1 sibling, 1 reply; 34+ messages in thread
From: Daniel Shahaf @ 2020-01-04 16:27 UTC (permalink / raw)
  To: Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04 16:27                             ` Daniel Shahaf
@ 2020-01-04 16:41                               ` Roman Perepelitsa
  2020-01-04 17:35                                 ` Daniel Shahaf
  0 siblings, 1 reply; 34+ messages in thread
From: Roman Perepelitsa @ 2020-01-04 16:41 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04 15:46                           ` Roman Perepelitsa
  2020-01-04 16:27                             ` Daniel Shahaf
@ 2020-01-04 17:11                             ` Bart Schaefer
  2020-01-05 10:40                               ` Oliver Kiddle
  1 sibling, 1 reply; 34+ messages in thread
From: Bart Schaefer @ 2020-01-04 17:11 UTC (permalink / raw)
  To: Roman Perepelitsa; +Cc: dana, Daniel Shahaf, Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04 16:41                               ` Roman Perepelitsa
@ 2020-01-04 17:35                                 ` Daniel Shahaf
  2020-01-04 17:42                                   ` Roman Perepelitsa
  0 siblings, 1 reply; 34+ messages in thread
From: Daniel Shahaf @ 2020-01-04 17:35 UTC (permalink / raw)
  To: zsh-workers

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04 17:35                                 ` Daniel Shahaf
@ 2020-01-04 17:42                                   ` Roman Perepelitsa
  0 siblings, 0 replies; 34+ messages in thread
From: Roman Perepelitsa @ 2020-01-04 17:42 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Zsh hackers list

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.

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-04 17:11                             ` Bart Schaefer
@ 2020-01-05 10:40                               ` Oliver Kiddle
  0 siblings, 0 replies; 34+ messages in thread
From: Oliver Kiddle @ 2020-01-05 10:40 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: Roman Perepelitsa, dana, Daniel Shahaf, Zsh hackers list

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

^ permalink raw reply	[flat|nested] 34+ messages in thread

* Re: Official plugin manager?
  2020-01-03 20:48                 ` Daniel Shahaf
  2020-01-03 21:51                   ` Roman Perepelitsa
@ 2020-01-06 17:47                   ` Leah Neukirchen
  1 sibling, 0 replies; 34+ messages in thread
From: Leah Neukirchen @ 2020-01-06 17:47 UTC (permalink / raw)
  To: zsh-workers

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/


^ permalink raw reply	[flat|nested] 34+ messages in thread

end of thread, other threads:[~2020-01-06 17:47 UTC | newest]

Thread overview: 34+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-01-02  3:17 Official plugin manager? Sebastian Gniazdowski
2020-01-02  4:28 ` Eric Cook
2020-01-02 11:03 ` Daniel Shahaf
2020-01-02 11:37   ` Sebastian Gniazdowski
2020-01-02 11:55     ` Sebastian Gniazdowski
2020-01-02 21:30     ` dana
2020-01-03  0:25       ` Sebastian Gniazdowski
2020-01-03  1:36         ` dana
2020-01-03  2:43           ` Sebastian Gniazdowski
2020-01-03  2:45           ` Bart Schaefer
2020-01-03  3:26             ` dana
2020-01-03  5:13               ` Sebastian Gniazdowski
2020-01-03 15:00               ` Peter Stephenson
2020-01-03 20:48                 ` Daniel Shahaf
2020-01-03 21:51                   ` Roman Perepelitsa
2020-01-03 22:06                     ` Daniel Shahaf
2020-01-03 22:26                       ` Bart Schaefer
2020-01-03 22:37                       ` Roman Perepelitsa
2020-01-04  0:42                         ` dana
2020-01-04  1:06                           ` Daniel Shahaf
2020-01-04 15:46                           ` Roman Perepelitsa
2020-01-04 16:27                             ` Daniel Shahaf
2020-01-04 16:41                               ` Roman Perepelitsa
2020-01-04 17:35                                 ` Daniel Shahaf
2020-01-04 17:42                                   ` Roman Perepelitsa
2020-01-04 17:11                             ` Bart Schaefer
2020-01-05 10:40                               ` Oliver Kiddle
2020-01-06 17:47                   ` Leah Neukirchen
2020-01-03 11:15             ` Oliver Kiddle
2020-01-04  5:16               ` Sebastian Gniazdowski
2020-01-04  6:00                 ` Sebastian Gniazdowski
2020-01-02 12:00   ` Roman Perepelitsa
2020-01-02 12:21     ` Sebastian Gniazdowski
2020-01-02 12:27       ` Roman Perepelitsa

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror http://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ http://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git