zsh-users
 help / color / mirror / code / Atom feed
From: Paul Seyfert <pseyfert.mathphys@gmail.com>
To: Sebastian Gniazdowski <sgniazdowski@gmail.com>
Cc: Mikael Magnusson <mikachu@gmail.com>, Zsh Users <zsh-users@zsh.org>
Subject: Re: detect if compinit was run and rerun
Date: Thu, 14 Jun 2018 17:12:36 +0200	[thread overview]
Message-ID: <CAF=e1ZULezLAkxvdaTE6kGQcL4TUVf4_eL320t-1RqPMh6XJ3A@mail.gmail.com> (raw)
In-Reply-To: <CAKc7PVDNSySnyUb_Q2Vaq2NpCj+4Z+UqQFZ1jfCq6uJFTFGMFQ@mail.gmail.com>

[-- 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
>

      reply	other threads:[~2018-06-14 15: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
2018-06-01 17:46     ` Sebastian Gniazdowski
2018-06-14 15:12       ` Paul Seyfert [this message]

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='CAF=e1ZULezLAkxvdaTE6kGQcL4TUVf4_eL320t-1RqPMh6XJ3A@mail.gmail.com' \
    --to=pseyfert.mathphys@gmail.com \
    --cc=mikachu@gmail.com \
    --cc=sgniazdowski@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).