all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Fabian Ezequiel Gallina <galli.87@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Emacs-Devel devel <emacs-devel@gnu.org>
Subject: Re: Comint: handle raw tab
Date: Tue, 13 Sep 2011 12:20:09 -0300	[thread overview]
Message-ID: <CABq4mQvgEXTQzKRWkjZ5f-fnPY+5Y-i3K8AxQ0iAxR8aJy+5Vw@mail.gmail.com> (raw)
In-Reply-To: <jwv62kwpqiw.fsf-monnier+emacs@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 2804 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 3774 bytes --]

      parent reply	other threads:[~2011-09-13 15:20 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-09-12  3:34 Comint: handle raw tab Fabian Ezequiel Gallina
2011-09-13 12:43 ` Stefan Monnier
2011-09-13 13:51   ` Štěpán Němec
2011-09-13 15:23     ` Fabian Ezequiel Gallina
2011-09-13 18:19       ` Stefan Monnier
2011-09-26  1:30         ` Fabian Ezequiel Gallina
2011-09-13 15:20   ` Fabian Ezequiel Gallina [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CABq4mQvgEXTQzKRWkjZ5f-fnPY+5Y-i3K8AxQ0iAxR8aJy+5Vw@mail.gmail.com \
    --to=galli.87@gmail.com \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.