Re: backward-kill-shell-word widget

[Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx>]

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).