From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Ken Manheimer" Newsgroups: gmane.emacs.devel Subject: Re: python-mode: make sure output is not eaten Date: Fri, 25 Aug 2006 15:53:56 -0400 Message-ID: <2cd46e7f0608251253s3d4dbf47y3f011435d6092b28@mail.gmail.com> References: <20060821220052.494C.SLAWOMIR.NOWACZYK.847@student.lu.se> <87lkphe20n.fsf-monnier+emacs@gnu.org> <20060822201045.4975.SLAWOMIR.NOWACZYK.847@student.lu.se> <87sljo40ra.fsf-monnier+emacs@gnu.org> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1156535663 13850 80.91.229.2 (25 Aug 2006 19:54:23 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Fri, 25 Aug 2006 19:54:23 +0000 (UTC) Cc: Slawomir Nowaczyk , Stefan Monnier , emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Aug 25 21:54:20 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 1GGhkp-000195-9q for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2006 21:54:11 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGhko-0003ut-N5 for ged-emacs-devel@m.gmane.org; Fri, 25 Aug 2006 15:54:10 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GGhkd-0003ue-3C for emacs-devel@gnu.org; Fri, 25 Aug 2006 15:53:59 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GGhkb-0003uS-Uh for emacs-devel@gnu.org; Fri, 25 Aug 2006 15:53:58 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GGhkb-0003uP-SJ for emacs-devel@gnu.org; Fri, 25 Aug 2006 15:53:57 -0400 Original-Received: from [66.249.82.224] (helo=wx-out-0506.google.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GGhsw-0000oC-VC for emacs-devel@gnu.org; Fri, 25 Aug 2006 16:02:35 -0400 Original-Received: by wx-out-0506.google.com with SMTP id i26so1029047wxd for ; Fri, 25 Aug 2006 12:53:56 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nzgnRTENAN+bR+nXStv5dyMHnnu5Vkrabx98o1hU+tp73XzLqvVdUO2nIVsYZHHRn/tPe7jmHP5BXY6dYxwkYGYu6XnsuBN6/IfWuUTO74hoG/XPXVo7tvmSUd2a/OoW0fInkCohZ+clexNXIyiIeV/eMVIN+rsVy7f/2cJa6zs= Original-Received: by 10.90.113.18 with SMTP id l18mr775663agc; Fri, 25 Aug 2006 12:53:56 -0700 (PDT) Original-Received: by 10.90.105.4 with HTTP; Fri, 25 Aug 2006 12:53:56 -0700 (PDT) Original-To: "Steven Huwig" In-Reply-To: Content-Disposition: inline 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:58869 Archived-At: On 8/24/06, 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 i haven't looked at the code in question, but have a salient point to offer. the handling of interactively entered python code is different than the processing of source code from a file, specifically in that the end of top-level blocks is detected by an empty line of input. this is necessary because, during interaction, you don't want to require people to enter the first line of the subsequent top-level construct to determine that the previous top-level construct has concluded. instead, it's assumed they've concluded when an empty line is encountered. i suspect that the "\n\n" you all are referring to is specifically to provide that newline. > 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. ... and a double newline doesn't have this effect for file input, where the interpreter/compiler *can* wait for the first line of the next top-level construct, or end-of-file. > [...] -- ken ken.manheimer@gmail.com http://myriadicity.net