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 14:29:01 +0200 Message-ID: <54F84C0D.106@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> <54F73EE0.9070306@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1425558563 2436 80.91.229.3 (5 Mar 2015 12:29:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 5 Mar 2015 12:29:23 +0000 (UTC) Cc: "=?UTF-8?Q?Fabi=c3=a1n_E.Gallina?=" , "emacs-devel@gnu.org" To: "Wedler, Christoph" , Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 05 13:29:13 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 1YTUtt-0000y3-9s for ged-emacs-devel@m.gmane.org; Thu, 05 Mar 2015 13:29:13 +0100 Original-Received: from localhost ([::1]:51360 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTUts-00080J-HD for ged-emacs-devel@m.gmane.org; Thu, 05 Mar 2015 07:29:12 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48867) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTUto-0007yb-7p for emacs-devel@gnu.org; Thu, 05 Mar 2015 07:29:09 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YTUtl-0006mT-2o for emacs-devel@gnu.org; Thu, 05 Mar 2015 07:29:08 -0500 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:46143) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YTUtk-0006mF-Rz for emacs-devel@gnu.org; Thu, 05 Mar 2015 07:29:04 -0500 Original-Received: by widem10 with SMTP id em10so37972973wid.5 for ; Thu, 05 Mar 2015 04:29:04 -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=A1mn0mDrlpIkZs5S3IOqHihnjuwfGSzjbDwqEwQvulE=; b=VVc3IoMp3F+fpOJ4H3jij3zVIETfoAY8/olwuj/DS9N0R3KkKkg4DBNxVeoJE160aq 5MC8yOSYDayd9zCQk25T5DEC1nSQZTocxYdIIW+HLDnDZLXgCmQMNF2JH6SbZg4Q4c33 K7qouWCdeWRFT0cU4H5TdxtlTOBt7n9tEv9XjgvFk4R9yHhWVv6Fj6IfyaeIRE/M8jtu iabRlBeZKJKpYv3xxvkaR270p266aK882KiU6rHlfN8cU0jYi5XCs0zRoZ72CXQliCew I0jr2dJhPeqBUNPTmQZpX6o62ElUTXR/nccPzjqQsUX5HR+t+a71TURFaX0SaOKgzZqz C4/Q== X-Received: by 10.194.120.40 with SMTP id kz8mr18285137wjb.21.1425558544288; Thu, 05 Mar 2015 04:29:04 -0800 (PST) Original-Received: from [192.168.1.3] ([82.102.93.54]) by mx.google.com with ESMTPSA id r3sm10322676wjw.7.2015.03.05.04.29.02 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 05 Mar 2015 04:29:03 -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:c05::22b 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:183665 Archived-At: On 03/05/2015 11:46 AM, Wedler, Christoph wrote: > narrow-to-region: for indentation code, this is probably only multi-mode > related Yeah, maybe. The old indentation engine uses it in one place, but that's probably just a bad decision. > 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. True. But I'd expect this to change, after either of the proposed schemes is implemented. Even if the major mode indentation function does the widening itself, that should happen in one place, right? Or otherwise centralized, as you suggest below. > 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. Right. In this case, indent-according-to-mode (for instance) could call `widen'. It's a rather straightforward change. > 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. That sounds good to me too, but then we should call it something like `prog-submode-widen', right? And then maybe introduce `prog-submode-narrow-to-region' and `prog-submode-save-restriction'. Et voilą, we now have a "new kind of narrowing", an approach Stefan, AFAICT, is still on the fence about. The above is also a bit less flexible than having a `widen-function'. > If the multi-mode indentation function additionally narrows to > START/END, our approach also works for sub modes which do not call widen. Yes, that's a nice bonus either way. > 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... I believe it's totally fine to introduce. It's not like the currently written modes will suddenly break. Only if they don't follow the guideline, they'll work worse in a multi-mode context. Note that your `prog-widen' suggestion (as well as `prog-indentation-context') also requires changes in those modes' implementations.