Re: Comint: handle raw tab

[Stefan Monnier <monnier@iro.umontreal.ca>]

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

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

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


        Stefan