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

[Roman Perepelitsa <roman.perepelitsa@gmail.com>]

On Tue, Jul 30, 2019 at 9:59 PM Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
>
> On Tue, 30 Jul 2019 at 21:42, Roman Perepelitsa
> <roman.perepelitsa@gmail.com> wrote:
> >
> > On Tue, Jul 30, 2019 at 9:34 PM Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:
> >>
> >> On Tue, 30 Jul 2019 at 21:24, Roman Perepelitsa
> >> <roman.perepelitsa@gmail.com> wrote:
> > I think we are in agreement. If there is a public function to unload, you can call it. If there isn't, it's a missing feature that cannot be provided by anyone other than the code's author. it's not possible to safely unload code as a blackbox without knowing all of its implementation details.
>
> Yes, but that's in general. I have very positive experiences with
> unloading of prompts. Currently in my setup by setting parameter
> MYPROMPT=1..8 I can choose the prompt that's active, as described in:
> http://zdharma.org/zplugin/site/Multiple-prompts/. In general it is
> like you've said, e.g. syntax-highlighting plugin's won't unload
> correctly, but only due to a final glitch and as I tested now, it
> *did* unload correctly (due to changes in my setup, most probably).
> But in general yes, plugins often do not unload fully clean, so I
> think that we are in agreement.

I'm not above some dirty hacks myself but you have to be clear with
your messaging if you are inviting others to use your code. If your
code may or may not work, can leak resources and corrupt files
(corrupting .git is pretty bad), can work today and stop working
tomorrow after an update, -- you might want to mention it.

>
> > Both gitstatusd and p10k do provide public functions for unloading. You are welcome to call them. They guarantee that repeated load+unload won't leak resources. That is, as long as you don't unset any of their internal variables. They do leave a handful of global parameters after unloading; without them they cannot be loaded correctly again.
>
> Could the function powerlevel10k_unload_plugin() be provided? I could
> deduce it from the plugin's name and call it in a general manner.

I have no objections against your providing this function, although I
would prefer that you didn't use "powerlevel10k" prefix to avoid
potential name clashes in the future. As long as it calls only the
public functions of p10k, it won't break when p10k evolves.

Roman.