zsh-workers
 help / color / mirror / code / Atom feed
* exposing completions data to user
@ 2016-10-18  0:06 Ben Veal
  2016-10-18 14:50 ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Veal @ 2016-10-18  0:06 UTC (permalink / raw)
  To: zsh-workers

Hi,
   I want to write a zaw plugin
   (https://github.com/zsh-users/zaw) for
   performing completions, matching on both
   completions and descriptions. 

   To do this I need access to the list of possible
   completions and their descriptions.
   As far as I can determine, this information is not
   normally available, and so I need to write a module
   which exposes this data.
   
   I had a look at the complist module code, and it
   seems that information is passed into domenuselect
   in a pointer to a chdata structure. However, when I
   tried stepping through the code with gdb, I
   couldn't find the completions data.
   Can anyone help?

Ben


-- 
 


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

* Re: exposing completions data to user
  2016-10-18  0:06 exposing completions data to user Ben Veal
@ 2016-10-18 14:50 ` Bart Schaefer
  2016-10-25  4:16   ` Ben Veal
  0 siblings, 1 reply; 4+ messages in thread
From: Bart Schaefer @ 2016-10-18 14:50 UTC (permalink / raw)
  To: zsh-workers

On Oct 18,  1:06am, Ben Veal wrote:
}
}    To do this I need access to the list of possible
}    completions and their descriptions.
}    As far as I can determine, this information is not
}    normally available

This is what the -O -A and -D options of the compadd builtin are meant
to accomplish.  Are you capturing completions for a specific context
for which you are writing the completion function, or are you trying
generically to capture the strings that any completion would normally
display via ZLE?

If the former you should be able to structure your own compadd calls
appropriately.  If the latter you might be able to get away with a
wrapper around "builtin compadd ..." that changes the arguments; see
for example what _approximate does.

}    and so I need to write a module
}    which exposes this data.

If you determine that you do need to go this way, looking at the
imlementation of the above compadd options is probably your best bet.


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

* Re: exposing completions data to user
  2016-10-18 14:50 ` Bart Schaefer
@ 2016-10-25  4:16   ` Ben Veal
  2016-11-13  8:00     ` Bart Schaefer
  0 siblings, 1 reply; 4+ messages in thread
From: Ben Veal @ 2016-10-25  4:16 UTC (permalink / raw)
  To: Bart Schaefer; +Cc: zsh-workers

Bart Schaefer <schaefer@brasslantern.com> writes:

> On Oct 18,  1:06am, Ben Veal wrote:
> }
> }    To do this I need access to the list of possible
> }    completions and their descriptions.
> }    As far as I can determine, this information is not
> }    normally available
>
> This is what the -O -A and -D options of the compadd builtin are meant
> to accomplish.  Are you capturing completions for a specific context
> for which you are writing the completion function, or are you trying
> generically to capture the strings that any completion would normally
> display via ZLE?
>
> If the former you should be able to structure your own compadd calls
> appropriately.  If the latter you might be able to get away with a
> wrapper around "builtin compadd ..." that changes the arguments; see
> for example what _approximate does.
>
> }    and so I need to write a module
> }    which exposes this data.
>
> If you determine that you do need to go this way, looking at the
> imlementation of the above compadd options is probably your best bet.

Yes, I want to get the completions and their
descriptions generically so that I can use zaw as an
alternative method for performing completions.

After poking around the source code some more it seems
that amatches[i]->matches[j]->str should contain the
completions (for different values of i and j). However
when I try exploring that datastructure at breakpoints
in the printlist, ilistmatches, and complistmatches
functions gdb tells me: "Cannot access memory at address 0x0" 
I get the same message when I try pmatches.

Any more advice?
-- 
 


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

* Re: exposing completions data to user
  2016-10-25  4:16   ` Ben Veal
@ 2016-11-13  8:00     ` Bart Schaefer
  0 siblings, 0 replies; 4+ messages in thread
From: Bart Schaefer @ 2016-11-13  8:00 UTC (permalink / raw)
  To: zsh-workers; +Cc: Ben Veal

On Oct 25,  5:16am, Ben Veal wrote:
}
} Yes, I want to get the completions and their
} descriptions generically so that I can use zaw as an
} alternative method for performing completions.
} 
} Any more advice?

I didn't think I had anything to add, but I found something else that
may help:

Look at Etc/zsh-development guide in the section on hooks.  There is
a set of hooks defined by the zsh/zle and zsh/complete modules that
you can use to intercept various completion operations.  (Depending
on how recent your zsh source is, you may need to look through the
source code to find all of these hook names.)

If your module adds a hook for "comp_list_matches", that *replaces*
the normal completion listing and instead passes the matches to your
module's callback in a struct chdata as defined in Src/Zle/comp.h (at
the very end of the file). This is actually the head of a linked list
of struct cmgroup that contain all the matches, so you'll have to
walk that list yourself.

Happy hunting.


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

end of thread, other threads:[~2016-11-13  8:06 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-10-18  0:06 exposing completions data to user Ben Veal
2016-10-18 14:50 ` Bart Schaefer
2016-10-25  4:16   ` Ben Veal
2016-11-13  8:00     ` Bart Schaefer

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