zsh-users
 help / color / mirror / code / Atom feed
From: Mikael Magnusson <mikachu@gmail.com>
To: Paul Seyfert <pseyfert.mathphys@gmail.com>
Cc: Zsh Users <zsh-users@zsh.org>
Subject: Re: detect if compinit was run and rerun
Date: Fri, 1 Jun 2018 19:12:00 +0200	[thread overview]
Message-ID: <CAHYJk3Tw7MisbkLWujDV-37HfAO9HOqKgzMVkp9z2NFdiBpKRw@mail.gmail.com> (raw)
In-Reply-To: <20180601145818.GC17967@robusta>

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


  parent reply	other threads:[~2018-06-01 17:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CGME20180601145937epcas3p38d330847971b65037b3a1596f186f9e9@epcas3p3.samsung.com>
2018-06-01 14:58 ` Paul Seyfert
2018-06-01 15:52   ` Peter Stephenson
2018-06-01 17:12   ` Mikael Magnusson [this message]
2018-06-01 17:46     ` Sebastian Gniazdowski
2018-06-14 15:12       ` Paul Seyfert

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=CAHYJk3Tw7MisbkLWujDV-37HfAO9HOqKgzMVkp9z2NFdiBpKRw@mail.gmail.com \
    --to=mikachu@gmail.com \
    --cc=pseyfert.mathphys@gmail.com \
    --cc=zsh-users@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).