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: Thu, 05 Mar 2015 00:59:07 +0200 Message-ID: <54F78E3B.1080000@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> <54F742DA.3080106@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 1425509957 600 80.91.229.3 (4 Mar 2015 22:59:17 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 4 Mar 2015 22:59:17 +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 Wed Mar 04 23:59: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 1YTIG4-0003BH-P9 for ged-emacs-devel@m.gmane.org; Wed, 04 Mar 2015 23:59:16 +0100 Original-Received: from localhost ([::1]:47294 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTIG4-0001Nd-9a for ged-emacs-devel@m.gmane.org; Wed, 04 Mar 2015 17:59:16 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50778) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTIG1-0001NX-IP for emacs-devel@gnu.org; Wed, 04 Mar 2015 17:59:14 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTIFy-0002MM-Bx for emacs-devel@gnu.org; Wed, 04 Mar 2015 17:59:13 -0500 Original-Received: from mail-wg0-x235.google.com ([2a00:1450:400c:c00::235]:41246) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTIFy-0002MG-5M for emacs-devel@gnu.org; Wed, 04 Mar 2015 17:59:10 -0500 Original-Received: by wghl2 with SMTP id l2so5992868wgh.8 for ; Wed, 04 Mar 2015 14:59:09 -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=qp8wfRCNTaCUJcRB9CrDREqjlEhGeBMkiODYT2/TNMY=; b=OyEdEdmIbyUks5wYjFVG1652oRxPppCOPcbNINLnUjbY1XbjMaVRbSRRdtT7bCun+2 pTKSiWshZcgQPQPhUUCIcB5lgdvgAuwWzX6iHM6r4J0IUXRuC3lqK2LM+Ejf4C7Lk0LI 5mZ2qPrN+yi0xsnNxbmba4vs42Fx/qLUImvRWprfABRPT7LVkodNzeVGRtIqH4f56tMd I2AtvClsZHc/sQPm6QUWICDz39EiZzv03pF7PofKcL0SZo/9NZR0mzUGwMLQ+Y82UEqO +7yYgb1iw8PGCY4K0vlzYlJWUBwLUeAdmERtxkJvtKMQ1DeMhSwInTotVFCUS/ssjPfW 9x8g== X-Received: by 10.194.63.230 with SMTP id j6mr12081307wjs.31.1425509949453; Wed, 04 Mar 2015 14:59:09 -0800 (PST) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id hv5sm7877415wjb.16.2015.03.04.14.59.08 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 04 Mar 2015 14:59:08 -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:c00::235 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:183651 Archived-At: On 03/05/2015 12:26 AM, Stefan Monnier wrote: >> Do you have a submode in mind that will benefit from this distinction >> (external vs internal narrowing) in practice, right now? > > I don't understand the question. The question is, do you really expect to be burned by unexpected narrowing/widening in indentation code. That problem, in isolation, seems easily solvable. > I'm just firmly opposed to an API > that *relies* on narrowing, because I've been burned by narrowing too > often already. I'm softly opposed to the color chosen for this bike shed. And since the plans for the power plant are non-existing, maybe we should avoid ordering the bikes just yet. Or to put it in a different way, the lack of an API (which encourages people use some unseemly approach) is not the same as an API that relies on it. Because we won't have to support it for ever and ever.