From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Wedler, Christoph" Newsgroups: gmane.emacs.devel Subject: RE: antlr-mode.el - need some support by python.el Date: Thu, 5 Mar 2015 09:46:47 +0000 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> <54F4BA93.4000801@yandex.ru> <54F73EE0.9070306@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1425548842 780 80.91.229.3 (5 Mar 2015 09:47:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 09:47:22 +0000 (UTC) Cc: =?iso-8859-1?Q?Fabi=E1n_E=2EGallina?= , "emacs-devel@gnu.org" To: Dmitry Gutov , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 05 10:47:06 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 1YTSMx-0005bM-JW for ged-emacs-devel@m.gmane.org; Thu, 05 Mar 2015 10:47:04 +0100 Original-Received: from localhost ([::1]:50643 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTSMx-0004qC-4E for ged-emacs-devel@m.gmane.org; Thu, 05 Mar 2015 04:47:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTSMp-0004mh-HZ for emacs-devel@gnu.org; Thu, 05 Mar 2015 04:46:59 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTSMk-0002At-I0 for emacs-devel@gnu.org; Thu, 05 Mar 2015 04:46:55 -0500 Original-Received: from smtpgw01.sap-ag.de ([155.56.66.96]:11422 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTSMk-0002Ag-9Y for emacs-devel@gnu.org; Thu, 05 Mar 2015 04:46:50 -0500 Thread-Topic: antlr-mode.el - need some support by python.el Thread-Index: AQHQVc+o/iQ7SI3fhEWPaKR798EdF50Mk39QgAETMUA= In-Reply-To: <54F73EE0.9070306@yandex.ru> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.40.114] X-detected-operating-system: by eggs.gnu.org: Windows 7 or 8 X-Received-From: 155.56.66.96 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:183663 Archived-At: >> If we do the START/END boundaries via narrowing, we probably >> induce too much work in major modes. As I wrote earlier: all >> functions which are called by the indent calculation must not call widen >> anymore > How is it "too much work"? I've written my share of indentation code,=20 > and the only related function that I found useful were=20 > `save-restriction' and `narrow-to-region'. save-restriction: sure, every use of narrow/widen in indentation code should be in a save-restriction. narrow-to-region: for indentation code, this is probably only multi-mode related widen: If you grep for `widen' in EMACS/lisp/progmodes, you find quite a few matches. Probably half of them are in indentation functions or functions which are used by indentation functions. And actually, they uses are _correct_, as the indentation commands should also work when the user has used narrowing (via C-x n n and friends). (As I wrote earlier, quite a few major modes do not work correctly or at least strange with intra-defun narrowing: C++, EmacsLisp, ...). If we do the START/END boundaries only via narrowing, only the outer indentation command should use widen (which the multi-mode code won't call), all called function are not allowed to use widen anymore. In other words, the widen calls must be moved to the outer commands. If we do the START/END boundaries via the dynamically scoped variable, the major modes just have to replace their (widen) call by (prog-widen), a widen function which respects prog-indentation-context. If the multi-mode indentation function additionally narrows to START/END, our approach also works for sub modes which do not call widen. Yes, relying on dynamically scoped variable is not completely nice, but there had been no programming guideline that indentation code should only call widen only once directly at the beginning (as I said before: inside save-restriction, of course). I would not introduce such a guideline after decades...