Hi,
On 2018-05-15 00:09, Frank Terbeck wrote:
Axel Beckert wrote:
Philipp Kern wrote:
[...]
My gut feeling is that this is because I did not autocomplete in the
old shell yet but now the module is gone.
Yes, that's the same conclusion I came to.
At least with a new shell complist.so is only in /proc/$$/maps after
an attempted completion.
Yes, modules are loadable at run-time.
Would it be possible to make sure that the autocompletion system
loads the module on startup rather than on-demand?
Zsh is setup to do lots of things on demand. It would certainly
be
conceivable to be more gracious about the issue. But when
versions
upgrade, I don't think it's unreasonable to restart a shell, like
Axel
mentioned via "exec zsh".
If you'd really like that module loaded all the time, you can load it
in
your setup. Personally, I'm loading a bunch of modules at startup time.
I'm caring about a large setup rather than a personal installation,
though, which sort of shifts as to what's reasonable and what isn't. ;-)
Let's say I'm using /etc/zsh/newuser.zshrc.recommended (which is
actually what I'm using verbatim). Could we at least fix it for that
configuration? That one does this:
| # Use modern completion system
| autoload -Uz compinit
| compinit
/usr/share/zsh/functions/Completion/compinit does not invoke "zmodload
-i zsh/complist" whereas the first invocation of the completion menu
would. How bad would it be to add the module loading to the
initialization? Is there a benefit to not doing that specific call on
startup? The module itself is a 63k .so file.
In a very non-scientific test I get a VM increase from 37076 kB -> 43968
kB (+18%), anon pages from 1840 -> 2148 kB (+16%) and file pages from
3912 -> 4508 kB (+15%) on amd64 when running a full completion for
l<tab> on my system. And that loads even more than just the module,
because it goes through the whole setup.
I mean sure, I could add a zmodload call to our system-wide config. But
I'd rather we solve this problem for all of Debian's users rather than
just us. (This is assuming that people are on some variant of a rolling
testing and don't reboot their machines all the time after updates -
which currently violates other Debian assumptions like the kernel's as
well.)
Kind regards and thanks for your consideration
Philipp Kern
