detect if compinit was run and rerun

detect if compinit was run and rerun

[Paul Seyfert]

[-- Attachment #1: Type: text/plain, Size: 1197 bytes --]

Dear all,

We are working on a small script that is supposed to be sourced to set
up some environment for a user. I.e. it mostly prepends to PATH,
LD_LIBRARY_PATH, MANPATH, PYTHONPATH, CMAKE_PREFIX_PATH.

For the additional commands, we would also like to provide tab
completions. The plan is atm to have them all in one directory which
would be prepended (appended?) to $fpath.

As far as I see, manipulating $fpath doesn't change the completion
behaviour until `compinit` is run. As far as I know it corresponds the
zsh design to not force completion on the user unless they ask for it,
therefore I don't want to blindly run compinit in the script (if a user
does not call `compinit`, I don't do it for them). On the other hand I
don't want to annoy users with "yes, you already called `compinit` in
your .zshrc, but you need to do it again".

I am therefore wondering if I can detect if `compinit` has already been
called and rerun it if so.

Do you have suggestions how to approach this?



I drafted:

( compdef ) ; [ $? != 127 ] && compinit ;

Ideally I would reuse its settings. I.e. if a user ran `compinit` with
-i or -C originally, our script shouldn't run `compinit` w/o.

Thanks,
Paul

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: detect if compinit was run and rerun

[Peter Stephenson]

On Fri, 1 Jun 2018 16:58:19 +0200
Paul Seyfert <pseyfert.mathphys@gmail.com> wrote:
> I am therefore wondering if I can detect if `compinit` has already
> been called and rerun it if so.

if (( ${+_comps} )): then
  ...
fi

should be good enough in the vast majority of cases.  _comps is only
setup within compinit or by compdef which isn't defined until compinit
runs.  So this only fails if the user is doing something very personal
best kept to the privacy of their own home.

pws

Re: detect if compinit was run and rerun

[Mikael Magnusson]

On Fri, Jun 1, 2018 at 4:58 PM, Paul Seyfert
<pseyfert.mathphys@gmail.com> wrote:
> Dear all,
>
> We are working on a small script that is supposed to be sourced to set
> up some environment for a user. I.e. it mostly prepends to PATH,
> LD_LIBRARY_PATH, MANPATH, PYTHONPATH, CMAKE_PREFIX_PATH.
>
> For the additional commands, we would also like to provide tab
> completions. The plan is atm to have them all in one directory which
> would be prepended (appended?) to $fpath.
>
> As far as I see, manipulating $fpath doesn't change the completion
> behaviour until `compinit` is run. As far as I know it corresponds the
> zsh design to not force completion on the user unless they ask for it,
> therefore I don't want to blindly run compinit in the script (if a user
> does not call `compinit`, I don't do it for them). On the other hand I
> don't want to annoy users with "yes, you already called `compinit` in
> your .zshrc, but you need to do it again".
>
> I am therefore wondering if I can detect if `compinit` has already been
> called and rerun it if so.
>
> Do you have suggestions how to approach this?
>
>
>
> I drafted:
>
> ( compdef ) ; [ $? != 127 ] && compinit ;
>
> Ideally I would reuse its settings. I.e. if a user ran `compinit` with
> -i or -C originally, our script shouldn't run `compinit` w/o.

If you change fpath and then rerun compinit, you are going to cause
zcompdump to be regenerated, ie every startup will do two full
regenerations of the cache instead of 0. Instead, you should not do
that. Just make sure your code that changes fpath is run before the
user runs compinit (by asking the user to configure their shell
correctly). If you absolutely want to add a completer at runtime, it
is probably better to use only compdef+autoload and not compinit. I
don't see any reason why the user would want to avoid having these
completers always configured though.

-- 
Mikael Magnusson

Re: detect if compinit was run and rerun

[Sebastian Gniazdowski]

On 1 June 2018 at 19:12, Mikael Magnusson <mikachu@gmail.com> wrote:
> regenerations of the cache instead of 0. Instead, you should not do
> that. Just make sure your code that changes fpath is run before the
> user runs compinit (by asking the user to configure their shell

If this would be about startup of zsh, I would agree as second
compinit call with $fpath changed adds 820 ms. But for some dynamic
Zsh use with things plugged in and out, compinit should be a good
choice, it is specifically adapted to detect changes (it checks number
of _* files AFAIR?).

> correctly). If you absolutely want to add a completer at runtime, it
> is probably better to use only compdef+autoload and not compinit. I
> don't see any reason why the user would want to avoid having these
> completers always configured though.

Good point, compinit interiors are quite easy to grasp and manual
plugging is possible. For example, this code is generated by Zplugin's
installer:

autoload -Uz _zplugin
(( ${+_comps} )) && _comps[zplugin]=_zplugin

This plugs zplugin completion into already initialized completion
system. I'm doing this because until user organizes his .zshrc, some
time typically passes, and with above, during this time zplugin will
have a working completion. The ${+_comps} check detects if completion
is already initialized.

-- 
Best regards,
Sebastian Gniazdowski

Re: detect if compinit was run and rerun

[Paul Seyfert]

[-- Attachment #1: Type: text/plain, Size: 2267 bytes --]

Hi all,

thanks for your replies

I would like to avoid suggesting users to extend their fpath themselves:
the entire idea of that script we're deploying is there is exactly one
place to pick a version of the software stack, so users do not need to edit
their shell setup, log out&in to switch versions, which we want to enable
them to do after logging in. also our homedirs are shared over different
operating systems …

I appreciate the comment that my idea would hammer zcompdump, I'll try in
any case what the time penalty on our systems is.

Anyway the snippet by Sebastian looks good and seems to do the job.
(And I don't need to worry about users who might call `compinit -u`)

Thanks,
Paul



2018-06-01 19:46 GMT+02:00 Sebastian Gniazdowski <sgniazdowski@gmail.com>:

> On 1 June 2018 at 19:12, Mikael Magnusson <mikachu@gmail.com> wrote:
> > regenerations of the cache instead of 0. Instead, you should not do
> > that. Just make sure your code that changes fpath is run before the
> > user runs compinit (by asking the user to configure their shell
>
> If this would be about startup of zsh, I would agree as second
> compinit call with $fpath changed adds 820 ms. But for some dynamic
> Zsh use with things plugged in and out, compinit should be a good
> choice, it is specifically adapted to detect changes (it checks number
> of _* files AFAIR?).
>
> > correctly). If you absolutely want to add a completer at runtime, it
> > is probably better to use only compdef+autoload and not compinit. I
> > don't see any reason why the user would want to avoid having these
> > completers always configured though.
>
> Good point, compinit interiors are quite easy to grasp and manual
> plugging is possible. For example, this code is generated by Zplugin's
> installer:
>
> autoload -Uz _zplugin
> (( ${+_comps} )) && _comps[zplugin]=_zplugin
>
> This plugs zplugin completion into already initialized completion
> system. I'm doing this because until user organizes his .zshrc, some
> time typically passes, and with above, during this time zplugin will
> have a working completion. The ${+_comps} check detects if completion
> is already initialized.
>
> --
> Best regards,
> Sebastian Gniazdowski
>