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/

Reply via email to