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: python.el patch proposal: Respect `prog-indentation-context'. Date: Mon, 22 Jun 2015 13:38:00 +0000 Message-ID: References: <87lhffjv0j.fsf@tromey.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1434980316 23329 80.91.229.3 (22 Jun 2015 13:38:36 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 22 Jun 2015 13:38:36 +0000 (UTC) Cc: "fgallina@gnu.org" , "emacs-devel@gnu.org" To: Tom Tromey Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jun 22 15:38:31 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 1Z71vh-0001Wv-8E for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 15:38:29 +0200 Original-Received: from localhost ([::1]:40192 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z71vg-0005fJ-1l for ged-emacs-devel@m.gmane.org; Mon, 22 Jun 2015 09:38:28 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60396) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z71vM-0005f0-7T for emacs-devel@gnu.org; Mon, 22 Jun 2015 09:38:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Z71vL-0004cQ-3O for emacs-devel@gnu.org; Mon, 22 Jun 2015 09:38:08 -0400 Original-Received: from smtpgw01.sap-ag.de ([155.56.66.96]:58513 helo=smtpgw.sap-ag.de) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Z71vH-0004bn-03; Mon, 22 Jun 2015 09:38:03 -0400 Thread-Topic: python.el patch proposal: Respect `prog-indentation-context'. Thread-Index: AQHQqs+U4G/9zyc6Rj2j25AJvOm6JJ24i2NA In-Reply-To: <87lhffjv0j.fsf@tromey.com> 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:187376 Archived-At: > I'm supportive of your project. I think it is great to see some > advances in this area in the core. Thanks. I have to admit, my change is just one step of many... Christoph> (save-restriction Christoph> - (widen) Christoph> + (prog-widen) Christoph> (let ((ppss (save-excursion Christoph> (beginning-of-line) Christoph> (syntax-ppss)))) > I'm curious how you plan to extend your approach to handle > syntax-ppss as well. It seems to me that the sub-mode has to be able > to change the syntax table at the mode boundaries At the moment (in my private version of antlr-mode, which will be release when I could have pushed my proposed change), I just dynamically bind `syntax-ppss-cache' and `syntax-ppss-last' around the call of `python-indent-line'. Later, I will probably also set the syntax table and related variables. It would be excellent if every prog-mode would have a -init-syntax-variables function which I could call for that purpose. In reality, the outer mode cannot support an inner mode with a complete different (lexer) syntax (without care by the users). For example, I have the following comment ;; * Some constructs of languages (in actions) which are highly un-C-ish m= ight ;; bring Emacs (and probably ANTLR) out of sync: e.g. regexp literals in ;; Perl, character and percent literals in Ruby. ...and I can remove the "probably", see the ANTLR3 distribution, ANTLR3.g, rule NESTED_ACTION: the ANTLR tool just counts the braces outside C-ish string/char literals and comments - so it is questionable whether to really support a complete different syntax table or even fancy things like `syntax-propertize-function' > and furthermore that this also has to be done during font-lock so that > syntactic font-locking works correctly in all the parts of the buffer. Quite surprisingly, the syntax highlighting already looks quite good without any special care for syntax tables (just js--font-lock-keywords-3 were not nice). But you are right, one should aim for improvements here, too. At the moment, it has lesser priority for me - after all, wrong syntax highlighting just corrupts the appearance of the code whereas wrong indentation corrupts the code itself. I still update the antlr-mode to have all its feature available for ANTLR v3 and v4 (options and makefile dependencies are still missing). Then quite some cleanups are necessary (I still does not use syntax-ppss in the mode itself as this feature was not available when the mode was written). - Christoph