unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Wedler, Christoph" <christoph.wedler@sap.com>
To: Tom Tromey <tom@tromey.com>
Cc: "fgallina@gnu.org" <fgallina@gnu.org>,
	"emacs-devel@gnu.org" <emacs-devel@gnu.org>
Subject: RE: python.el patch proposal: Respect `prog-indentation-context'.
Date: Mon, 22 Jun 2015 13:38:00 +0000	[thread overview]
Message-ID: <F9C2521BBF380A4A97379009991555E685BA071B@DEWDFEMB17C.global.corp.sap> (raw)
In-Reply-To: <87lhffjv0j.fsf@tromey.com>

> 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	other threads:[~2015-06-22 13:38 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 14:05 python.el patch proposal: Respect `prog-indentation-context' Wedler, Christoph
2015-06-19 20:36 ` Tom Tromey
2015-06-22 13:38   ` Wedler, Christoph [this message]
2015-06-29 18:53     ` Tom Tromey
2015-06-30 13:53       ` Stefan Monnier
2015-07-02  9:13       ` Wedler, Christoph
  -- strict thread matches above, loose matches on Subject: below --
2015-07-02  9:16 Wedler, Christoph

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=F9C2521BBF380A4A97379009991555E685BA071B@DEWDFEMB17C.global.corp.sap \
    --to=christoph.wedler@sap.com \
    --cc=emacs-devel@gnu.org \
    --cc=fgallina@gnu.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).