From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: antlr-mode.el - need some support by python.el Date: Wed, 04 Mar 2015 19:37:30 +0200 Message-ID: <54F742DA.3080106@yandex.ru> 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; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1425490672 4595 80.91.229.3 (4 Mar 2015 17:37:52 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Mar 2015 17:37:52 +0000 (UTC) Cc: "Wedler, Christoph" , "=?windows-1252?Q?Fab?= =?windows-1252?Q?i=E1n?= E.Gallina" , "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Mar 04 18:37:47 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 1YTDEu-0006Dp-Qg for ged-emacs-devel@m.gmane.org; Wed, 04 Mar 2015 18:37:44 +0100 Original-Received: from localhost ([::1]:45567 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTDEu-0002ax-CJ for ged-emacs-devel@m.gmane.org; Wed, 04 Mar 2015 12:37:44 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44156) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTDEq-0002Zx-Lj for emacs-devel@gnu.org; Wed, 04 Mar 2015 12:37:41 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTDEm-00012v-Rs for emacs-devel@gnu.org; Wed, 04 Mar 2015 12:37:40 -0500 Original-Received: from mail-we0-x230.google.com ([2a00:1450:400c:c03::230]:35767) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTDEm-00012q-LI for emacs-devel@gnu.org; Wed, 04 Mar 2015 12:37:36 -0500 Original-Received: by wevl61 with SMTP id l61so47918770wev.2 for ; Wed, 04 Mar 2015 09:37:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=rw6xgsrDH6geuLu6JIIabjNxOAgfwM60lKvaM+OeAxM=; b=IhxX8T3olAZSKwQP2bR7A8whcnYtWqh7BtyGMs04F/87fMtDTJAHABaZZ4pb8/dBfV dZqZAVkx/DE9A+N8nFpx2OHnVcd4PNoLHixA+UpcjOjc4D5SLSwrntnGWCMW1fDQa/Nb rmrmizDV5TJnGZblBYx+lWbPMf1uqI+sa9jIKoWpJRjKv/jqoG90RwsA5JTmhDbd69nY Dsx/HGa25/XljowpA8vcXl1ODy/joh6kPG+YJ3HsLjjT3CBUoK7aephaICXYcohrguZB bdoQvuKA5MsmMhTVIgdXfwd3Vrn0BJXplP3qyBAjHhiyGMNYsgZXuJWzMOzIzBkjqSIt h/Kg== X-Received: by 10.194.133.196 with SMTP id pe4mr10654166wjb.76.1425490655860; Wed, 04 Mar 2015 09:37:35 -0800 (PST) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id v6sm8033229wix.8.2015.03.04.09.37.33 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 09:37:35 -0800 (PST) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 Thunderbird/36.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::230 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:183646 Archived-At: On 03/03/2015 06:32 PM, Stefan Monnier wrote: > 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. That is interesting. Thanks. But considering this, we're unlikely to have `Info-mode' as a submode somewhere. >> 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). If widen-function is technically feasible, I'd rather go in this direction rather than introduce a variable everyone can ignore. > 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. That is true. However, as long as we don't have solutions for the hard problems in the multiple-mode space, we might as well hold of on making the change that only solves the relatively easy one (and let multiple-mode solutions use `widen' for the time being). It doesn't seem to me like it moves toward solutions for the hard problems, in any way. > 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). Do you have a submode in mind that will benefit from this distinction (external vs internal narrowing) in practice, right now?