Re: A serious bug in execution – where to debug?

[Sebastian Gniazdowski <sgniazdowski@xxxxxxxxx>]

On Wed, 31 Jul 2019 at 09:23, Roman Perepelitsa
<roman.perepelitsa@xxxxxxxxx> wrote:
>
> On Wed, Jul 31, 2019 at 3:30 AM Sebastian Gniazdowski
> <sgniazdowski@xxxxxxxxx> wrote:
> >
> > On Wed, 31 Jul 2019 at 00:39, Roman Perepelitsa
> > <roman.perepelitsa@xxxxxxxxx> wrote:
> >
> > > I'm on the fence on this issue. As long as I don't get too many bug
> > > reports because of over-ambitious plugin managers, I'm fine.
> >
> > So Zplugin is considered an over-ambitious plugin manager by you? :)
>
> I meant over-ambitious in the specific sense mentioned above --
> advertising features that are not and cannot be implemented.
> ...
> Features whose
> user-observable behavior cannot be described even in theory, and for
> which an honest specification is tightly tied to their implementation
> details, are over-ambitious.

I'm not sure if this will not be "honest specification" (that is) "is
tightly tied to their implementation
details", but somewhat user-observable effects of zplugin unload
procedure "described in theory" are:

1. Withdrawal of any bindkey call, i.e. if a plugin did bindkey ^T
widget, then the binding will be deleted (restoring of previous
binding is a TODO), including range bindings (bindkey -R).
2. Deletion of created keymaps (bindkey -N) and unlinking of the main
keymap (bindkey -A).
3. Withdrawal of any zstyles (again, only deletion).
4. Withdrawal (i.e. deletion) and restoration (i.e. set up of the
previous value) of aliases, including suffix and global aliases.
5. Withdrawal of zle created widgets (zle -N) – restoration and deletion.
6. Restoration of changed options.
7. Removal of added PATH and FPATH elements (adding of removed element
is ready to be implemented, yet it wasn't needed)
8. Deletion of created functions
9. Removal of any added hooks
10. Unset of created global parameters (restoration of previous type's
is a niche TODO).

> Saying that zplugin can unload arbitrary
> code is inaccurate at best and deceptive at worst.

Maybe.. I think that it's an untold common truth shared by any user
that Zplugin cannot be that smart to withdraw *any* sophisticated
effect of a potential plugin. Claiming in an straightforward manner
"Zplugin can unload plugins" is like a statement that encourages to
acknowledge that *some serious* unloading is possible, that the shell
isn't a black hole where things undergo untracked, in one direction
only. Didn't you revise your opinion a little on unloading of plugins
after reading the list from the previous paragraph?

> What the user will actually see is unpredictable.
I think that it's actually possible to predict to a large extent by
looking at the list of unload-actions.

> Spawning long-lived background processes that opt-out of job control
> isn't uncommon among zsh themes and plugins.

To be clear: I like the sophistication of the theme and see it as the
right path.

> Powerline, p10k, p9k,
> zinc, pure all do it. So does zplugin, I believe.

Zplugin forks (if you're talking about the `services' feature) or
loads a binary zshell module zplugin.so.

> Technical differences
> in background process management make it impossible to implement clean
> shutdown for these themes/plugins externally but they don't make them
> over-ambitious.

Ok, agreed.

> Powerline does what it claims to do -- give you a
> prompt with lots of colors and ornaments. No leaky abstractions, no
> deception.

I hope that by the second paragraph I've lessen the "deception"
argument to a significant degree.

> Having said that, I have no illusions about the utility of my public
> zsh code. If all zsh plugins and themes would disappear overnight, I
> don't know if the world would be better or worse off. This ecosystem
> feeds on customization addiction after all.
>
> Roman.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org