Updates to the Plugin Standard

Updates to the Plugin Standard

[Sebastian Gniazdowski]

Hello,
I'm doing the ongoing effort to create the definition of a Zsh plugin.
It's available here:

http://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html

The document received several updates, namely:

1. Five "Best Practices" sections describing the recommended
programming practices when programming a plugin. It might be
interesting to read them.

2. Two sections on two new proposed plugin mechanisms, namely the
@zsh-plugin-run-on-{update,unload} calls.

The history of updates to the document is available in the Appendix:

http://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html#appendix

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

Re: Updates to the Plugin Standard

[René Wilhelm]

So much work and thought. Thank you Sebastian.




‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, October 25, 2019 8:21 PM, Sebastian Gniazdowski <sgniazdowski@gmail.com> wrote:

> Hello,
> I'm doing the ongoing effort to create the definition of a Zsh plugin.
> It's available here:
>
> http://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html
>
> The document received several updates, namely:
>
> 1.  Five "Best Practices" sections describing the recommended
>     programming practices when programming a plugin. It might be
>     interesting to read them.
>
> 2.  Two sections on two new proposed plugin mechanisms, namely the
>     @zsh-plugin-run-on-{update,unload} calls.
>
>     The history of updates to the document is available in the Appendix:
>
>     http://zdharma.org/Zsh-100-Commits-Club/Zsh-Plugin-Standard.html#appendix
>
>     --
>     Sebastian Gniazdowski
>     News: https://twitter.com/ZdharmaI
>     IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
>     Blog: http://zdharma.org
>

Re: Updates to the Plugin Standard

[gi1242+zsh]

[-- Attachment #1: Type: text/plain, Size: 559 bytes --]

I took a quick look at the namespace prefix section: That looks a bit
overkill to me. Also using . and / as function prefixes can easily get
confused with paths.

I'd suggest using just one name space prefix for everything to keep
things simple. It could be ::function, or pluginName::funciton for
instance.

If there are too many types, it makes it more confusing / cumbersome
when writing.

GI

-- 
'Common' Proof Techniques:
12. Proof by obfuscation -- A long plotless sequence of true and/or
meaningless syntactically related statements.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: Updates to the Plugin Standard

[Sebastian Gniazdowski]

[-- Attachment #1: Type: text/plain, Size: 2329 bytes --]

pt., 25 paź 2019, 21:08 użytkownik <gi1242+zsh@gmail.com> napisał:

> I took a quick look at the namespace prefix section: That looks a bit
> overkill to me. Also using . and / as function prefixes can easily get
> confused with paths.
>
> I'd suggest using just one name space prefix for everything to keep
> things simple. It could be ::function, or pluginName::funciton for
> instance.
>

The section has purely advisory character. However for the pluginName::
proposal there's a valid argument - the possible conflict as in
https://github.com/zdharma/fast-syntax-highlighting/issues/157.

As for the points about the dot and / prefixes, I'll take them into
consideration. Right now I can tell that the / prefix is used for debug
functions because they're most outside from the main code. They're side to
the main code, hence the overall nice (and most of all – available) but
otherwise problematic ASCII character '/' has been selected to them. The
other available characters, like ^ aren't available because of the <= 5.7.1
autoload bug (https://www.zsh.org/mla/workers/2019/msg00534.html) however
hence / isn't available for autoload anyway, the character might get
changed. Any propositions for a replacement?

If there are too many types, it makes it more confusing / cumbersome
> when writing.
>

My subjective impression is that the : prefix is especially useful. Many
functions are hooks, and it's nice to list them as in
https://asciinema.org/a/277059, just to see them grouped (noticing: they're
cannot be directly completed, entering :<TAB> tries to complete the
modifiers, is there a way to change this?).

I foresee that the number of prefixes will not get smaller, it might get,
however, larger, when the Unicode characters will get mentally accepted
into consideration. I'm already using …-prefix in one of my projects as
it's easy to type (Alt-k on my keymap), to denote a "backend function",
i.e. a function that is a closed black-box -like thing that is getting the
requests to do the dirty work at the end of a multi-stage preparement. The
function is called: …zp-test-make-targets.

GI
>
> --
> 'Common' Proof Techniques:
> 12. Proof by obfuscation -- A long plotless sequence of true and/or
> meaningless syntactically related statements.
>

>