emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: python.el patch proposal: Respect `prog-indentation-context'.


From: Wedler, Christoph
Subject: RE: python.el patch proposal: Respect `prog-indentation-context'.
Date: Mon, 22 Jun 2015 13:38:00 +0000

> 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 <prog>-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 might
;;    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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]