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: Mon, 8 Jun 2015 09:12:35 +0000 Message-ID: References: <54E90362.8070904@yandex.ru> <54F38FD3.1020307@yandex.ru> <54F47CD3.5080708@yandex.ru> <54F4A62F.3040403@yandex.ru> <54F4BA93.4000801@yandex.ru> <54F73EE0.9070306@yandex.ru> <5571E070.9050905@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 1433754886 16966 80.91.229.3 (8 Jun 2015 09:14:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 8 Jun 2015 09:14:46 +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 Mon Jun 08 11:14:41 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 1Z1t8b-0007mk-Vr for ged-emacs-devel@m.gmane.org; Mon, 08 Jun 2015 11:14:34 +0200 Original-Received: from localhost ([::1]:56628 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1t8b-00012F-9B for ged-emacs-devel@m.gmane.org; Mon, 08 Jun 2015 05:14:33 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59434) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1t8J-00011y-4c for emacs-devel@gnu.org; Mon, 08 Jun 2015 05:14:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z1t8F-0000md-Uu for emacs-devel@gnu.org; Mon, 08 Jun 2015 05:14:15 -0400 Original-Received: from smtpgw03.sap-ag.de ([155.56.66.98]:35939 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z1t8F-0000kc-M3 for emacs-devel@gnu.org; Mon, 08 Jun 2015 05:14:11 -0400 Thread-Topic: antlr-mode.el - need some support by python.el Thread-Index: AQHQnhJn02VwMpjAIE6bq0LznyyOqJ2eMvhRgAQm0HA= In-Reply-To: <5571E070.9050905@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.98 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:187090 Archived-At: >> Many modes use more than the current line / code chunk in their >> indentation calculations. For example, in `c-guess-basic-syntax', the >> outer language constructs are also considered. If the indentation >> engine of the inner mode just see the code chunks, there is a potential >> problem... > I think the string value is not ideal, because then the inner mode can't= =20 > cache syntactic information, and reuse it between chunks. This is=20 > something we probably want to facilitate. Originally, I had some inner mode dependent value here. Stefan had objections, because mode-specific stuff in a generic value is not that nice (agreed) and the outer mode would need to know inner mode internals. For caching, I can imagine the following: - the inner mode does at least cache the syntactic info for the last string (for the grammar case, you would almost ever have a cache hit) - the inner mode is encouraged to change PREVIOUS-CHUNKS inside `prog-indentation-context' to the inner mode specific value. The outer mode can retrieve the value after the call and use it for further calls. > Adapting the current major mode indentation code to work with either=20 > kind of PREVIOUS-CHUNKS value, looks non-trivial as well. For the string value (for grammars =3D the case I am interested in): looks manageable - I could later add a corresponding patch to cc-mode, see below - in general, the inner mode could insert the string at START inside a `call-with-transparent-undo' (XEmacs, whatever the Emacs equivalent is) The get-previous-chunk function case (for literate programming =3D the case Stefan and you, Dmitry, were interested in): I agree, this is non-trivial (see my remarks back in Feb/Mar). > I don't currently have a better suggestion, though. But this proposal=20 > could use a corresponding patch to cc-mode. Well, I really like to see something included in Emacs before I spend more time on this. My suggestion: 1. Stefan tells me what he had against the "should" in the docstring of `prog-widen' (and/or sends me a corrected docstring). I reduce the patch to NOT include PREVIOUS-CHUNKS (and use the widen-feature of narrow-to-region ;-)) 2. If that is included, I reintroduce PREVIOUS-CHUNKS and include a corresponding patch to cc-mode - but only for the "string/grammar case" -- Christoph