From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Comint: handle raw tab Date: Tue, 13 Sep 2011 08:43:10 -0400 Message-ID: References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1315917815 15014 80.91.229.12 (13 Sep 2011 12:43:35 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Tue, 13 Sep 2011 12:43:35 +0000 (UTC) Cc: Emacs-Devel devel To: Fabian Ezequiel Gallina Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Sep 13 14:43:28 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 1R3SKm-0007xb-8q for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 14:43:28 +0200 Original-Received: from localhost ([::1]:37762 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3SKk-0006Kb-V2 for ged-emacs-devel@m.gmane.org; Tue, 13 Sep 2011 08:43:26 -0400 Original-Received: from eggs.gnu.org ([140.186.70.92]:53765) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3SKd-0006JZ-Es for emacs-devel@gnu.org; Tue, 13 Sep 2011 08:43:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1R3SKZ-0003XL-5V for emacs-devel@gnu.org; Tue, 13 Sep 2011 08:43:19 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:57634 helo=ironport2-out.pppoe.ca) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1R3SKZ-0003X4-2n for emacs-devel@gnu.org; Tue, 13 Sep 2011 08:43:15 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAMFOb05FxK3+/2dsb2JhbABCp2Z5gVMBAQQBViMFCws0EhQYDSSICrgqhm4EoDeERA X-IronPort-AV: E=Sophos;i="4.68,374,1312171200"; d="scan'208";a="136060670" Original-Received: from 69-196-173-254.dsl.teksavvy.com (HELO ceviche.home) ([69.196.173.254]) by ironport2-out.pppoe.ca with ESMTP/TLS/ADH-AES256-SHA; 13 Sep 2011 08:43:12 -0400 Original-Received: by ceviche.home (Postfix, from userid 20848) id 4D772660B6; Tue, 13 Sep 2011 08:43:10 -0400 (EDT) In-Reply-To: (Fabian Ezequiel Gallina's message of "Mon, 12 Sep 2011 00:34:00 -0300") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:143966 Archived-At: > 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