zsh-workers
 help / color / mirror / code / Atom feed
From: Sebastian Gniazdowski <sgniazdowski@gmail.com>
To: Roman Perepelitsa <roman.perepelitsa@gmail.com>
Cc: Daniel Shahaf <d.s@daniel.shahaf.name>,
	Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: A serious bug in execution – where to debug?
Date: Wed, 31 Jul 2019 13:41:17 +0200	[thread overview]
Message-ID: <CAKc7PVAMxstE137buR3vFLkmcHJ9KDg0WDGB95_3_8ZXNvh-Gg@mail.gmail.com> (raw)
In-Reply-To: <CAN=4vMrTHP5qtS0dJrLJKPc9M3K5DsLTAa78i+W7+Sy4F90YOw@mail.gmail.com>

On Wed, 31 Jul 2019 at 09:23, Roman Perepelitsa
<roman.perepelitsa@gmail.com> wrote:
>
> On Wed, Jul 31, 2019 at 3:30 AM Sebastian Gniazdowski
> <sgniazdowski@gmail.com> wrote:
> >
> > On Wed, 31 Jul 2019 at 00:39, Roman Perepelitsa
> > <roman.perepelitsa@gmail.com> 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

  reply	other threads:[~2019-07-31 11:42 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-07-30 17:00 Sebastian Gniazdowski
2019-07-30 17:05 ` Sebastian Gniazdowski
2019-07-30 17:41 ` Roman Perepelitsa
2019-07-30 17:55   ` Sebastian Gniazdowski
2019-07-30 18:12     ` Roman Perepelitsa
2019-07-30 18:16       ` Sebastian Gniazdowski
2019-07-30 18:22         ` Roman Perepelitsa
2019-07-30 18:53           ` Sebastian Gniazdowski
2019-07-30 19:23             ` Roman Perepelitsa
2019-07-30 19:34               ` Sebastian Gniazdowski
2019-07-30 19:41                 ` Roman Perepelitsa
2019-07-30 19:59                   ` Sebastian Gniazdowski
2019-07-30 20:08                     ` Roman Perepelitsa
2019-07-30 20:38                       ` Sebastian Gniazdowski
2019-07-30 18:27 ` Bart Schaefer
2019-07-30 18:46   ` Sebastian Gniazdowski
2019-07-30 21:02     ` Roman Perepelitsa
2019-07-30 21:38       ` Sebastian Gniazdowski
2019-07-30 21:45         ` Roman Perepelitsa
2019-07-30 21:54           ` Sebastian Gniazdowski
2019-07-30 22:11             ` Roman Perepelitsa
2019-07-30 22:18           ` Daniel Shahaf
2019-07-30 22:32             ` Roman Perepelitsa
2019-07-31  1:30               ` Sebastian Gniazdowski
2019-07-31  7:23                 ` Roman Perepelitsa
2019-07-31 11:41                   ` Sebastian Gniazdowski [this message]
2019-07-31 12:40                     ` Roman Perepelitsa
2019-07-31 13:10                       ` Sebastian Gniazdowski
2019-07-31 13:34                         ` Roman Perepelitsa
2019-07-31 13:40                           ` Sebastian Gniazdowski
2019-07-31 14:11                             ` Roman Perepelitsa
2019-07-31 17:56                               ` Sebastian Gniazdowski
2019-07-31  1:42               ` Bart Schaefer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKc7PVAMxstE137buR3vFLkmcHJ9KDg0WDGB95_3_8ZXNvh-Gg@mail.gmail.com \
    --to=sgniazdowski@gmail.com \
    --cc=d.s@daniel.shahaf.name \
    --cc=roman.perepelitsa@gmail.com \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).