From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Fabian Ezequiel Gallina Newsgroups: gmane.emacs.devel Subject: Re: Comint: handle raw tab Date: Tue, 13 Sep 2011 12:20:09 -0300 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=bcaec520f20bdf091004acd42d4f X-Trace: dough.gmane.org 1315929056 3329 80.91.229.12 (13 Sep 2011 15:50:56 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Sep 2011 15:50:56 +0000 (UTC) Cc: Emacs-Devel devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 13 17:50:52 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1R3VG8-0002iw-8Z for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 17:50:52 +0200 Original-Received: from localhost ([::1]:34322 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3VG7-0004cf-Ot for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 11:50:51 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:57681) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3VG1-0004cH-A7 for emacs-devel@gnu.org; Tue, 13 Sep 2011 11:50:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3VFx-0005S1-5C for emacs-devel@gnu.org; Tue, 13 Sep 2011 11:50:45 -0400 Original-Received: from mail-pz0-f44.google.com ([209.85.210.44]:57731) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3VFw-0005Rv-Lj for emacs-devel@gnu.org; Tue, 13 Sep 2011 11:50:40 -0400 Original-Received: by pzk36 with SMTP id 36so1200344pzk.17 for ; Tue, 13 Sep 2011 08:50:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=huLOtNJcMhIWEpYWCXt9AD2FHdU0WmUH1nmBTzt+WaA=; b=lk1yc+LsRBtHVlfQrHKNt51le1N0OJUatxzyRXQ7nKCITHkXIFLK7txHum/8K4s5AO ufXhtuGuYtz2fH2GQNCHCfug91ahPYZ+9HBrM3ZeTS3NT7wwF289yOmHUq1fZA6/sj7Z NydFc650jpfSbi23BMtUlZeOon6CCURyVbvds= Original-Received: by 10.68.34.169 with SMTP id a9mr1787698pbj.134.1315927209478; Tue, 13 Sep 2011 08:20:09 -0700 (PDT) Original-Received: by 10.68.60.10 with HTTP; Tue, 13 Sep 2011 08:20:09 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.210.44 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:143974 Archived-At: --bcaec520f20bdf091004acd42d4f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable 2011/9/13 Stefan Monnier > > 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 thi= ng > 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" t= o > 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, --=20 Fabi=E1n E. Gallina http://www.from-the-cloud.com --bcaec520f20bdf091004acd42d4f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
2011/9/13 Stefan Monnier <<= a href=3D"mailto:monnier@iro.umontreal.ca">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 ex= panded
> to "True" which is the unique completion. On the comint buff= er this causes
> the input to remain frozen. Internally, the input *does* get updated s= ince
> when I hit RET after evaling the code above the out shows "True&q= uot; but I
> didn't find a way to update the current input accordingly. Is ther= e 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 p= ointers (perhaps to an existing code in Emacs) on how to do that. I'm l= ooking at the documentation and existing code with no luck yet.
=A0
> 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 poss= ible
> completions I can get them with comint-output-filter-functions, the th= ing is
> the buffer now looks like this:
> In [1]: T
> TabError =A0 =A0 =A0 True =A0 =A0 =A0 TypeError

> And the only way I found to show the prompt again without sending &quo= t;T" to the
> process was sending a BREAK signal because comint-delete-input does no= t 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= 9;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. M= y guess is that once we can solve the first case they will be easy to disti= nguish.
=A0
> 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 co= mint
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 b= ased one. Once TAB does what I mean I don't see why change it ;)


Regards,
--
Fabi=E1n E. Gallina
http://www.from-the-cloud.com --bcaec520f20bdf091004acd42d4f--