2011/9/13 Stefan Monnier
<address@hidden>
> First case scenario, unique completion:
> Consider the only possible completion being "True".
> In [1]: Tr
> Then hit C-q TAB so a TAB gets inserted after it and evaled:
> (comint-send-input t)
> In a normal ipython shell the result of this causes the input to be expanded
> to "True" which is the unique completion. On the comint buffer this causes
> the input to remain frozen. Internally, the input *does* get updated since
> when I hit RET after evaling the code above the out shows "True" but I
> didn't find a way to update the current input accordingly. Is there any way
> to achieve that?
You're going to have to redirect the process's output to read the
shell's output and then use it to fill the user's current input.
I'll appreciate any pointers (perhaps to an existing code in Emacs) on how to do that. I'm looking at the documentation and existing code with no luck yet.
> Second scenario, multiple completions available:
> Consider now I have typed just T:
> In [1]: T
> Then hit C-q TAB so a TAB gets inserted after it and evaled:
> (comint-send-input t)
> Now interesting things happens, since ipython outputs the list of possible
> completions I can get them with comint-output-filter-functions, the thing is
> the buffer now looks like this:
> In [1]: T
> TabError True TypeError
> And the only way I found to show the prompt again without sending "T" to the
> process was sending a BREAK signal because comint-delete-input does not work
> in that instance. Is there a better way to handle that?
The better way (IMNSHO) is to catch the process output so it doesn't get
inserted in the buffer, build a completion table from it, and then
call the normal in-buffer completion code with it so it gets displayed
in *Completions*.
That's simple enough, changing the process filter for that particular case would do the trick. My guess is that once we can solve the first case they will be easy to distinguish.
> The only thing I can think of is having to rewrite the shell
> interactions (pydoc, pdbtrack, etc) I already have in python.el.
> However all the inferior shells implementations I know use comint so
> that makes me feel unsure about it.
I don't know if someone ever tried to use a term rather than a comint
inferior process, but I'd be interested to hear your experience with it.
I suspect it's going to be harder to interface it with compile.el.
I really would like to continue with the comint based one. Once TAB does what I mean I don't see why change it ;)