Zsh Mailing List Archive
Messages sorted by: Reverse Date, Date, Thread, Author

Re: Special _tags:comptags:67: no tags registered

On 28 September 2016 at 08:39, Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
> On Sep 27,  6:40pm, Sebastian Gniazdowski wrote:
> }
> } I've tried debug-printing whole _tags to see differences in path the
> } execution has taken or in parameters, and it was rather the same,
> } couldn't spot any differences. I wonder what is the origin of such
> } error message?
> Remember that "declare -f" for autoloaded functions will dump out a
> definition of the form "_name() { builtin autoload -X }".  There are
> subtle differences between "real" autoloading and autoload -X.  In
> this case, the internals of "comptags" use the depth of the function
> call stack to keep track of which tags are active at which nested
> loop, but the addition of the "autoload -X" wrapper changes the
> call depth.

Thank you very much for the answer. I'm implementing a mechanism to
take other session's state. Via Zconvey, the flocked IDs each sessions
has, I will send:

zc-take-state -n vim2

and obtain whole state of such session. So, a=1, then echo $a in other
session. This will be done via zsnapshot plugin:


There I iterate over $parameters, carefully establish each variable's
type, recreate the variables with full typeset call. Saving and
restoring functions is done via declare -f and it has flaws, thanks
for the explanation it is needed to me to do this correctly! It seems
that I'll be iterating over $functions, parsing first lines to detect
autoload-stubs, then recreate the stubs via autoload call not via
source of function's body. Fair enough. Then comptags should have no
objections? There is apparently other minor flaw of not restoring
emulations that stick to autoload functions, set via the call you once

emulate zsh -c 'autoload compinit'

? Probably no workaround?

Best regards,
Sebastian Gniazdowski

Messages sorted by: Reverse Date, Date, Thread, Author