From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Slawomir Nowaczyk Newsgroups: gmane.emacs.devel Subject: Re: python-mode: make sure output is not eaten Date: Sat, 26 Aug 2006 14:41:30 +0200 Message-ID: <20060826143952.38F8.SLAWOMIR.NOWACZYK.847@student.lu.se> References: <20060825094503.4A84.SLAWOMIR.NOWACZYK.847@student.lu.se> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Trace: sea.gmane.org 1156596139 15261 80.91.229.2 (26 Aug 2006 12:42:19 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 26 Aug 2006 12:42:19 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 26 14:42:18 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 1GGxUK-0002Gi-ES for ged-emacs-devel@m.gmane.org; Sat, 26 Aug 2006 14:42:12 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGxUJ-0003tM-PA for ged-emacs-devel@m.gmane.org; Sat, 26 Aug 2006 08:42:11 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GGxTw-0003sj-RC for emacs-devel@gnu.org; Sat, 26 Aug 2006 08:41:48 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GGxTu-0003sE-Vr for emacs-devel@gnu.org; Sat, 26 Aug 2006 08:41:48 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGxTu-0003s9-TJ for emacs-devel@gnu.org; Sat, 26 Aug 2006 08:41:46 -0400 Original-Received: from [130.235.16.11] (helo=himmelsborg.cs.lth.se) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GGxcP-0001n8-KE for emacs-devel@gnu.org; Sat, 26 Aug 2006 08:50:34 -0400 Original-Received: from [127.0.0.1] (slawek@dain [130.235.16.76]) by himmelsborg.cs.lth.se (8.13.6/8.13.6/perf-jw-tr) with ESMTP id k7QCfelh029559 for ; Sat, 26 Aug 2006 14:41:41 +0200 (CEST) Original-To: emacs-devel@gnu.org In-Reply-To: X-Esmandil_Citation: done X-Mailer-Plugin: Popup Memopad for Becky!2 Ver.0.02 Rev.2 X-Mailer: Becky! ver. 2.25.02 [en] 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:58912 Archived-At: On Fri, 25 Aug 2006 18:53:41 -0400 Stefan Monnier wrote: #> > 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. Have you installed the complete patch? Because current version of the CVS code doesn't quite work for me... it hangs emacs whenever I try python-send-buffer (I need C-g to get it make it responsive again), which seems to be related to the "while" loop in python-send-receive never finishing due to the (local-variable-p 'python-preoutput-result) in python-preoutput-filter never being true... I do not understand the purpose of most of your code, so I do not know how should it be fixed. In general, I do not particularly like your patch (I am talking about prompt handling, there are a couple of other things you have changed which look OK). I still think (python-send-string "import emacs") (python-send-receive "print '_emacs_out ()'") is cleaner than (python-send-receive "import emacs; print '_emacs_out ()'") I do not understand why "command" python-send-command shouldn't contain newline... It should work just fine with multiple lines, the only thing which might cause problems is indentation, and even that only if there is an indented block at the very end. If you are thinking about conditionally adding one or two newlines after python-send-string, than the correct condition should be "add double newline if and only if the last line is indented", IMHO. I do not understand the purpose of python-preoutput-result variable. It is used in python-send-receive and in python-preoutput-filter, but those uses seem unrelated... if I read the code correctly, python-send-receive will call (make-local-variable 'python-preoutput-filter), but it will also always call (kill-local-variable 'python-preoutput-filter)... what is the point of it? And when could testing (local-variable-p 'python-preoutput-result) in python-preoutput-filter make sense? Also, python-mode-running doesn't seem to be used anywhere. #> > 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. I do not think this is the right way to solve the problem. IMHO, the variable should be called python-inhibit-output and should prevent *anything* from being printed in Inferior Python buffer -- thus, functions like eldoc could bind it to 't and we would not need to worry about them at all. After all, it doesn't matter how the output of python-eldoc-function looks like, it should never appear in the comint buffer. And it would let us simplify the common case of *user* wanting to run Python code. #> > 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. I do not quite understand... You never *know* that it is the internal thingy anyway (try typing "print '_emacs_out'" in the Inferior Python buffer)... I do not see the danger of removing the prompt in front of _emacs_out. -- Best wishes, Slawomir Nowaczyk ( slawomir.nowaczyk.847@student.lu.se ) If vegetarians love animals so much, why do they eat all their food???