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: Wed, 18 Feb 2015 16:10:36 +0000 Message-ID: References: <54E40954.7000706@yandex.ru> <54E4AFE5.1070208@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 1424275861 16310 80.91.229.3 (18 Feb 2015 16:11:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 18 Feb 2015 16:11:01 +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 Wed Feb 18 17:10:59 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 1YO7DF-0001C1-OP for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2015 17:10:57 +0100 Original-Received: from localhost ([::1]:51639 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YO7DF-00084j-0Z for ged-emacs-devel@m.gmane.org; Wed, 18 Feb 2015 11:10:57 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44230) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YO7D0-00084d-Tj for emacs-devel@gnu.org; Wed, 18 Feb 2015 11:10:43 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YO7Cw-0004oW-Pl for emacs-devel@gnu.org; Wed, 18 Feb 2015 11:10:42 -0500 Original-Received: from smtpgw03.sap-ag.de ([155.56.66.98]:59600 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YO7Cw-0004oC-CS for emacs-devel@gnu.org; Wed, 18 Feb 2015 11:10:38 -0500 Thread-Topic: antlr-mode.el - need some support by python.el Thread-Index: AQHQSyxuxsXFZU5LQTeH9ayNQUY/OZz2iSBCgAALEaA= In-Reply-To: <54E4AFE5.1070208@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:183255 Archived-At: >> If we would have two narrowings, then the "functional" should >> always be a subset of the "visible" narrowing (and the "functional" >> should be made somehow detectable for the user by a different background >> color). Otherwise, things would get very confusing for the user. > I believe it will be in reverse. Though many editing commands will have=20 > to respect the "visible" narrowing, instead of "functional". Well, if we think that the advantage of a 2nd narrowing is greater then the disadvantage (complexity) -I am not convinced-, then we should at least reduce the disadvantage. In this case, this means that the "functional" narrowing should be visible - I am not sure how to do it if the "visible" narrowing is smaller... >> LEFTMOST-COL, likewise, can by added by the calling function. No need to >> make the submode's indentation function be aware of it. > > As Stefan has mention, it would first require that the mode not just > indents the line, but also has a function which returns the correct > indentation. > Not necessarily: you also can adjust the indentation after the submode=20 > applies it. I do exactly that, but it does not work for python due to its cycling functionality. (It is also not ideal buffer-undo-list -wise.) >> Even if we have this, things are not that easy - we start with the >> non-Python case: >> - some indent calculation return the correct indentation based on the >> indentation of previous lines - here, I won't have to add anything >> (given that I calculate the correct index of the first SUB-line myse= lf, >> which I can do), except sometimes for top-level constructs >>> - some indent calculation return the correct indentation based on the > syntactic context - here, I would have to add LEFTMOST-COL > Currently, I'm using this trick: narrow, then add LEFTMOST-COL at the=20 > beginning of the region. In the end, remove them. Well, this does not work always. Let us assume that ANTLR would support EmacsLisp code generation (there is actually some experimental plugin somewhere) - in this case, the context of the actions would be some implicit progn in some function. A rule would look like direct_declarator : ( IDENTIFIER { (when (and (> (len $declaration) (isTypedef $declaration))) (print "define type etc")) (do-something) (do-something-more) } | '(' declarator ')' ) declarator_suffix* ; The action would be only almost correctly indented - but not the last two actions like (do-something). Reason: these sexps are top-level in the code chunk, and Emacs Lisp indents it not relatively to some previous line, but at column 0. We could again do some workaround if the indentation of the sub mode indents at column 0 (that is exactly what I am currently doing), but it again does not work for Python due to its indentation cycling. Christoph