* detect if compinit was run and rerun @ 2018-06-01 14:58 ` Paul Seyfert 2018-06-01 15:52 ` Peter Stephenson 2018-06-01 17:12 ` Mikael Magnusson 0 siblings, 2 replies; 5+ messages in thread From: Paul Seyfert @ 2018-06-01 14:58 UTC (permalink / raw) To: Zsh Users [-- 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 --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: detect if compinit was run and rerun 2018-06-01 14:58 ` detect if compinit was run and rerun Paul Seyfert @ 2018-06-01 15:52 ` Peter Stephenson 2018-06-01 17:12 ` Mikael Magnusson 1 sibling, 0 replies; 5+ messages in thread From: Peter Stephenson @ 2018-06-01 15:52 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: detect if compinit was run and rerun 2018-06-01 14:58 ` detect if compinit was run and rerun Paul Seyfert 2018-06-01 15:52 ` Peter Stephenson @ 2018-06-01 17:12 ` Mikael Magnusson 2018-06-01 17:46 ` Sebastian Gniazdowski 1 sibling, 1 reply; 5+ messages in thread From: Mikael Magnusson @ 2018-06-01 17:12 UTC (permalink / raw) To: Paul Seyfert; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: detect if compinit was run and rerun 2018-06-01 17:12 ` Mikael Magnusson @ 2018-06-01 17:46 ` Sebastian Gniazdowski 2018-06-14 15:12 ` Paul Seyfert 0 siblings, 1 reply; 5+ messages in thread From: Sebastian Gniazdowski @ 2018-06-01 17:46 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Paul Seyfert, Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: detect if compinit was run and rerun 2018-06-01 17:46 ` Sebastian Gniazdowski @ 2018-06-14 15:12 ` Paul Seyfert 0 siblings, 0 replies; 5+ messages in thread From: Paul Seyfert @ 2018-06-14 15:12 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Mikael Magnusson, Zsh Users [-- 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 > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2018-06-14 15:12 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CGME20180601145937epcas3p38d330847971b65037b3a1596f186f9e9@epcas3p3.samsung.com> 2018-06-01 14:58 ` detect if compinit was run and rerun 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
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).