Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
From: Bart Schaefer <schaefer@brasslantern.com>
Message-Id: <160113225402.ZM14484@torch.brasslantern.com>
Date: Wed, 13 Jan 2016 22:54:02 -0800
In-Reply-To: <20160114001341.GA4698@tarsus.local2>
Comments: In reply to Daniel Shahaf <d.s@daniel.shahaf.name>
        "Re: backward-kill-shell-word widget" (Jan 14, 12:13am)
References: <CAKc7PVAgH7YOD+Q0wo2iO0-tOGKbHNpuK=OCTs7WG_YJUbGyVg@mail.gmail.com> 
	<CAKc7PVA2iY4rzcaCmt_Tt0huhQA7O5vyiQ3UWLk_OC=CiC=s1g@mail.gmail.com> 
	<20160113011850.GC2736@tarsus.local2> 
	<CAKc7PVB8=7Z5jU31Brpb1YW6MGZeB7e+VmpE038ZrOicn=bEVA@mail.gmail.com> 
	<20160114001341.GA4698@tarsus.local2>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: backward-kill-shell-word widget
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

On Jan 14, 12:13am, Daniel Shahaf wrote:
}
} Perhaps that has something to do with the fact that the zsh default
} setup is rather minimal: no cwd in PS1, no history tracking, etc..

I've been noodling about with a set of default styles to set for
compsys, not (obviously) to be incorporated into the C code but to
be distributed as a source-able (or potentially autoloadable) file.
It would replace the zstyle stuff at the end of StartupFiles/zshrc.

} (Actually, with StartupFiles/zshrc, I can't get even "rsync --<TAB>" to
} work, even though it calls compinit.)

That's interesting.  It works for me.  Had you noticed that there is a
"return 0" at the very top of StartupFiles/zshrc that you must edit out?

} So one of the things a "plugin infrastructure" could do is standardise
} a documentation format, so if you had N plugins installed, each plugin
} could register the styles and parameters it cares about, and then you
} could look them up, or enumerate them, in a unified way.

Of course the original example for this is the prompt themes system,
where each file name follows a pattern and each file defines functions
that also are conventionally named, which includes a "help" function.

This could probably be improved upon.

As for Sebastian's grumble about "flooding $fpath" ... there's really
no [default] way to avoid using fpath entries without populating the
shell process memory with a full function definition.  As is often
the case, the problem is bootstrapping -- first a hook to the plugin
has to be found in some standard place, and then that hook informs
how the rest of the plugin is found.  $fpath is the well-known way
to identify all of those places.

There is a sort of workaround; instead of

    fpath=(/path/to/the/plugin $fpath)
    autoload some_function_from_plugin

the plugin initializer might instead do

    function some_function_from_plugin {
	local FPATH=/path/to/the/plugin
	autoload -X
    }

This wastes some space in the function definition (a value for FPATH
is stored in every "not yet defined" function), but it avoids putting
anything in the global $fpath and it guarantees the function is loaded
from the same place regardless of $fpath order (one of Ray's bugaboos
from last summer).

However, you still have to bootstrap before these functions can exist;
so there at least has to be a single fpath entry where all the plugins
agree to deposit their equivalent of "promptinit" (or where the user
of the plugin is instructed to put a link to that, or whatever).