zsh-workers
 help / color / mirror / code / Atom feed
From: Peter Stephenson <p.w.stephenson@ntlworld.com>
To: zsh-workers@zsh.org
Subject: Re: PATH: autoload with explicit path
Date: Sun, 29 Jan 2017 17:58:15 +0000	[thread overview]
Message-ID: <20170129175815.15366274@ntlworld.com> (raw)
In-Reply-To: <alpine.LRH.2.00.1701290758180.4560@toltec.zanshin.com>

On Sun, 29 Jan 2017 08:11:04 -0800 (PST)
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Consider for example that several of the autoloadable functions in the
> zsh distribution rely on "autoload colors".
> 
> If autoload behaved the way you suggest, this would break, because the
> colors function would not be found at the absolute path from which the
> calling function was loaded -- unless the writer of the calling function
> has used "autoload -d", of course.  But if we're now relying on the
> author to use the correct options for autoload, we're right back where
> we started -- might as well rely on the author to make his function
> suite "relocatable" by way of $function_source as well, and that is
> now possible.
> 
> There's no magic solution that automatically covers all the variations
> without cooperation from both the writer and the installer of the suite.

That's roughly my thinking --- any attempt to magic it gets very messy
very quickly --- and you don't need to.  Here's how it can work.  I
think it puts the onus to do the clever stuff on the function code
writer, which is the right place.

1. User gets a heap of functions and is instructed to put them all in the
same directory (or under the same directory, we have the flexiblity to
make it work with a set of subdirectories).  That's not controversial
anyway, I don't think.

2. User puts:

autoload -Uz /wherever/they/put/it/mainfunc

in their start up.  Note it'll still work if they rely on $fpath ---
mainfunc is resolved when loaded, so the code below still works.  So you
are protected against the user doing anything as long as it's some valid
autoload that works in the version of the shell in us.  No special
instructions are needed.

3. mainfunc contains:

zmodload zsh/parameter
if (( ${+functions_source} )); then
  # If that's available, load by absolute path is available.
  # The -R barfs immediately if the function can't be found
  # (optional extra to simplify error handling).
  # You can add -d if you want to search $fpath, too.
  autoload -RUz ${functions_source[mainfunc]:h}/{other1,other2,other3}
  # ... or whatever.
else
  # We're stuck with old-fashioned fpath.  Add warning, check, whatever.
  autoload other1 other2 other3
fi

This can be tailored to suit.  Any half-baked magic in the shell C
implementation can't.  To repeat, I'm not in any case interested in
doing half-baked magic in the shell C implementation. so let's not
go down that route again.

pws


  parent reply	other threads:[~2017-01-29 17:58 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
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 [this message]
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=20170129175815.15366274@ntlworld.com \
    --to=p.w.stephenson@ntlworld.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).