From: Oliver Kiddle <opk@zsh.org>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: info completion doesn't offer index entries any longer
Date: Thu, 05 Aug 2021 09:53:23 +0200 [thread overview]
Message-ID: <26560-1628150003.918228@jgeh.uisY.RfGy> (raw)
In-Reply-To: <20210801162439.nfs6b7v6i2c6luqw@chazelas.org>
On 1 Aug, Stephane Chazelas wrote:
> 2021-08-01 17:05:47 +0100, Stephane Chazelas:
> [...]
> > but even after that fixed (which causes the completion to be
> > very slow on my system as
That fix is needed. It looks like _call_program got added in without
further testing (or a cache obscured the breakage in testing). Feel free
to push the fix you described to the git repo.
> >
> > $ info -k '' | wc
> > 47919 267467 2341131
You clearly have vastly more on your system than I have. I would guess
that among that extra output is an entry or entries that need additional
quoting or something and are breaking _describe - colons perhaps.
> > That still doesn't give me index entries. Same with
There is no actual attempt to complete anything for --index-search=
What do you think we should do there?
> Actually, (once fixed) it does seem to work as intended in that
> it only uses the output of "info -k ''" to build a list of info
> nodes that are referenced in index entries, not the index
> entries themselves.
>
> That seems to be redundant with the parsing of info -o- that the
> completer does otherwise to retrieve the list of nodes (and
> which is much faster as it only covers the one manual the user
> is querying completion for).
I think that method only retrieves the menu for the top level of the
manual. It makes more difference with some documentation than others.
> Evidence of that is that fixing that "info -k" to intended "info
> -k ''" doesn't seem to change much if at all the behaviour (but
> makes the completion significantly slower).
>
> Also, caching doesn't seem to work properly as "info -k ''"
> seems to be invoked every time.
It does appear to work in my testing. Does the cache variable get set in
your case? Again, I suspect something peculiar to the longer info -k ''
output on your system is causing issues for the basic nested parameter
expansion that parses the output.
Oliver
next prev parent reply other threads:[~2021-08-05 7:54 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-01 16:05 Stephane Chazelas
2021-08-01 16:24 ` Stephane Chazelas
2021-08-05 7:53 ` Oliver Kiddle [this message]
2021-08-08 15:58 ` Stephane Chazelas
2021-08-09 13:36 ` Oliver Kiddle
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=26560-1628150003.918228@jgeh.uisY.RfGy \
--to=opk@zsh.org \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).