From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15835 invoked by alias); 2 Oct 2016 15:39:31 -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: 39537 Received: (qmail 18458 invoked from network); 2 Oct 2016 15:39:31 -0000 X-Qmail-Scanner-Diagnostics: from mail-qk0-f172.google.com 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(209.85.220.172):SA:0(0.0/5.0):. Processed in 0.391683 secs); 02 Oct 2016 15:39:31 -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=FREEMAIL_FROM,SPF_PASS, T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: sgniazdowski@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.220.172 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=ZY0G+EAZdGBZbRExjGiJydIoF7fLCvHS8rdg1/0maR0=; b=XvdlTG/1gsi7zfDqCkctKuQ8ZGhcR9S16T67fc6PJqtN/jezkcFkCHkm6+MTO7sGW2 ai3iFIoWi4ta6ng3X3IsQ+3cvGDHHqSFkvRrv75X+g0xAeVKtqCZTNv+z6vZ0lxcj1ko DQDifT0OytT7asQgI/+JosgB6MJthqbl2MoDX4lh47fjffFLmw8fyx6nU8D37xt7LcFX AvLeqZ+Xw/y7TRDQQPCMrUH+HDdKIv/G0U7Kcs4T0lTfuoR07dTuOl2hPlFnjIZS1icY B6xWz99gM4jqp+tW2rZDZNv5n4ctvoQSUjfykhzvNrsDbTYtfoyqtt/S1O6IcWJwlC0T iM/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=ZY0G+EAZdGBZbRExjGiJydIoF7fLCvHS8rdg1/0maR0=; b=lTViBPQ1zgaEwfPqLzbM3wkwS9UY8RtQD9Z+AdYjaLTvsG2GN3PE+KOm8ViHomqgDT uk93AitCXGb7I1yqhvpAH0oB2ASs4Fe0x/gy1Yu5uNE5WMAFcRLdwBj/SGnHYSNdeaWs YGoetRoNdXtM1Jtz7tR/b6nggOPqW9sti4oNa8UA68tyXZ4DyuNwAXDS4gKn7Q7tEcJP A1cUyMGCFJQNBn1dwAvg6PpXIYYZVdtYsqL4hWBYFVazG1m57p93yLM9sOJftbcstABf J6wOgmi0oKjE7aSLj2Xb8LbHm1rwec3dGirDi6xzDOt0TMApUvQgOXvQUOmTs5IqO+X3 zEyQ== X-Gm-Message-State: AA6/9Rn9kJwWpiklQwS6xYvuUxAh+nixjp44OBPY5E1afr12o+iRc7YKb1SITA3hbnKefQEXF6rPEY5RwQExwg== X-Received: by 10.55.151.3 with SMTP id z3mr4874412qkd.321.1475215448824; Thu, 29 Sep 2016 23:04:08 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <160929145022.ZM12459@torch.brasslantern.com> References: <160929001004.ZM27686@torch.brasslantern.com> <160929145022.ZM12459@torch.brasslantern.com> From: Sebastian Gniazdowski Date: Fri, 30 Sep 2016 08:03:48 +0200 Message-ID: Subject: Re: Surprising effect of fun() { local FPATH=...; autoload -X }, and a bug To: Bart Schaefer Cc: Zsh hackers list Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 29 September 2016 at 23:50, Bart Schaefer wr= ote: > On Sep 29, 3:58pm, Sebastian Gniazdowski wrote: > } > } Turns out a normal fpath-extending loading support is needed for > } Zplugin, unless a creative solution is found > > Your autoload wrapper that sets up the "local FPATH" needs to store > the FPATH value for each module somewhere, e.g., in a has indexed > on the module name, and then recall that every time another autoload > occurs from inside a function that was loaded from that module. This would lead to aliases? The autoloaded function would have to have "autoload" calls translated into "zplg_autoload" calls. -U flag causes problems here. Loading function with aliases disabled.. I could use $dis_aliases to disable every alias except for "autoload", and this way in general provide what -U should, however it looks like restoring $dis_aliases will be difficult after autoload -X, because following content of autoload stub will not be run I could also make autoload wrapper continuously active in Zsh session but that doesn't look nice to me. Having fpath-extending loading support in place doesn't mean that clean-FPATH goal will not be reached. Few plugins use autoload -> autoload, so user would have to load via fpath say 2 times, and 10 times via fpath-clean way. Fair enough. And even this might not happen, because author of plugin only has to do all autoloads in plugin.zsh file, not in autoloaded file, to solve the problem. > Whether it's possible to find that the name of the module at the > necessary time, is a harder question. In 5.3 "whence -v" will > reliably give you the path from which the function was loaded, but > it may not in earlier versions. Supporting starting from 5.3 is fine to me in this case. Good to hear about whence -v, this should open way to interesting tricks. Side, I hope there is still some time till 5.3 because I want to make Zconvey more robust, currently if I press Ctrl-R Ctrl-C continuously, rapidly then often happens that every 2 seconds I get beep and new line =E2=80=93 zconvey's 2-second scheduled function is being apparently hit. Plan to get on this with debugger today and to code as you had an idea of how to make this less probable, will check that. Zconvey can be a cool plugin, I currently e.g. switch all my sessions to current project that I work on via "zcm -zz" (zcommodore -z -z, it uses zconvey). Plus the take-session I mentioned and other possible ideas, I think having sessions coupled together can get important say among users. Idea "if you want functionality use latest" is fine to me if it's about sophisticated functionality. So I exercised idea of extending 5.3 to make further-autoloading work. getfpfunc does: pp =3D fpath; for (; *pp; pp++) { and it's about side-providing additional path to that loop. Had multiple flawed ideas yesterday but now I'm rather blank. So maybe actually no idea. Recalling something about if functions do have some sort of meta-data. Then at some point additional fpath could be extracted and provided to getfpfunc. Example problem: the state save-restoration, one more data not serializable via declare -f. Other flawed idea is autoload option to hold single path. It could store the path somewhere so that getfpfunc could use it. But sorry I'm currently not having any actual ideas. Btw. I've stumbled upon following code in execcmd / exec.c:3054: } else if (is_shfunc || type =3D=3D WC_AUTOFN) { Shfunc shf; if (is_shfunc) shf =3D (Shfunc)hn; else { shf =3D loadautofn(state->prog->shf, 1, 0); Is this the place where autoload-marked functions are differentiated from manual-autoload-stub functions? Best regards, Sebastian Gniazdowski