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: Sat, 26 Aug 2006 10:48:25 -0400 Message-ID: References: <20060825094503.4A84.SLAWOMIR.NOWACZYK.847@student.lu.se> <20060826143952.38F8.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 1156603730 1725 80.91.229.2 (26 Aug 2006 14:48:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 26 Aug 2006 14:48:50 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Aug 26 16:48:49 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 1GGzSn-0000t7-3j for ged-emacs-devel@m.gmane.org; Sat, 26 Aug 2006 16:48:45 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGzSm-00022t-3P for ged-emacs-devel@m.gmane.org; Sat, 26 Aug 2006 10:48:44 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GGzSW-0001zS-Gw for emacs-devel@gnu.org; Sat, 26 Aug 2006 10:48:28 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GGzSV-0001wI-GX for emacs-devel@gnu.org; Sat, 26 Aug 2006 10:48:28 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGzSV-0001w1-7C for emacs-devel@gnu.org; Sat, 26 Aug 2006 10:48:27 -0400 Original-Received: from [209.226.175.184] (helo=tomts22-srv.bellnexxia.net) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GGzb1-00039K-Ab for emacs-devel@gnu.org; Sat, 26 Aug 2006 10:57:15 -0400 Original-Received: from localhost ([70.55.147.36]) by tomts22-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20060826144825.EIKI10262.tomts22-srv.bellnexxia.net@localhost>; Sat, 26 Aug 2006 10:48:25 -0400 Original-Received: by localhost (Postfix, from userid 20848) id 5DFAB8E4E; Sat, 26 Aug 2006 10:48:25 -0400 (EDT) Original-To: Slawomir Nowaczyk In-Reply-To: <20060826143952.38F8.SLAWOMIR.NOWACZYK.847@student.lu.se> (Slawomir Nowaczyk's message of "Sat, 26 Aug 2006 14:41:30 +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:58919 Archived-At: > #> > 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... Hmm... looks like the two pieces of code don't run in the same buffer maybe? I've just installed a patch which may fix it. > 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 ()'") Again, here's the issue: the process's output can be absolutely arbitrary. If we see "\n>>> " somewhere in the process's output we have in general no guarantee that it's actually a prompt. Similarly if we see "_emacs_out " we have in general no guarantee that it's coming from python.el or from emacs.py. So we should be careful in the process filter to be as selective as possible in what we remove. In interactive use, it's perfectly OK to do: >>> import emacs >>> print '_emacs_out ()' _emacs_out () >>> but from python.el this basically turns into: >>> import emacs print '_emacs_out ()' >>> _emacs_out () >>> because we don't wait for the prompt in between the two. That's not something you'd normally do interactively. Instead if you didn't want to wait for the prompt between the two, you'd do something like: >>> import emacs; print '_emacs_out ()' _emacs_out () >>> which has the advantage that the _emacs_out () thingy appears at its normal place so you can be more selective and risk misidentifying it in fewer cases. > I do not understand why "command" python-send-command shouldn't contain > newline... It's not a command, so it can only called from elisp code. Check the callers and you'll see it is never called with a newline. So it's OK to make such an assumption. > 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. Sending a multiline thingy via python-send-string will look like absolute crap in the resulting output, because all the intermediate prompts will get concatenated rather than interleaved with the input. So I see no point in trying to support this in a case such as `python-send-command' where we don't use this flexibility anyway (and where we need to analyze the output, so the more control over it the better). > 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. Sure, go ahead. I just tried a simple heuristic to preserve the previous "\n\n" thingy without imposing it in the case where I know it's unneeded and even annoying. > 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... They're very much related: the accept-process-output call in python-send-receive will let process filters run, so it's basically an indirect call to python-preoutput-filter. > 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? Yes, it checks that the filter is being run from within the accept-process-output of python-send-receive. > Also, python-mode-running doesn't seem to be used anywhere. It's used right where it's used ;-) (unless (boundp 'python-mode-running) ; kill the recursion from jython-mode (let ((python-mode-running t)) (python-maybe-jython)))) i.e. it's used to prevent python-maybe-jython -> jython-mode -> python-mode -> python-maybe-jython -> jython-mode -> python-mode -> python-maybe-jython -> ... > #> > 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. Sounds good. As long as you can be sure that there can be no other output at the same time (i.e. the python process is idle, waiting at the prompt when you send the eargs command). Currently, we do not check that python is idle, so we have no guarantee that we can just discard all the output between after we send the `eargs' (ou modpath, or complete, ...) until after we see the _emacs_out. > #> > 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)... Thanks to the local-variable-p check, the filter should now correctly let it go through, except for unusual cases. Stefan