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: antlr-mode.el - need some support by python.el Date: Tue, 03 Mar 2015 11:32:37 -0500 Message-ID: References: <54E40954.7000706@yandex.ru> <54E4AC06.60300@yandex.ru> <54E54DE7.1010807@yandex.ru> <54E558C8.9040600@yandex.ru> <54E90362.8070904@yandex.ru> <54F38FD3.1020307@yandex.ru> <54F47CD3.5080708@yandex.ru> <54F4A62F.3040403@yandex.ru> <54F4BA93.4000801@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425400405 13743 80.91.229.3 (3 Mar 2015 16:33:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 Mar 2015 16:33:25 +0000 (UTC) Cc: "Wedler, Christoph" , "=?windows-1252?Q?Fab?= =?windows-1252?Q?i=E1n?= E.Gallina" , "emacs-devel@gnu.org" To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 03 17:33:17 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YSpkx-0002nx-FO for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 17:33:15 +0100 Original-Received: from localhost ([::1]:39601 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSpkw-0001oA-L1 for ged-emacs-devel@m.gmane.org; Tue, 03 Mar 2015 11:33:14 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41941) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSpkf-0001kp-4l for emacs-devel@gnu.org; Tue, 03 Mar 2015 11:33:02 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSpkb-0002B2-Qs for emacs-devel@gnu.org; Tue, 03 Mar 2015 11:32:57 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:40013) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSpkb-0002Aw-Lk for emacs-devel@gnu.org; Tue, 03 Mar 2015 11:32:53 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t23GWm2p014106; Tue, 3 Mar 2015 11:32:49 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 31E05AE187; Tue, 3 Mar 2015 11:32:37 -0500 (EST) In-Reply-To: <54F4BA93.4000801@yandex.ru> (Dmitry Gutov's message of "Mon, 02 Mar 2015 21:31:31 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0 X-NAI-Spam-Rules: 1 Rules triggered RV5234=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5234> : inlines <2341> : streams <1399335> : uri <1870036> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:183597 Archived-At: >> Actually, for Info-mode, it wouldn't be "scoped", so it would need to be >> buffer-local (and even if it's scoped, it needs to say to which buffer >> it applies). > Sorry, can't follow you here. Info-mode's buffers (i.e. *.info files) contain several Info pages at the same time, so when you "go to an Info page" what really happens is that the mode narrows the buffer to the corresponding chunk in the buffer. Clearly this is not scoped inside a `let': the narrowing will simply be in effect until you jump to another page, at which point the narrowing will be changed to select another chunk. > But it's good if widen-function can have normal uses. Indeed, I don't see any problem there (I was just pointing out that assuming let-like scoping is a bad idea). > First of all, we've already agreed (I think?) to move LEFTMOST-COL from that > variable to an argument of the indent-calculate function. I can't remember agreeing to this level of detail, but I'm not necessarily opposed to that. > Thus, removing (START . END) will amount to not introducing the > aforementioned variable. Maybe never, maybe not just yet. The issue is simply: how to tell the submode what are the bounds of its chunk. If you don't do it by passing START/END, then you have to do it via side channels such as by narrowing. > While LEFTMOST-COL is quite useful, (START . END) is less so, The information of the bounds of the chunk is indispensable (the END part much less so, but the START part very much so). > modes. And yes, using narrowing. And I'm firmly opposed to imposing such an API. I much prefer passing START/END via dynamically scoped vars or via explicit arguments, and then let the submode use a little wrapper that sets up narrowing and calls the "same old" code (if the submode prefers using narrowing). Stefan