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: Mon, 02 Mar 2015 13:51:58 -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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425322359 12587 80.91.229.3 (2 Mar 2015 18:52:39 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Mar 2015 18:52:39 +0000 (UTC) Cc: "Wedler, Christoph" , =?windows-1252?Q?Fab?= =?windows-1252?Q?i=E1n_E=2EGallina?= , "emacs-devel@gnu.org" To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 02 19:52:29 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 1YSVS8-000487-Pu for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 19:52:28 +0100 Original-Received: from localhost ([::1]:58907 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSVS8-00043t-Af for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 13:52:28 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54784) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSVRs-00041I-SD for emacs-devel@gnu.org; Mon, 02 Mar 2015 13:52:13 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSVRp-00077k-4z for emacs-devel@gnu.org; Mon, 02 Mar 2015 13:52:12 -0500 Original-Received: from pruche.dit.umontreal.ca ([132.204.246.22]:56208) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSVRp-00077W-02 for emacs-devel@gnu.org; Mon, 02 Mar 2015 13:52:09 -0500 Original-Received: from fmsmemgm.homelinux.net (lechon.iro.umontreal.ca [132.204.27.242]) by pruche.dit.umontreal.ca (8.14.1/8.14.1) with ESMTP id t22Iq31b023430; Mon, 2 Mar 2015 13:52:04 -0500 Original-Received: by fmsmemgm.homelinux.net (Postfix, from userid 20848) id 9E151AE187; Mon, 2 Mar 2015 13:51:58 -0500 (EST) In-Reply-To: <54F4A62F.3040403@yandex.ru> (Dmitry Gutov's message of "Mon, 02 Mar 2015 20:04: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 RV5233=0 X-NAI-Spam-Version: 2.3.0.9393 : core <5233> : inlines <2338> : streams <1398838> : uri <1869231> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.22 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:183581 Archived-At: > While `widen-function' should be enough for this, maybe it's too flexible > after all: that variable would never be used (correctly) with a buffer-local > value. Only with local dynamic binding. 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). >> It's OK if the API *allows* the use of >> narrowing, but requiring it would be a mistake. > I don't think any version of the API requires it. IIUC, you want to remove the (START . END) data: > + The non-nil value looks as follows > + ((START . END) LEFTMOST-COL) The first element tries to re-implement what's currently being handled with narrowing, successfully. Why? I understood this as saying you want to enforce the use of narrowing to pass to the sub-mode to bounds of its chunk. > It doesn't require any changes to the narrowing/widening logic, so the > question of whether narrowing is a good approach can again be deferred > until later. If you remove (START . END), then you decide that narrowing is the only way to go. Stefan