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, 09 Mar 2015 21:16:20 -0400 Message-ID: References: <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> <54F78E3B.1080000@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1425950226 4859 80.91.229.3 (10 Mar 2015 01:17:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 10 Mar 2015 01:17:06 +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 10 02:16:57 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 1YV8n0-0004wa-Gh for ged-emacs-devel@m.gmane.org; Tue, 10 Mar 2015 02:16:54 +0100 Original-Received: from localhost ([::1]:46007 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8mu-0006Hv-9v for ged-emacs-devel@m.gmane.org; Mon, 09 Mar 2015 21:16:48 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:43536) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8me-0006Hi-R4 for emacs-devel@gnu.org; Mon, 09 Mar 2015 21:16:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YV8mU-0003Uz-1Y for emacs-devel@gnu.org; Mon, 09 Mar 2015 21:16:32 -0400 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:25400) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YV8mT-0003Uj-Ti for emacs-devel@gnu.org; Mon, 09 Mar 2015 21:16:21 -0400 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlgJAPOG1lRLd/0j/2dsb2JhbABbgwaDX8Y4BAICgQ1EAQEBAQEBfIQNAQQBViMFCwsOJhIUGA0kiDgIziMBAQEHAgEfj3gHhCoFqXKBRSKECiKCcwEBAQ X-IPAS-Result: AlgJAPOG1lRLd/0j/2dsb2JhbABbgwaDX8Y4BAICgQ1EAQEBAQEBfIQNAQQBViMFCwsOJhIUGA0kiDgIziMBAQEHAgEfj3gHhCoFqXKBRSKECiKCcwEBAQ X-IronPort-AV: E=Sophos;i="5.09,536,1418101200"; d="scan'208";a="113131827" Original-Received: from 75-119-253-35.dsl.teksavvy.com (HELO pastel.home) ([75.119.253.35]) by ironport2-out.teksavvy.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 09 Mar 2015 21:16:21 -0400 Original-Received: by pastel.home (Postfix, from userid 20848) id A4F081047; Mon, 9 Mar 2015 21:16:20 -0400 (EDT) In-Reply-To: <54F78E3B.1080000@yandex.ru> (Dmitry Gutov's message of "Thu, 05 Mar 2015 00:59:07 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 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:183751 Archived-At: > The question is, do you really expect to be burned by unexpected > narrowing/widening in indentation code. I'm not sure what you mean by that question: if the outer mode uses narrowing to specify the bounds of the chunk, then indentation code can't use `widen'. Use of narrowing inside the indentation code will be fine, but use of widen will not. Yet, "grep widen lisp/progmodes/*.el" suggests that it's probably used by several indenters. So, yes, I expect problems. > 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. I think specifying the chunk bounds via some dynamically-scoped var is a pretty safe option. Maybe it will be supplanted in the future by some other alternative, but it doesn't impose any particular implementation constraint, contrary to the use of narrowing. Stefan