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: python-mode: make sure output is not eaten Date: Fri, 25 Aug 2006 18:53:41 -0400 Message-ID: References: <20060822201045.4975.SLAWOMIR.NOWACZYK.847@student.lu.se> <87sljo40ra.fsf-monnier+emacs@gnu.org> <20060825094503.4A84.SLAWOMIR.NOWACZYK.847@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1156546442 12236 80.91.229.2 (25 Aug 2006 22:54:02 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Aug 2006 22:54:02 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 26 00:54:01 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GGkYo-0002VJ-Dx for ged-emacs-devel@m.gmane.org; Sat, 26 Aug 2006 00:53:58 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGkYo-0002q0-2e for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2006 18:53:58 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GGkYb-0002pR-N3 for emacs-devel@gnu.org; Fri, 25 Aug 2006 18:53:45 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GGkYZ-0002mb-Ih for emacs-devel@gnu.org; Fri, 25 Aug 2006 18:53:45 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGkYZ-0002mT-FM for emacs-devel@gnu.org; Fri, 25 Aug 2006 18:53:43 -0400 Original-Received: from [209.226.175.4] (helo=tomts16-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GGkgw-0008AT-ED for emacs-devel@gnu.org; Fri, 25 Aug 2006 19:02:22 -0400 Original-Received: from localhost ([70.55.147.36]) by tomts16-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060825225342.YLNQ27612.tomts16-srv.bellnexxia.net@localhost>; Fri, 25 Aug 2006 18:53:42 -0400 Original-Received: by localhost (Postfix, from userid 20848) id EB15A8E4E; Fri, 25 Aug 2006 18:53:41 -0400 (EDT) Original-To: Slawomir Nowaczyk In-Reply-To: <20060825094503.4A84.SLAWOMIR.NOWACZYK.847@student.lu.se> (Slawomir Nowaczyk's message of "Fri, 25 Aug 2006 11:03:41 +0200") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58890 Archived-At: > #> Yes, of course. BTW do you have any idea why the current code uses "\n\n"? > Not, not really -- it looks to me like an attempt to fix some prompt > problems which didn't quite work. Or it may be an attempt to have > C-c C-s work for indented blocks, as Steven suggested. I've installed a half-way solution which I believe keeps the old behavior when needed. > Not really, at least not in my testing... the problems I am seeing > come from the fact that when eldoc sends commands, Python responds > with line that looks like "_emacs_out reload(module)\n>>> " and the > comint filter needs to remove the trailing prompt as well. I've added python-preoutput-skip-next-prompt for that purpose. This way such prompts should get removed unambiguously. > OTOH, I like your solution of printing prompt only if there is some > other output -- seems clean to me. That's just what was there before (modulo the fact that it didn't catch all situations). > You have misspelled command as "comand" in > (defun python-send-command (command) Thanks. Fixed. > Other than that, your patch looks OK to me. Please install, it's > definitely an improvement. I've installed a variation of it. Please fix it as you see fit. > However, if you change the > (string-match "\\`_emacs_out \\(.*\\)\n\\'" line) > to > (string-match "\\`\\(?:>>> \\)?_emacs_out \\(.*\\)\n\\'" line) > then you do not need to do the trick of augmenting commands with "; > print" statement: things work just fine if you do python-send-string > followed by python-send-receive. Silently interpreting/removing output from the process is always risky, since the output may appear for other reasons than the ones we expected. So I'd rather be extra careful to only recognize _emacs_out when I'm sure it's really the internal thingy. Stefan