Re: Forgetting about compinit with manual alteration of _comps

Re: Forgetting about compinit with manual alteration of _comps

[Daniel Shahaf]

Sebastian Gniazdowski wrote on Tue, Feb 09, 2016 at 11:28:10 +0100:
> The bottom line is: a software package providing trivial completions
> can do autoload/_comps alteration to make users happy. If they called
> compinit before – completions will work. If they call compinit after –
> completions will work also. Any nastiness in this?

As far as I know, $_comps is an implementation detail, meaning it may
change incompatibly without notice.  Instead of assigning to $_comps,
you should use 'compdef _mycmd mycmd', which is a stable API.

However, I'm not sure making a plugin loadable _either before or after_
compinit is a good idea.  It may be simpler for plugin authors to expect
to be loaded in one circumstance (say, after compinit) and ensure they
emit a clear error message in the other circumstance (say, before
compinit), than to eternally support two codepaths.

Cheers,

Daniel

Re: Forgetting about compinit with manual alteration of _comps

[Sebastian Gniazdowski]

On 10 February 2016 at 10:23, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> However, I'm not sure making a plugin loadable _either before or after_
> compinit is a good idea.  It may be simpler for plugin authors to expect
> to be loaded in one circumstance (say, after compinit) and ensure they
> emit a clear error message in the other circumstance (say, before
> compinit), than to eternally support two codepaths.

All this is a frustration about "compinit does everything". If there
was "compinit" and "compinit_examine_fpath", it would be all much
simpler. User would init completion at beginning of .zshrc, which is a
natural location for "init" things, and then "compinit_examine_fpath"
at end, which is also natural. All this resolved by providing
compdef() stub gathering compdef calls and allowing to replay them
after compinit placed at bottom of .zshrc.

Best regards,
Sebastian Gniazdowski

Re: Forgetting about compinit with manual alteration of _comps

[Mikael Magnusson]

On Wed, Feb 10, 2016 at 11:28 AM, Sebastian Gniazdowski
<sgniazdowski@gmail.com> wrote:
> On 10 February 2016 at 10:23, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>> However, I'm not sure making a plugin loadable _either before or after_
>> compinit is a good idea.  It may be simpler for plugin authors to expect
>> to be loaded in one circumstance (say, after compinit) and ensure they
>> emit a clear error message in the other circumstance (say, before
>> compinit), than to eternally support two codepaths.
>
> All this is a frustration about "compinit does everything". If there
> was "compinit" and "compinit_examine_fpath", it would be all much
> simpler. User would init completion at beginning of .zshrc, which is a
> natural location for "init" things, and then "compinit_examine_fpath"
> at end, which is also natural. All this resolved by providing
> compdef() stub gathering compdef calls and allowing to replay them
> after compinit placed at bottom of .zshrc.

Another thought is designing a plugin interface designed around how
zsh actually works, rather than bending over backwards to accomodate
cargo culted code that barely works in the first place.

-- 
Mikael Magnusson

Re: Forgetting about compinit with manual alteration of _comps

[Sebastian Gniazdowski]

On 10 February 2016 at 11:32, Mikael Magnusson <mikachu@gmail.com> wrote:
> Another thought is designing a plugin interface designed around how
> zsh actually works, rather than bending over backwards to accomodate
> cargo culted code that barely works in the first place.

That's quite true, sadly. Most of the plugins are written very poorly.
One reason for Zplugin to exist, with the debugging functionalities
that are intended to quickly identify a junk plugin. Other thought is
that writing robust zsh code isn't that simple. Let's forget about
possibility of KSH_ARRAYS, which will break probably all plugins.
There are other robustness-demanding options like GLOB_SUBST, where
simple echo ${fg_bold[red]}"Hello"$reset_color will cause problems. I
would create a list of options that would be repeated loudly for green
Zsh programmers. Not that I knew all this myself always, only recently
I discovered that SH_GLOB disables parentheses at parse time. The
point is that flexibility of Zsh can be converted into quality control
tool. Let fresh programmers know just few options (KSH_ARRAYS,
GLOB_SUBST, SH_GLOB, POSIX_IDENTIFIERS, that's only four) and they
will write better code regardless of their will. Plus patterns, which
will allow to leave ABS scripting that utilizes sed, etc. Of course,
this results in {} being all over the place, around
${#every_identifier}, etc. But not quite, when one writes plugin he
can use setopt localoptions and configure zsh according to his needs.
Exposed code would have {} everywhere, resulting in whole
/usr/share/functions/* working with emulate sh.

Best regards,
Sebastian Gniazdowski

Forgetting about compinit with manual alteration of _comps

[Sebastian Gniazdowski]

Hello,
one calls compinit in .zshrc and then loads something that adds to
$fpath having intention of providing a completion. User is puzzled as
completion doesn't work, has to take care of having compinit placed at
say bottom of .zshrc.

Turns out the loading could be followed by:

    autoload -Uz _mycmd
    _comps[mycmd]=_mycmd

and that sets things working, mycmd is correctly completed. This works
for trivial #compdefs, don't know what side effects can non-trivial
#compdefs have.

The bottom line is: a software package providing trivial completions
can do autoload/_comps alteration to make users happy. If they called
compinit before – completions will work. If they call compinit after –
completions will work also. Any nastiness in this?

Best regards,
Sebastian Gniazdowski