Special _tags:comptags:67: no tags registered

Special _tags:comptags:67: no tags registered

[Sebastian Gniazdowski]

Hello,
I do uncommon thing: in a very fresh shell – no Tab yet used, right
after start, in one line:

declare -f > functions; unfunction -m \*; source ./functions

Then I enter ls<Tab>, and get:

_tags:comptags:67: no tags registered

The line pointed (5.2-dev-2) is last line in the file _tags:

comptags "-N$prev"


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?

Best regards,
Sebastian Gniazdowski

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

[Bart Schaefer]

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.

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

[Sebastian Gniazdowski]

On 28 September 2016 at 08:39, Bart Schaefer <schaefer@brasslantern.com> 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:

https://github.com/psprint/zsnapshot/blob/master/__zsnapshot

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
showed:

emulate zsh -c 'autoload compinit'

? Probably no workaround?

Best regards,
Sebastian Gniazdowski

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

[Bart Schaefer]

On Sep 28,  9:05am, Sebastian Gniazdowski wrote:
}
} 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

Or you could use "zcompile -acm stubfile \*" and then read it in the
other shell with "autoload -w stubfile.zwc".

} There is apparently other minor flaw of not restoring
} emulations that stick to autoload functions

I believe that's true, yes -- though I haven't checked / don't recall
whether zcompile saves the sticky emulation.