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: Tue, 17 Feb 2015 10:55:54 +0000 Message-ID: References: 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 1424170583 10197 80.91.229.3 (17 Feb 2015 10:56:23 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 17 Feb 2015 10:56:23 +0000 (UTC) Cc: =?iso-8859-1?Q?Fabi=E1n_E=2EGallina?= , "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 17 11:56:08 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 1YNfoy-0001oQ-Ld for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2015 11:56:04 +0100 Original-Received: from localhost ([::1]:44701 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNfoy-0005XT-17 for ged-emacs-devel@m.gmane.org; Tue, 17 Feb 2015 05:56:04 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNfou-0005XO-UT for emacs-devel@gnu.org; Tue, 17 Feb 2015 05:56:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNfor-0008S3-M3 for emacs-devel@gnu.org; Tue, 17 Feb 2015 05:56:00 -0500 Original-Received: from smtpgw01.sap-ag.de ([155.56.66.96]:38990 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNfor-0008Rh-DF for emacs-devel@gnu.org; Tue, 17 Feb 2015 05:55:57 -0500 Thread-Topic: antlr-mode.el - need some support by python.el Thread-Index: AQHQSh4IxsXFZU5LQTeH9ayNQUY/OZz0qdsQ In-Reply-To: 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:183189 Archived-At: >> To get support by the authors of potential sub-modes, I would really >> like to keep the effort for the sub-modes small. >> Given that the indentation code of many prog-modes is probably the most >> complex part, I would understand if the authors do not want to change it >> considerably just to support some special-topic major mode. > But it's not like there are many other options. The options are either: > - the submode doesn't know how to use previous chunks, so it doesn't > work correctly when the code is split into related chunks. > - the submode does know how to parse and connect the various chunks. That is not the difference we have: - You want to connect the chunks on-the-fly during the indent calculation. - I want to first connect the chunks and then do the indent calculation, or to be more exact: I want to first connect the previous chunks, get the parse state at the end of these chunks, and use this parse state as the initial one when indenting the current chunk. This is exactly the difference between 5 (yours) and 4 (mine) below - and the nice thing is that the submode can decide for itself whether to do it like 4 or 5. >> 4. SUB provides a function which creates a valid value for >> `SUB-extra-indentation-context' - valid arguments for that function >> would either be a string, or a list of buffer ranges. >> For C (assuming that a valid value for `c-extra-indentation-context' >> would look like the return value of `c-guess-basic-syntax'), this >> function could simply put the string / buffer chunks into a >> temporary buffer and call `c-guess-basic-syntax' at eob. >> In my use case, I would run this function once - in the literate >> programming case, you would run it whenever you delegate the >> indentation to the sub mode. >> 5. If SUB decides that it can support the "multi-chunk case" directly >> in the indentation code (e.g. for performance improvements), it can >> do so without any change in the call by the main mode - the function >> introduced in stage 4 would then simply return the buffer-positions. > I don't see much difference between 4 and 5: basically, the difference > is between putting the code in the outer-mode or in the submode, but > it'll be the same code. Actually not. In both cases, the submode provides the code. In 4, the sub mode provides a function to compute the initial parse state given the string / chunks. It can do that quite simply by inserting it/them into a temporary buffer and using a function which computes the syntactic context at the end of that buffer - most major mode already have such a function. In other words: the effort for the submode is small. In 5, they follow your idea: >>>>>> [...] that would require them to create a temporary buffer for the >>>>>> indent calculation. >>>>> Not necessarily: the submode can just go to the end of the previous >>>>> chunk, compute some state at that position and use that state as init= ial >>>>> context at MIN. >>>> ... if scan-lists, mode-specific skip-comments etc are prepared for th= is. >>> That's the responsibility of the sub-mode. To me, that seems to be more work. And it would not be enough for me, as my previous chunk is not part of the buffer, but provided by a string. Performance-wise, this could be better in the literate programming use case, but not in my use case. > In any case your patch looks good, feel free to install it. If I might come back to your offer from last month (concerning antlr-mode.el, actually) - it would be excellent if you could apply the prog-mode.el.patch to the Emacs repository... Christoph