bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

More hooks in bash completion


From: gibboris
Subject: More hooks in bash completion
Date: Fri, 13 Nov 2009 05:08:30 -0800 (PST)
User-agent: G2/1.0

Hello,
I'm trying to figure out how to get more of the readline granularity
in the bash completion process.
First of all I would like to fprintf to rl_outstream before
display_matches and from what I saw readline defines a
rl_completion_display_matches_hook which doesn't seem used by bash.
Not yet sure but using it would give a possibility to execute
something after the  rl_complete_internal ('@') (especially
interesting in the case of the switch(what_to_do) {} of
rl_complete_internal calls append_to_match).

But the difficult part is to come from find_variable ("X"); bash-
readline completion appears like a complex process even if the code is
tidy.

In brief I'm looking the following thing :
1) use complete -F _a_bash_func -o myopts --post-hook
_another_bash_func command
or
1 bis) use complete -F _a_bash_func -o myopts command with complete
analysing COMPREPLY but also another variable containing a string to
be printed (eg POSTCOMP_STRING and/or POSTCOMP_CONDITION)

In  the case 1), the bash functions would be hooked with the help
rl_completion_display_matches_hook.
In the case of 1 bis) the string would simply printed between
rl_insert_completions and rl_possible_completions (note, it seems
vi_mode is more flexible as a quick grep in emacs and vi keymap made
me discover rl_insert_completions AND rl_possible_completions while
emacs only uses rl_complete)

In both case having the possibility to conditionally hook according to
whether rl_complete_internal returned after
append_to_match or display_matches seems useful so shouldn't first
rl_complete_internal handle more append_to_match in a specific case
and put the if (matches[1]) one level upper ?

In the case of 1) both bash functions relative to one command doesn't
share their context so it's maybe more difficult and implies
reprocessing the command line words twice.
But the 1 bis) make harder for bash (programmer) to use option like
whether printing the string before each display_match, only after
append_to_match, ...


Some real use case :
- using bash functions for displaying matches (use of color as /bin/ls
bash_display_matches(), or, why printing both the long option and it's
use in display_matches() while only completing the command line with
the option string alone, ...
- conditionally process the command line according to whether the
completion successfully completed the word so, eg, if you burn-cd/
cdrecord, if a filename has been completed a progress bar may be
displayed to show the current size of the project, ... (idem with eg,
cp or scp)
In fact I think their should be different hook for completions (being
appended to command line if match : the COMPREPLY variable) and
suggestions (to be printed to help in the choice of the next
character) and the suggestion should be hookable (like said above it's
a readline feature not used by bash isn't)

Are there any hint/ideas/suggestions/url/previous_debates/... about
that ?
Should I dig it ? by beginning from the find_variable() of pcomplete.c
or the lib/{emacs,vi}{mode,keymap}.c ?

Raph


reply via email to

[Prev in Thread] Current Thread [Next in Thread]