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, 16 Feb 2015 14:38:45 +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 1424097567 2845 80.91.229.3 (16 Feb 2015 14:39:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 16 Feb 2015 14:39:27 +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 Mon Feb 16 15:39:21 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 1YNMpU-00028X-RX for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 15:39:21 +0100 Original-Received: from localhost ([::1]:39946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNMpU-0007MX-Bv for ged-emacs-devel@m.gmane.org; Mon, 16 Feb 2015 09:39:20 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35030) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNMp2-0007GE-SH for emacs-devel@gnu.org; Mon, 16 Feb 2015 09:38:54 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YNMoz-0001c8-Me for emacs-devel@gnu.org; Mon, 16 Feb 2015 09:38:52 -0500 Original-Received: from smtpgw04.sap-ag.de ([155.56.66.99]:59493 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YNMoz-0001b6-8S for emacs-devel@gnu.org; Mon, 16 Feb 2015 09:38:49 -0500 Thread-Topic: antlr-mode.el - need some support by python.el Thread-Index: AQHQR8T1xsXFZU5LQTeH9ayNQUY/OZzzXDAw 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.99 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:183162 Archived-At: > Thanks, see comments below. Thanks for the comments - below the updated patch for prog-mode.el. I use START/END as in `narrow-to-region'. >> Instead, I added a paragraph in the doc string that sub modes can define >> their own `SUB-extra-indentation-context', which would have the >> additional advantage that the variable content is documented. > Since this is a specific to a particular submode and both the inner-mode > and the outer-mode will need to agree on it, there's no need to document > it in the generic part of the interface. Hm, I actually like these kind of cross-links in comments. Otherwise, someone could read this docstring and ask themselves "...and where can I specify that my code snippet is a sequence of statements and not a seq of declarations?". With the comment they know that the sub mode might specify such a possibility if they are lucky. But it is up to you whether you include this paragraph. >>>> [...] 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 initia= l >>> context at MIN. >> ... if scan-lists, mode-specific skip-comments etc are prepared for this= . > That's the responsibility of the sub-mode. 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. >> as the previous chunks are not part of the ANTLR grammar buffer (but >> of the ANTLR code generation code) - I could just fake some context >> _string_. (Providing the context as a string would be actually the >> easiest for me.) > Hmm.. you mean you'd specify the c-extra-indentation-context as > a "pseudo previous chunk of code"? That's a nice idea, in that it would > not encode specific knowledge about CC-mode, only specific knowledge > about the C language, so it'd be fairly generic. So maybe > prog-indentation-context could come with a PREVIOUS value which could > either be a string (so the indentation should pretend that the code was > preceded by this string) or some other value (e.g. a function, or a list > of buffer positions) which gives access to the previous chunks. Yes, I like to see some generic support in the future, both for literate programming and my use case. To get it, the path to that future should be easy for the authors of the sub-mode. Therefore, I think that it will involve some mode-specific `SUB-extra-indentation-context', whose exact format will just be of lesser importance in later stages. I would see the following stages of support by the major mode SUB: 1. SUB supports START/END and LEFTMOST-COL in 'prog-indentation-context' 2. SUB provides a function which sets the syntax table and all variables which are necessary to properly run its indentation code and functions used as font-lock highlight functions (and does not set variables which are not necessary for these tasks) 3. SUB supports `SUB-extra-indentation-context' (with a format which is most easily to consume by SUBs indentation code) 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. Christoph diff -c prog-mode.el.\~24.4\~ prog-mode.el *** prog-mode.el.~24.4~ 2014-04-27 19:41:16.000000000 +0000 --- prog-mode.el 2015-02-16 14:26:58.376762000 +0000 *************** *** 41,46 **** --- 41,76 ---- map) "Keymap used for programming modes.") =20 + (defvar prog-indentation-context nil + "Non-nil while indenting lines considered as belonging to a sub mode. + There are languages where part of the code is actually written in + a sub language, e.g., a Yacc/Bison or ANTLR grammar also consists + of plain C code. This variables enables the major mode of the + main language to use the indentation function of the sub language + for lines belonging the code of the sub language. +=20 + When a major mode of such a main language decides to delegate the + indentation of a line/region to the indentation engine of the sub + mode, it is supposed to bind this variable to non-nil around the call. +=20 + The non-nil value looks as follows + ((START . END) LEFTMOST-COL) +=20 + START to END is the region consisting of code of the sub mode. + LEFTMOST-COL is the minimum column the indentation engine of the + sub mode should choose (instead of 0). +=20 + It is the task of the calling main mode to (temporarily) set the + syntax table and related variables to values suitable for the sub + mode, and to call `syntax-ppss-flush-cache' if necessary. +=20 + If the indentation engine of the sub mode SUB depends on some + global context, it may introduce a variable named + `SUB-extra-indentation-context', which is to be bound like this + variable by the main major mode. For example, cc-mode might + define `c-extra-indentation-context' which is to be bound to a + list of SYNTACTIC-SYMBOL as explained in `c-offsets-alist'.") +=20 (defun prog-indent-sexp (&optional defun) "Indent the expression after point. When interactively called with prefix, indent the enclosing defun