zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: Proof of concept mainstream plugin manager
Date: Fri, 22 Jan 2016 17:37:05 -0800	[thread overview]
Message-ID: <160122173705.ZM11491@torch.brasslantern.com> (raw)
In-Reply-To: <CAKc7PVByfo51GcVkb_kYgO2D3cWYrcq-p4v8gmyfsaeWU=2new@mail.gmail.com>

On Jan 22,  8:44pm, Sebastian Gniazdowski wrote:
}
} I imagine much more can be done if mainstream pairs of eyes will look
} at this. Any ideas of what can be done?
} 
} https://github.com/psprint/zsh-plugin-governor

Some thoughts ...

Consider declaring some or all ZGOV_* variables with "typeset -gH".

For shadowing commands like "autoload", you'd be better off using
function wrappers rather than aliases.  There are too many ways that
aliases can be turned off or bypassed, and none of the commands you
are replacing have keyword-like behavior.

I'm not sure how much value there is in capturing "setopt".  It's
really difficult to manage the side-effects of the "localoptions"
option within a wrapper function, and there are several other ways
to change options as well.  

You're failing to handle any of the flags of the "autoload" command
in zgov-shadow-autoload.  You can probably pass these through to the
"builtin autoload -X" inside the "eval".

You can of course eval a single double-quoted string with embedded
newlines instead of ending all those lines with backslash.

Various things in here are going to gripe if the warn_create_global
option is set.  Hard to decide what to do about that given that this
file is meant to be loaded with "source".  Perhaps wrap the entire
file in an anonymous function:

    () {
      emulate -LR zsh
      unsetopt warncreateglobal # not needed as of 5.3 with emulate

      # your entire current file contents go here
      # except you must use explicit "typeset -g"
    }

Every plugin that you "source" from inside zgov-load-plugin is going
to have a similar problem:  They're one level deeper in the function
stack than they would be if sourced directly from .zshrc and need to
be prepared for that.

For unloading, what you need is a diff of ${(k)functions} before and
after the plugin is loaded, assuming that the plugin really does
autoload or otherwise declare all its function names at load time.
Possibly a conventional unload function name, expected to be defined
by the plugin, could be called if it is in fact defined.  You may even
want the sort of setup/boot/cleanup/finish model used by zmodload
for binary object modules.

As a final thought, I'd just call this whole thing "zplugin", forget the
suffix "governor", name the variables ZPLUG_*, etc.

-- 
Barton E. Schaefer


  reply	other threads:[~2016-01-23  1:36 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-22 19:44 Sebastian Gniazdowski
2016-01-23  1:37 ` Bart Schaefer [this message]
2016-01-23  9:03   ` Sebastian Gniazdowski
2016-01-23 15:54     ` Sebastian Gniazdowski
2016-01-23 16:00       ` Sebastian Gniazdowski
2016-01-23 16:09         ` Sebastian Gniazdowski
2016-01-23 16:26           ` Sebastian Gniazdowski
2016-01-23 17:36           ` Bart Schaefer
2016-01-23 19:20             ` Bart Schaefer
2016-01-23 20:00               ` Bart Schaefer
2016-01-24 10:51                 ` Sebastian Gniazdowski
2016-01-24 14:59                   ` Sebastian Gniazdowski
2016-01-24 19:06                     ` Sebastian Gniazdowski
2016-01-24 20:45                     ` Bart Schaefer
2016-06-04 11:36                       ` Sebastian Gniazdowski
2016-06-04 17:02                         ` Bart Schaefer
2016-01-26 22:50                   ` Daniel Shahaf
2016-01-27  7:47                     ` Sebastian Gniazdowski
2016-01-26 22:50                 ` Daniel Shahaf
2016-01-27  4:34                   ` Bart Schaefer
2016-01-27  7:34                     ` Sebastian Gniazdowski
2016-01-28  6:38                       ` Bart Schaefer
2016-01-28  7:13                         ` Sebastian Gniazdowski

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=160122173705.ZM11491@torch.brasslantern.com \
    --to=schaefer@brasslantern.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).