[IPython-dev] ipython/pydb integration - readline

[R. Bernstein]

Here's a suggestion for a what I think is a simpler interface.

First I hadn't realized that previously:

   complete_symbol(line, pos_in_line) -> [completions]

pos_in_line referred to the *end* of the word to complete rather than
the beginning of it, and that there was an implicit search *back* from
that to find the word start boundary. I just assumed the word
completion went from pos_in_line to the end of the string. So that
also means that I hadn't realized that there was some implied regular
expression that was getting used to search back from. And with the
previous interface that still seems to happen in some situations.

Let's start out with the simplest definition:

   complete_symbol(line) -> [completions]

or should it be (completions)?

What this would do is give completions of the last "word" in line with
an implicit search back to find the word in line. But as you point
out, the word one wants to complete might not be the last word but be
a word somewhere in the middle of the line, and one wants to keep the
context to the right in the string the same. Okay then let's try:

   complete_symbol(line, endword_pos=-1) -> [completions]

But now there is an observation that finding the word may be context
sensitive. In the "Struct" or object interface, this is solved by
having the caller pick out that part and pass that. I think it's
called "symbol". But two other solutions I think that are simpler at
least from the caller's standpoint is to give the position of the
start of the word or a regexp to use to search back to instead of the
default look-for-blank (or maybe its look-for-non-alphanum) regular
expression that is implied previously.

Allowing a start position I think would be the simplest:

   complete_symbol(line, endword_pos=-1, startword_pos=None) -> [completions]

But if one really wants that regexp, because it saves the caller from
having to do a search first (and presumably within the context of the
caller it knows what the right regexp should be) then:

   complete_symbol(line, endword_pos=-1, re_str="[ \t]") 
   -> [completions]
or 
   complete_symbol(line, endword_pos=-1, startword_pos=None, re_str='[ \t]') 
   -> [completions]
   # Note: re_str is used *only* if startword_pos is None

Here's why I find this nicer. My guess is more than half of the time
the call needs only to be:

   complete_symbol(line)

and 90% of the time (actually 100% in the cases in either debugger pdb
or pydb)
   complete_symbol(line, endword_pos)

will suffice. The thing about the object parameter interface is that
the caller has to create it. And the line portion is *not* optional,
so why not make that a required parameter? It reduces run-time errors
at least in that aspect. And I don't see a need for giving the
"command" part because at least in my uses, I arrange for what the
valid completions can be *in advance* of the completion calls.


Ville M. Vainio writes:
 > On 10/29/06, R. Bernstein <rocky at panix.com> wrote:
 > 
 > > Looking to see how this matches the corresponding GNU Emacs interface
 > > gud-gdb-complete-command() I see that that the routine picks out the
 > > last word rather than being told where the last word starts. Since
 > > finding word boundaries may be a little application specific, perhaps
 > > passing in a position is not so bad. But maybe better though would to
 > > make "pos_in_line" optional and use a default find last word search to
 > > pick the word out.
 > 
 > pos_in_line is necessary because the cursor could be positioned like
 > this on the moment of pressing tab:
 > 
 > cp /var/lo[cursor] /home/foo
 > 
 > I thought passing the last "symbol" as convenience (in this example,
 > '/var/lo') could be handy, but it would bloat the hook too much.
 > 
 > I guess I'll pass a "Struct" object, where the hook would be:
 > 
 > def my_complete_symbol(event):
 >  print event.line, event.pos_in_line, event.symbol, event.command
 > 
 > (where 'command' would be the first word).
 > 
 > symbol and command are there purely for the convenience.
 > 
 > I think the completion hooks should be dispatchable by both of:
 > 
 > - Dictionary lookup with 'command' (for performance)
 > - Regexp (where the hooks with empty regexp are always tried).
 > 
 > -- 
 > Ville M. Vainio - vivainio.googlepages.com
 > blog=360.yahoo.com/villevainio - g[mail | talk]='vivainio'
 >