2011/9/13 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.
>
>
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 ;)


Regards,
-- 
Fabián E. Gallina
http://www.from-the-cloud.com