zsh-workers
 help / color / mirror / code / Atom feed
From: Sebastian Gniazdowski <psprint2@fastmail.com>
To: zsh-workers@zsh.org
Subject: Re: PATH: autoload with explicit path
Date: Fri, 27 Jan 2017 10:40:15 -0800	[thread overview]
Message-ID: <1485542415.1037033.861766968.196E6FB9@webmail.messagingengine.com> (raw)
In-Reply-To: <20170127162440.10a5c85b@pwslap01u.europe.root.pri>

On Fri, Jan 27, 2017, at 08:24 AM, Peter Stephenson wrote:
> On Fri, 27 Jan 2017 07:12:59 -0800
> Sebastian Gniazdowski <psprint2@fastmail.com> wrote:
> > I do the non-fpath autoloading by local FPATH parameter. There's
> > drawback: if autoloaded function does further autoloading of other
> > function, then the earlier supplied local FPATH parameter isn't active
> > anymore.
> > 
> > So it's not possible to have /home/user/functions/{fun1,fun2}, autoload
> > fun1, and have fun2 available for fun1. Now, with the new feature,
> > directory path can be attached to function and if it calls autoload
> > itself, then the attached directory can be examined before FPATH.
> 
> You're worried about something like this?
> 
> 
> # set up function
> local path_that_only_appears_here=/foo/bar
> autoload -Uz $path_that_only_appears_here/fun1
> 
> 
> # definition of fun1
> autoload -Uz <what-goes-here?>/fun2
> fun2
> 
> 
> You can already do this using funcsourcetrace from zsh/parameter:
> ${funcsourcetrace[1]%%:<->} is the source file for the immediately
> enclosing scope, so take the directory part of that and you've
> got what you want (being careful if you happen to have evals
> or anonymous functions which generate their own scopes).

Internally via autoload it will be easy to create custom versions of
multiple functions. For example calendar does:

autoload -Uz calendar_{add,parse,read,scandate,show,lockfiles}

With the requested feature, I can copy any subset of above functions to
/home/user/functions, and "autoload -Uz /home/user/functions/calendar"
will pull them. This is also possible by prepending FPATH with
/home/user/functions, true. But deciding whether I want to pull in
custom calendar or not via FPATH management or by removing calendar*
files is hard. The new feature will be very convenient if user will have
multiple directories, for example a second one /home/user/new_functions.
To choose from where to pull in the calendar will be to simply change
path to it in autoload call.

So in .zshrc there will be:

# My custom calendar
autoload -Uz /home/user/functions/calendar

and that's it, no FPATH management or removing files from
/home/user/functions (to revert to official calendar, if the directory
is in FPATH).

> It's a bit limiting you can't get that information for any function,
> since it's alrady available internally in the shfunc structure.  I'd be
> happy to add an associative array in zsh/parameter parallel to
> $functions, say $function_sources, that gives the information for all
> functions.

Sounds nice, though it's nice that current implementation of the
absolute-path feature uses pointers to paths to limit memory usage, a
new parameter would probably spend that.

-- 
Sebastian Gniazdowski


  reply	other threads:[~2017-01-27 18:40 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20170127151334epcas2p4c32b57f69fcae22b40b309793eb8ceb6@epcas2p4.samsung.com>
2017-01-27 15:12 ` Sebastian Gniazdowski
2017-01-27 16:24   ` Peter Stephenson
2017-01-27 18:40     ` Sebastian Gniazdowski [this message]
2017-01-27 18:44       ` Peter Stephenson
2017-01-27 19:00         ` Sebastian Gniazdowski
2017-01-28 18:05         ` Bart Schaefer
2017-01-28 19:12           ` Peter Stephenson
2017-01-28 19:45             ` Bart Schaefer
2017-01-28 19:56               ` Peter Stephenson
2017-01-28 20:37                 ` Sebastian Gniazdowski
2017-01-29 12:27             ` Sebastian Gniazdowski
2017-01-29 16:11               ` Bart Schaefer
2017-01-29 17:32                 ` Sebastian Gniazdowski
2017-01-29 18:37                   ` Bart Schaefer
2017-01-29 21:53                     ` Vin Shelton
2017-01-30 10:06                       ` Peter Stephenson
2017-01-29 17:58                 ` Peter Stephenson
2017-01-30 11:37                   ` Sebastian Gniazdowski
2017-01-30 11:55                     ` Peter Stephenson
2016-12-11 22:18 Peter Stephenson
2016-12-12 16:05 ` Bart Schaefer
2016-12-12 16:31   ` Peter Stephenson
2016-12-12 18:09     ` Bart Schaefer
2017-01-10 19:31     ` Peter Stephenson
2017-01-11 11:42       ` Peter Stephenson
2017-01-11 20:51         ` Peter Stephenson
2017-01-12 20:42           ` Peter Stephenson
2017-01-13 18:04           ` Peter Stephenson
2017-01-16 10:37             ` Peter Stephenson
2017-01-16 15:04               ` Daniel Shahaf
2017-01-16 15:48                 ` Peter Stephenson
2017-01-16 15:22               ` Bart Schaefer
2017-01-16 15:59                 ` Peter Stephenson
     [not found]                   ` <CAHYJk3SB1NDj6y5TRHHsAVsyjHfZQhTzMRzTR2c-SVEc9oAwzA@mail.gmail.com>
2017-01-24 11:10                     ` Peter Stephenson
2017-01-11 21:13         ` Peter Stephenson

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=1485542415.1037033.861766968.196E6FB9@webmail.messagingengine.com \
    --to=psprint2@fastmail.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).