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: Fri, 25 Aug 2006 11:03:41 +0200 Message-ID: <20060825100525.4A98.SLAWOMIR.NOWACZYK.847@student.lu.se> References: <87sljo40ra.fsf-monnier+emacs@gnu.org> 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 1156496710 11067 80.91.229.2 (25 Aug 2006 09:05:10 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Aug 2006 09:05:10 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 25 11:05:02 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 1GGXbw-0005Sh-5X for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2006 11:04:20 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGXbv-0000TX-CP for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2006 05:04:19 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GGXba-0000QP-Ul for emacs-devel@gnu.org; Fri, 25 Aug 2006 05:03:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GGXbZ-0000O5-QY for emacs-devel@gnu.org; Fri, 25 Aug 2006 05:03:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGXbZ-0000Nk-IR for emacs-devel@gnu.org; Fri, 25 Aug 2006 05:03:57 -0400 Original-Received: from [130.235.16.11] (helo=himmelsborg.cs.lth.se) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GGXjo-0003Fz-B6 for emacs-devel@gnu.org; Fri, 25 Aug 2006 05:12:28 -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 k7P93ofk008260 for ; Fri, 25 Aug 2006 11:03:51 +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:58856 Archived-At: On Thu, 24 Aug 2006 20:18:07 -0400 Steven Huwig wrote: #> On Aug 23, 2006, at 12:04 AM, Stefan Monnier wrote: #> > #> > Yes, of course. BTW do you have any idea why the current code uses #> > "\n\n"? #> #> Might it be because the Python interactive interpreter needs the extra #> newline due to significant whitespace? E.g. #> #> >>> for i in range(1,5): #> ... print i, #> ... #> 1 2 3 4 #> #> a DEDENT token is created by the unindented second newline, closing #> the block. A single newline cannot do that as it is also the #> statement terminator. #> #> Probably it compensates for indented text without a trailing newline. #> It doesn't look like python-mode itself has any situations where this #> matters, but it is possible -- but unlikely -- for user input to be #> affected. #> #> If you do the following in python-mode with both versions: #> #> C-c C-s for i in range(1, 5): C-q C-j #> print i, #> #> you will see the difference in behavior. OK, you are right... In my testing I only made sure that ending code with indented block works fine with commands like python-send-buffer and python-send-region, I haven't tested with bare python-send-string. Yes, double "\n" might be an attempt to get that working. #> To explain my post a little more, I think the new code is the right #> thing. If someone is astute enough to type in multi-line Python #> commands at an Emacs interactive prompt, then they will likely be #> astute enough to realize that they need to add an extra newline. #> #> Plus I don't think the usage pattern is typical in the first place; #> there is a comint buffer for such interaction. I agree. Besides, if anything, TRT would be to allow people start an indented block with C-c C-s and then *continue* it in comint buffer... but it is neither easy nor important enough to worry about it right now, IMHO. -- Best wishes, Slawomir Nowaczyk ( slawomir.nowaczyk.847@student.lu.se ) Write your questions down on the back of $20 dollar bill and send them to me.