* Re: Forgetting about compinit with manual alteration of _comps [not found] <CAKc7PVBLufmR3wLZ8mVGpGq1o1DgB8ci3bH3X6cyzbMyEOoZZg__29303.1625486494$1455013779$gmane$org@mail.gmail.com> @ 2016-02-10 9:23 ` Daniel Shahaf 2016-02-10 10:28 ` Sebastian Gniazdowski 0 siblings, 1 reply; 5+ messages in thread From: Daniel Shahaf @ 2016-02-10 9:23 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Forgetting about compinit with manual alteration of _comps 2016-02-10 9:23 ` Forgetting about compinit with manual alteration of _comps Daniel Shahaf @ 2016-02-10 10:28 ` Sebastian Gniazdowski 2016-02-10 10:32 ` Mikael Magnusson 0 siblings, 1 reply; 5+ messages in thread From: Sebastian Gniazdowski @ 2016-02-10 10:28 UTC (permalink / raw) To: Daniel Shahaf; +Cc: Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Forgetting about compinit with manual alteration of _comps 2016-02-10 10:28 ` Sebastian Gniazdowski @ 2016-02-10 10:32 ` Mikael Magnusson 2016-02-10 11:02 ` Sebastian Gniazdowski 0 siblings, 1 reply; 5+ messages in thread From: Mikael Magnusson @ 2016-02-10 10:32 UTC (permalink / raw) To: Sebastian Gniazdowski; +Cc: Daniel Shahaf, Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Forgetting about compinit with manual alteration of _comps 2016-02-10 10:32 ` Mikael Magnusson @ 2016-02-10 11:02 ` Sebastian Gniazdowski 0 siblings, 0 replies; 5+ messages in thread From: Sebastian Gniazdowski @ 2016-02-10 11:02 UTC (permalink / raw) To: Mikael Magnusson; +Cc: Daniel Shahaf, Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Forgetting about compinit with manual alteration of _comps @ 2016-02-09 10:28 Sebastian Gniazdowski 0 siblings, 0 replies; 5+ messages in thread From: Sebastian Gniazdowski @ 2016-02-09 10:28 UTC (permalink / raw) To: Zsh Users 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2016-02-10 11:03 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CAKc7PVBLufmR3wLZ8mVGpGq1o1DgB8ci3bH3X6cyzbMyEOoZZg__29303.1625486494$1455013779$gmane$org@mail.gmail.com> 2016-02-10 9:23 ` Forgetting about compinit with manual alteration of _comps Daniel Shahaf 2016-02-10 10:28 ` Sebastian Gniazdowski 2016-02-10 10:32 ` Mikael Magnusson 2016-02-10 11:02 ` Sebastian Gniazdowski 2016-02-09 10:28 Sebastian Gniazdowski
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).