zsh-workers
 help / color / mirror / Atom feed
* info completion doesn't offer index entries any longer
@ 2021-08-01 16:05 Stephane Chazelas
  2021-08-01 16:24 ` Stephane Chazelas
  0 siblings, 1 reply; 5+ messages in thread
From: Stephane Chazelas @ 2021-08-01 16:05 UTC (permalink / raw)
  To: Zsh hackers list

Hello,

I'm pretty sure zsh used to offer completion for index entries
so you could do "info zsh read<Tab>" for instance to see the
index entry for the "read" builtin among other things, but that
no longer works.

I noticed that the completer runs "info -k" which is not a valid
command which points to the obvious:

_call_program info-nodes $cmd -k ''

mistake in the code which should be:

_call_program info-nodes "$cmd -k ''"

Or possibly 

_call_program info-nodes "${(qq)cmd} -k ''"

as those _call_program arguments are interpreted as shell code
to evaluate, not a list of arguments making up a simple command,
but even after that fixed (which causes the completion to be
very slow on my system as

$ info -k '' | wc
47919  267467 2341131
), 
That still doesn't give me index entries. Same with

info zsh --index-search=<Tab>

info has its own completion for the index with "i", and even "I"
for a selectable search result, so not having it in zsh is not
critical, but it sounds like it's meant to be there, but just
broken atm.

-- 
Stephane


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: info completion doesn't offer index entries any longer
  2021-08-01 16:05 info completion doesn't offer index entries any longer Stephane Chazelas
@ 2021-08-01 16:24 ` Stephane Chazelas
  2021-08-05  7:53   ` Oliver Kiddle
  0 siblings, 1 reply; 5+ messages in thread
From: Stephane Chazelas @ 2021-08-01 16:24 UTC (permalink / raw)
  To: Zsh hackers list

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
> 
> $ info -k '' | wc
> 47919  267467 2341131
> ), 
> That still doesn't give me index entries. Same with
[...]

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).

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.

-- 
Stephane


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: info completion doesn't offer index entries any longer
  2021-08-01 16:24 ` Stephane Chazelas
@ 2021-08-05  7:53   ` Oliver Kiddle
  2021-08-08 15:58     ` Stephane Chazelas
  0 siblings, 1 reply; 5+ messages in thread
From: Oliver Kiddle @ 2021-08-05  7:53 UTC (permalink / raw)
  To: Zsh hackers list

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: info completion doesn't offer index entries any longer
  2021-08-05  7:53   ` Oliver Kiddle
@ 2021-08-08 15:58     ` Stephane Chazelas
  2021-08-09 13:36       ` Oliver Kiddle
  0 siblings, 1 reply; 5+ messages in thread
From: Stephane Chazelas @ 2021-08-08 15:58 UTC (permalink / raw)
  To: Oliver Kiddle; +Cc: Zsh hackers list

2021-08-05 09:53:23 +0200, Oliver Kiddle:
[...]
> > > $ 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.

Most of those are from a dozen of info manuals:

$ info -k '' | grep -Po '^"\(\K[^)]*' | uniq -c | sort -rn | pr -t3
   4979 gcc                 650 kpathsea            179 diffutils
   4820 libc                501 flex                177 gawkinet
   4143 gcal                500 nettle              158 datamash
   3641 gdb                 479 bash                150 rcs
   2740 zsh                 463 autogen             105 find
   2682 gawk                409 info-stnd           103 grub
   2679 coreutils           372 tlbuild              86 stabs
   2500 groff               355 m4                   51 libffi
   2437 gnulib              353 sed                  51 history
   1975 texinfo             336 readline             51 gperf
   1356 recode              325 screen               15 cpio
   1316 gettext             271 texi2html             8 time
   1157 automake-1          269 ssed                  8 texinfo
    843 tar                 268 grep                  8 gzip
    809 gnupg               247 mtools                5 ssip
    806 web2c               231 wget                  1 grub-dev
    792 cvs                 192 gawkworkflow          1 gawk
    680 dvips               186 speech-dispatch

(not sure why there should be only one entry for gawk for
instance though).

[...]
> I think that method only retrieves the menu for the top level of the
> manual. It makes more difference with some documentation than others.

You're right, I was too quick to jump to conclusions.

> There is no actual attempt to complete anything for --index-search=
> What do you think we should do there?

Well, I was hoping zsh would give me similar completion as
info's i would.

$ info -k '' | grep -iPo '^"\Q(zsh)\E.*" -- \Kread' | sort -u
read
READ

That's not the same as what info i completion gives me on "read" though:

8 completions:
read                         read-from-minibuffer         READNULLCMD                  READNULLCMD, ignoring <1>
read-command                 reading a line               READNULLCMD, ignoring        READNULLCMD, use of

I must have misunderstood what info -k does.

Doing the same as i's completion may require parsing the contents of the info
file directly.


> > 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.
[...]

What I mean is that I'd expect info -k '' would only need to be
run once within a single interactive zsh session. When I
instrument it with

info() { echo info called>/dev/tty; command info "$@";}

I can see info being called each time I complete info zsh something<Tab> for
instance.

-- 
Stephane


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: info completion doesn't offer index entries any longer
  2021-08-08 15:58     ` Stephane Chazelas
@ 2021-08-09 13:36       ` Oliver Kiddle
  0 siblings, 0 replies; 5+ messages in thread
From: Oliver Kiddle @ 2021-08-09 13:36 UTC (permalink / raw)
  To: Zsh hackers list

Stephane Chazelas wrote:
> > There is no actual attempt to complete anything for --index-search=
> > What do you think we should do there?
>
> Well, I was hoping zsh would give me similar completion as
> info's i would.
 ...
> Doing the same as i's completion may require parsing the contents of the info
> file directly.

We may be able to use the search for an empty string approach again,
e.g. info -o- --all --index-search='' zsh

The patch below tries that. You need to specify the manual first before
--index-search but for 'read' in the zsh manual I get a similar list to
the i command in info.

We could perhaps drop the info -k '' method in favour of this - would
need to compare results for a variety of info pages. In the patch here,
I've made it include in the part to the right of " -- " too so it is
generating more matches including the "info zsh read" case we started
with.

> What I mean is that I'd expect info -k '' would only need to be
> run once within a single interactive zsh session. When I
> instrument it with
>
> info() { echo info called>/dev/tty; command info "$@";}
>
> I can see info being called each time I complete info zsh something<Tab> for
> instance.

In my testing, it is running info -o- zsh each time but not the much
slower info -k ''
If you include "$@" in your instrumentation function are you able to
confirm that?
This is because both menu and index items are allowed.

Oliver

diff --git Completion/Unix/Command/_texinfo Completion/Unix/Command/_texinfo
index 2122a70ad..526a595a8 100644
--- Completion/Unix/Command/_texinfo
+++ Completion/Unix/Command/_texinfo
@@ -37,14 +37,14 @@ local -A opt_args infodirs
 case $service in
   info)
     cmd=${words[1]}
-    _arguments -C -s \
+    _arguments -C -s -S \
       '(-a --all)'{-a,--all}'[use all matching manuals]' \
       '(: -)'{-k+,--apropos=}'[look up string in indices]:search string: ' \
       \*{-d+,--directory=}'[add directory to infopath]:info dir:_files -/' \
       '--dribble=[record keystrokes]:file with keystrokes:_files' \
       '(-f --file 1)'{-f+,--file=}'[specify Info manual to visit]:info manual:->infofiles' \
       '(: - -h --help)'{-h,--help}'[display usage]' \
-      '(-o --output -O)--index-search=[go directly to node if found]:search string: ' \
+      '(-o --output -O)--index-search=[search for matching index entry]:search string:->index-entries' \
       '(--index-search -o --output -O)'{-o+,--output=}'[dump selected nodes to filename]:filename:_files -g "*(-.)"' \
       '--init-file=[specify initialisation file]:file:_files' \
       '(-n --node)'{-n+,--node=}'[specify nodes in first visited Info file]:node:->nodes' \
@@ -302,6 +302,13 @@ if [[ -n $state ]]; then
       tags+=( info-nodes )
     fi
     items=( ${${${(M)${(f)"$(_call_program menu-items info -o- $file)"}:#(#s)\* *::*}%%::*}#??} )
+  elif [[ $state = index-entries ]]; then
+    if [[ -n $file ]]; then
+      tags=( index-entries )
+      items=( ${${${(M)${(f)"$(_call_program index-entries info -o- --all --index-search= $file)"}:#(#s)\* *:*}%%:*}#??} )
+    else
+      _message -e index-entries $state_descr
+    fi
   fi
 
   _tags $tags
@@ -309,6 +316,7 @@ if [[ -n $state ]]; then
   while _tags; do
     _requested info-files expl 'info file' compadd $suf -M 'm:{a-zA-Z}={A-Za-z}' -a files && ret=0
     _requested menu-items expl 'menu item' compadd -M 'm:{a-zA-Z}={A-Za-z}' -a items && ret=0
+    _requested -x index-entries expl 'index entry' compadd -M 'm:{a-zA-Z}={A-Za-z}' -a items && ret=0
     _requested info-nodes expl 'node' compadd -M 'm:{a-zA-Z}={A-Za-z}' ${nodes#*:} && ret=0
 
     (( ret )) || break


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-08-09 13:37 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-01 16:05 info completion doesn't offer index entries any longer Stephane Chazelas
2021-08-01 16:24 ` Stephane Chazelas
2021-08-05  7:53   ` Oliver Kiddle
2021-08-08 15:58     ` Stephane Chazelas
2021-08-09 13:36       ` Oliver Kiddle

zsh-workers

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://inbox.vuxu.org/zsh-workers

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 zsh-workers zsh-workers/ https://inbox.vuxu.org/zsh-workers \
		zsh-workers@zsh.org
	public-inbox-index zsh-workers

Example config snippet for mirrors.
Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


code repositories for the project(s) associated with this inbox:

	https://git.vuxu.org/mirror/zsh/

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git