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: Fri, 5 Jun 2015 14:17:00 +0000 Message-ID: References: <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="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1433514008 8344 80.91.229.3 (5 Jun 2015 14:20:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 5 Jun 2015 14:20:08 +0000 (UTC) Cc: =?iso-8859-1?Q?Fabi=E1n_E=2EGallina?= , Dmitry Gutov , "emacs-devel@gnu.org" To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jun 05 16:20:01 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 1Z0sTU-0002Ga-B0 for ged-emacs-devel@m.gmane.org; Fri, 05 Jun 2015 16:19:56 +0200 Original-Received: from localhost ([::1]:47594 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0sTT-0003Ia-PE for ged-emacs-devel@m.gmane.org; Fri, 05 Jun 2015 10:19:55 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44440) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0sQo-0007te-BL for emacs-devel@gnu.org; Fri, 05 Jun 2015 10:17:11 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z0sQi-0000Ao-Gh for emacs-devel@gnu.org; Fri, 05 Jun 2015 10:17:10 -0400 Original-Received: from smtpgw04.sap-ag.de ([155.56.66.99]:55247 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z0sQi-0000AP-85 for emacs-devel@gnu.org; Fri, 05 Jun 2015 10:17:04 -0400 Thread-Topic: antlr-mode.el - need some support by python.el Thread-Index: AQHQnhJn02VwMpjAIE6bq0LznyyOqJ2d6YOg 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:187044 Archived-At: >> +PREVIOUS-CHUNKS, if non-nil, provides the indentation engine of >> +the sub mode with the virtual context of the code chunk. Valid >> +values are: >> + >> + - A string containing code which the indentation engine can >> + consider as standing in front of the code chunk. For example, >> + it can contain a function header to make the code chunk >> + being correctly indented as a function body. >> + >> + - A function called with the start position of the current >> + chunk. It will return either the region of the previous chunk >> + as \(PREV-START . PREV-END) or nil if there is no further >> + previous chunk.") > This is very unclear, so I'm not sure how an inner-mode could make use > of it. 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... Code chunks in grammars (like ANTLR) are valid sub constructs (basically like a function bodies), but are not necessarily valid top/root constructs according to the grammar of the inner mode. This might affect the indentation calculation - and if so, the inner mode hopefully uses the PREVIOUS-CHUNKS specification, e.g. `c-guess-basic-syntax' could use it to compute an initial value for `c-syntactic-context'. In the literate programming case (which I'm less interested in, but you and Fabi=E1n seemed to be), the code chunks are not necessary even valid sub constructs, e.g. a code chunk could just be the "else" clause. Here, it might be even essential that the indentation engine of the inner mode knows the previous code chunks. > Who (and how) decides what the values will be? The outer-mode > or the inner-mode? The outer mode (like the rest of the value) - after all, the preceding part of the docstring was "the major mode of such a main language [...] is supposed to bind this variable" >> +(defun prog-widen () >> + "Remove restrictions (narrowing) from current code chunk or buffer. >> +This function should be used instead of `widen' in any function >> +used by the indentation engine to make it respect the value >> +`prog-indentation-context'. > I don't see a need for "should" here. What else - a "must" (This function is to be used)? >> + (widen) >> + (let ((chunk (cadr prog-indentation-context))) >> + (when chunk >> + (narrow-to-region (car chunk) (or (cdr chunk) (point-max)))))) > Better do > (let ((chunk (cadr prog-indentation-context))) > (if chunk > (narrow-to-region (car chunk) (or (cdr chunk) (point-max))) > (widen)))) OK, I didn't know whether I should rely on the behavior (defined in src/editfns.c) that narrow-to-region might also `widen'... This behavior could be mentioned in the docstring - other possibilties would be: - (when (or (> (point-min) start) (< (point-max) end)) (error ...)) - (narrow--internal (max (point-min) start) (min (point-max) end) -- Christoph