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: Mon, 02 Mar 2015 21:31:31 +0200 Message-ID: <54F4BA93.4000801@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> 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 1425324720 22024 80.91.229.3 (2 Mar 2015 19:32:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 2 Mar 2015 19:32:00 +0000 (UTC) Cc: "Wedler, Christoph" , "=?UTF-8?Q?Fabi=c3=a1n_E.Gallina?=" , "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Mar 02 20:31:54 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 1YSW4H-0005Qe-Mf for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 20:31:53 +0100 Original-Received: from localhost ([::1]:59239 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSW4G-0001VK-Re for ged-emacs-devel@m.gmane.org; Mon, 02 Mar 2015 14:31:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40595) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSW42-0001So-7r for emacs-devel@gnu.org; Mon, 02 Mar 2015 14:31:39 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YSW3y-0006vs-Rj for emacs-devel@gnu.org; Mon, 02 Mar 2015 14:31:38 -0500 Original-Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:37863) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YSW3y-0006vm-M2 for emacs-devel@gnu.org; Mon, 02 Mar 2015 14:31:34 -0500 Original-Received: by wesw55 with SMTP id w55so35425991wes.4 for ; Mon, 02 Mar 2015 11:31:34 -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=fxwEfbGslU5EDxMZXkXI2uIiCVDayqOfeCDVB3+sO5E=; b=O1+lric7B97XzcZQf3IPi2nEDT4dmtH6fxiSvfoE3lM1NE8Pe/+6AR4qboyHB9fsLH 8xvK6AYl2Xa8tq8mJw3Oh30a7/q8AmsXHifYhryLd8ubMg6iV2g7KAQR/sKbN2szuYG7 wMeLmjdgmoY3FZyjvNRWT4HvFartIOrPC9MHfKWlVVwdH24Yn3vUOcHP0XsicQrla8wU jP3mELgn9eBr0V9tHr/lJoCTdO4cUOGh2atbo2uR3ilxh08Z2HOCsr3xPlqelYa03wzK xBs+1ID0rhmNldgvM4iUULq8pVZ4epLiyKZeki97hRGXyB9gbaIDY/+EWgS31AuMVpWI y0hA== X-Received: by 10.180.90.38 with SMTP id bt6mr12469429wib.46.1425324694089; Mon, 02 Mar 2015 11:31:34 -0800 (PST) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id vv9sm2147502wjc.35.2015.03.02.11.31.32 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Mar 2015 11:31:33 -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::22a 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:183582 Archived-At: On 03/02/2015 08:51 PM, Stefan Monnier wrote: > 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. Not really familiar with Info-mode (even though I've tried to get into it a few times). But it's good if widen-function can have normal uses. > 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. First of all, we've already agreed (I think?) to move LEFTMOST-COL from that variable to an argument of the indent-calculate function. Thus, removing (START . END) will amount to not introducing the aforementioned variable. Maybe never, maybe not just yet. While LEFTMOST-COL is quite useful, (START . END) is less so, since it would replace what already works in e.g. mmm-mode is doing it now, *and* it would require more changes to existing modes. >> 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. It can be added later, although I don't see a lot of value in it. Honestly, if we had such variable, after we have prog-indent-line delegating to indent-calculate functions, I'd be very tempted to implement its support in prog-indent-line itself, instead of leaving it up to individual modes. And yes, using narrowing.