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

[Roman Perepelitsa <roman.perepelitsa@xxxxxxxxx>]

On Wed, Jul 31, 2019 at 3:10 PM Sebastian Gniazdowski
<sgniazdowski@xxxxxxxxx> wrote:
> This particular case will be solved if the plugin will use
> add-zle-hook-widget instead of wrapping (support for this isn't yet in
> zplugin, but it'll be there soon).

Unfortunately, using add-zle-hook-widget is no-no. If you use it while
other plugins are still wrapping widgets old-school, you can cause
infinite loops. All plugins have to be switched to add-zle-hook-widget
at the same time, which is pretty much impossible. Hopefully someone
will care enough to fix add-zle-hook-widget but the benefits are
difficult to see. Wrapping widgets works fine. It breaks zplugin's
unloading code but the same can be said about pretty much everything.

> To sum up, your opinion is a mathematical-like proof that:
>
> * You cannot implement an unloading that just works as expected.
>
> While my opinion is a practical-view -like point that:
>
> * You can often get good results with unloading, just try & test it
> first with the plugin that you need to unload.

Both statements are true.

What I don't like is the implication of offering a
maybe-works-maybe-doesn't unloading mechanism. It creates an
expectation that plugins must be unloadable not via their public APIs
but through brutal and unceremonious deletion of their internal
parameters, widgets and so on. If something breaks during unloading,
users may not even realize they've grown to rely on hacks and that
their shell configuration is unsupported. They can reasonably reach
out to the "malfunctioning" plugin's developers and ask them to fix
the "issue". It's like selling rocks as a tool to turn off TV sets.
Just throw a rock at the TV and it'll turn off! If it breaks your TV,
please don't complain to your TV manufacturer.

I also have intense emotional reaction to this kind of unloading. It
just feels rude to modify internal implementation details of software.
It's one thing to do it with code that only you yourself use, or to
apply this sort of dirty patching to a product you are intimately
familiar with, but it's quite another to distribute this crude tool as
a feature. It's disrespectful to the developers whose code is
brutalized, and it causes extra strain on them due to bug reports by
the affected users.

Roman.