From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14110 invoked by alias); 27 Apr 2017 15:54:09 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 41017 Received: (qmail 27300 invoked from network); 27 Apr 2017 15:54:08 -0000 X-Qmail-Scanner-Diagnostics: from aok120.rev.netart.pl by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(85.128.245.120):SA:0(0.0/5.0):. Processed in 2.30798 secs); 27 Apr 2017 15:54:08 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: psprint@zdharma.org X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: none (ns1.primenet.com.au: domain at zdharma.org does not designate permitted sender hosts) X-Virus-Scanned: by amavisd-new using ClamAV (15) Date: Thu, 27 Apr 2017 17:43:54 +0200 From: Sebastian Gniazdowski To: zsh-workers@zsh.org Message-ID: Subject: Re: off topic X-Mailer: Airmail (231) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Hello, I've stumbled upon this 2016 post from Oliver. It is attached at the end.= Let me share my 2-3 year experience about plugins: - Plugin is: name.plugin.zsh sourced, =240:h added to =24fpath. So autoload functions will work and also completions, too. Such plugin ma= nager will be very compact: a hopefully flexible git cloning code + sourc= ing. The new 5.3.1-dev-0 functionality can be used to skip =24fpath changes: a= utoloads via absolute paths. To do this, autoload() function to shadow th= e builtin should be added before sourcing, and it would catch user's auto= load, and prepend =240:h. That's it. Nested, post-sourcing autoloads (i.e= . catched =22autoload X=22 from plugin.zsh, uncatched from within functio= n X, at runtime) will work with the 5.3.1-dev-0 functionality. It might sound heavy, but I shadow multiple things in Zplugin: zle, zstyl= e, bindkey, autoload, compdef and no problems occurred and no reports abo= ut this. - Then goes the hidden truth about plugins, not easily discovered: plugin= s can call compdef, so compinit should be in place already (it defines co= mpdef), but plugins extend =24fpath. Solution in Zplugin: compdefs are saved via shadowing compdef() function,= and =22zplugin cdreplay=22 command is provided for user, to be ran after= he calls compinit, which is expected to be after all Zplugin invocations= . Solution in OMZ: plugins are given via array. OMZ can make all =24fpath c= hanges and invoke compinit before sourcing plugins, so compdef is ready t= o use for the plugins when sourcing them. Possible solution: =22zplugin load=22-like call should append to some arr= ay, with some possible options, and then =22plug apply=22 call would be e= xpected from user, that would do =24fpath changes, compinit and whole sou= rcing. That said, compdef shadowing is really nice looking and working th= ing, and it doesn't hide compinit somewhere in plugin manager. - Small thing: plugins can be compiled at install, I do this from 1 year = now with Zplugin, and no problems are reported. That said, other people a= re maybe able to squeeze milliseconds from this (heard that), but I saw n= o changes in loading time. Now set of things that I plan for Zplugin after observing things for 1.4 = year. I don't propose Zplugin because it's little verbose (but still rath= er fastest out there) with the reporting feature. - I observed a trend to make plugin manager a swiss-knife. If you look at= the first factoid I gave, then plugin manager is just clone+source. Howe= ver, the swiss-knife trait can uplift this not-great state. - Zplugin has =22snippet=22 command, it kinda shows what's this is about:= it creates directory that encodes url of a remote file: github--DOT--com--SLASH--robbyrussell--SLASH--oh-my-zsh--SLASH--blob--SLA= SH--master--SLASH--lib--SLASH--git.zsh then downloads the file into this directory, and sources it. This allows = to use 99% of OMZ plugins without bloating code with OMZ-specific stuff, = because 99% of plugins there are single file without autoloads. =46ollowi= ng =22snippet=22 commands will skip downloading. Note the advantage that = this creates. You can easily update the snippet, hook it to remote locati= on =E2=80=93 a swiss-knife like thing resulting from simple concept. - Such simple concepts allow clever zshrc. =46or example, how to load thi= s non-plugin:=C2=A0https://github.com/trapd00r/LS=5FCOLORS =3F A Zplugin = user did: zplugin load trapd00r/LS=5FCOLORS LS=5FCOLORS=5FDIR=3D=24ZPLG=5FPLUGINS=5FDIR/trapd00r---LS=5FCOLORS if =5B=5B =21 =24LS=5FCOLORS=5FDIR/LS=5FCOLORS.plugin.zsh -nt =24LS=5FCOL= ORS=5FDIR/LS=5FCOLORS =5D=5D; then dircolors -b =24LS=5FCOLORS=5FDIR/LS=5FCOLORS > =24LS=5FCOLORS=5FDIR/LS=5F= COLORS.plugin.zsh zplugin compile trapd00r/LS=5FCOLORS source =24LS=5FCOLORS=5FDIR/LS=5FCOLORS.plugin.zsh fi So he has single dircolors call in case of update, which is a serious ass= et, as author proposed doing =22eval =24( dircolors -b =24HOME/LS=5FCOLOR= S )=22, i.e. a fork, and eval usage probably slightly slower than source.= So, a swiss-knife could be added for such fancy sourcing, that would be = better than the =22create plugin.zsh on -ot=22 user-side solution above. - Such swiss-knife are also =22hook-build=22 and =22hook-load=22 in zplug= /zplug (other plugin manager), which specify code to be ran after install= /update and after loading. - I can think of: option to trigger =22git reset --hard HEAD=22 before up= date, and also doing =22hook-build=22 that modifies or removes files. Com= pare this to normal zshrc management of things. - =22if=22 option, that would test =22=5B=5B some =3D condition =5D=5D=22= , and decide to load the plugin I think this can be approached as tools for any not-conforming thing on g= ithub. - One last thing =E2=80=93 all my plugins do: if =5B=5B -z =22=24ZPLG=5FCUR=5FPLUGIN=22 && -z =22=24=7Bfpath=5B(r)=24MY= =5FREPO=5FDIR=5D=7D=22 =5D=5D; then =C2=A0 =C2=A0 fpath+=3D( =22=24MY=5FREPO=5FDIR=22 ) fi Basically, as it can be seen, plugin managers can be skipped because plug= in can correctly manage =24fpath itself. The official plugin manager coul= d create standard=C2=A0=24ZPLG=5FCUR=5FPLUGIN analogue, I would switch Zp= lugin to that standard parameter (indicating that plugin manager is activ= e and no self-management of =24fpath is needed). Sebastian On 10 Dec 2016 at 03:50:26, Oliver Kiddle wrote: Rather than a source-able file, would it perhaps make sense to embrace the concept of plugins. It's a concept that people are familiar with from other software. With vim for example, it is common to have a list in .vimrc, e.g: =C2=A0 call plug=23begin('=7E/.vim/plugged') =C2=A0 Plug 'surround.vim' =C2=A0 Plug 'tommcdo/vim-exchange' =C2=A0 ... The various existing zsh plugin managers are similar. One well known plugin named sensible.vim is similar to what you posted: defaults everyone can agree on. I think it also tends to result in better maintained plugins when people keep their own plugin in their own github area vs. an omz pull request and then assuming that the omz people will look after it thereafter. As a first step, we could add an Etc/plugin-guide file to outline conventions such as how structure a plugin, use of add-zsh-hook, how to avoid trampling on the rest of the user's setup. default=5Fzstyle could perhaps be included in Misc (or added as an option to zstyle). Name of path variable which is used when searching for plugins, etc. The omz convention seems to be a single file with the extension .plugin.zsh which is sourced but there may be more to it than that. We also need to think about the order in which commands are run. We could include a rudimentary plugin manager. So people would do something like: =C2=A0 autoload -U pluginit; pluginit =C2=A0 plug zsh-syntax-highlighting =C2=A0 plug zsh-viexchange Or they could continue using zplugin or whatever else if they want fancy features like coloured github updates. And if we've kept things simple, it could work to just source a single file for a plugin. =46inally, we could include the odd plugin in the distribution for anything which could be considered fairly core - such as the sensible defaults plugin. -- Sebastian Gniazdowski psprint /at/ zdharma.org