Re: Official plugin manager?

["Daniel Shahaf" <d.s@xxxxxxxxxxxxxxxxxx>]

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