|
From: | Dmitry Gutov |
Subject: | Re: A vision for multiple major modes: some design notes |
Date: | Sun, 24 Apr 2016 01:36:52 +0300 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.0 |
On 04/21/2016 05:24 PM, Stefan Monnier wrote:
I haven't kept up with this discussion, but I think it'd worthwhile taking a look at what things like SublimeText do for syntax highlighting, because it's a lot more powerful than what font-lock does (IOW it lets you define contexts and is hence closer to a parser whereas font-lock is closer to a lexer), and it might be an interesting starting point for multiple major modes.
Indeed. If anyone's interested, here's some documentation: https://www.sublimetext.com/docs/3/syntax.html
Apparently, Sublime, TextMate, Atom and even Vim all use this or similar approaches. If it were somehow adopted for Emacs (plenty of details would need to be worked out), it would allow describing more complex grammars, and e.g. support a related Ruby feature that I'm having difficulty implementing right now.
Further, if it provides a different mechanism of syntactic parsing, it could be an alternative to using islands to make parse-partial-sexp skip over "foreign" regions. Although, unless we're going to change how we write indentation code, we'd still need to be able to compute the current paren nesting. Ultimately, the new way of defining a grammar could also be a way to define and apply "island" boundaries automatically, without the need for third-party code.
Where it's less likely to help, though, is with being able to combine and reuse settings and code from multiple major modes in one file. For anything like that to happen, the syntax definitions would have to be using a format that's highly composable, at least. I'm not sure I'm seeing that in any of the current grammars in the aforementioned editors. And the current way to combine the functionality from different languages is to call different major mode functions and switch between sets of buffer-local variables. Not sure what's the alternative for that.
[Prev in Thread] | Current Thread | [Next in Thread] |