e...@emilstenstrom.se writes: > Seems simple enough, right? The problem is: There's no syntax > highlighting in my code editor for the three other languages.
Then you're not using Emacs's mmm-mode, which has been available for a couple of decades. Now, mmm-mode doesn't solve the whole problem -- it doesn't know anything about how the languages are tagged. But this isn't a problem for an Emacs shop, the team decides on a convention (or recognizes a third party's convention), and somebody will code up the 5-line function that font-lock (syntax highlighter in Emacs) uses to dispatch to the appropriate the syntax highlighting mode. AFAICS this requires either all editors become Emacs ;-) or all editor maintainers get together and agree on the tags (this will need to be extensible, there are a lot of languages out there, and some editors will want to distinguish languages by version to flag syntax invalid in older versions). Is this really going to happen? Just for Python? When the traditional solution of separating different languages into different files is almost always acceptable? There are other uses proposed for tagged strings. In combination, perhaps this feature is worthwhile. But I think that on its own the multiple language highlighting application is pretty dubious given the limited benefit vs. the amount of complexity it will introduce not only in Python, but in editors as well. > This makes for a horrible developer experience, where you > constantly have to hunt for characters inside of strings. If this were a feature anyway, it would be very useful in certain situations (for example dynamic web pages), no question about it. But mixed-language files are not something I want to see in projects I work on -- and remember, I use Emacs, I have mmm-mode already. > If I instead use separate files, I get syntax highlighting and > auto-completion for each file, because editors set language based > on file type. This is problematic for your case. This means that the editor needs to change how it dispatches to syntax highlighting. Emacs, no problem, it already dispatches highlighting based on tagged regions of text. But are other editors going to *change* to do that? > But should I really have to choose? Most of the time, I'd say "yes", and you should choose multiple files. ;-) YMMV of course, but I really appreciate the separation of concerns that is provided by separate files for Python code, HTML templates, and (S)CSS presentation. > *Do we need a python language solution to this?* > Could the code editors fix this? There's a long issue thread for > vscode where this is discussed: > https://github.com/Microsoft/vscode/issues/1751 - The reasoning > (reasonable imho) is that this is not something that can be done > generally, but that it needs to be handled at the python vscode > extension level. Makes sense. Makes sense, yes -- that's how Emacs does it, but Emacs is *already* fundamentally designed on a model of implicitly tagged text. Parsing strings is already relatively hard because the begin marker is the same as the end marker. Now you need to tie it to the syntax highlighting mode, which may change over large regions of text every time you insert or delete a quotation mark or comment delimiter. You *can't* just hand it off to the Python highlighter, *every* syntax highlighter that might be used inside a Python string at least needs to know how to hand control back to Python. For one thing, they all need to learn about all four of Python's string delimiters. And it gets worse. I wonder how you end up with CSS and HTML inside Python strings? Yup, the CSS is inside a <style> element inside the HTML inside the Python string which may end in any of four different ways. It's not good enough to add this to the Python highlighter.... Even if Python gets tagged strings, my bet is that the odds are quite bad that any given editor ever supports this application of them. I wouldn't wish this on the devs of any editor except Emacs, which has had it since the late 1990s. Isn't it easier for you to just use Emacs? ;-) Steve _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/2LUHVPJ5LSCS2HUGVQ7KYU25GYHFEKPL/ Code of Conduct: http://python.org/psf/codeofconduct/
