From: "Jostein Kjønigsen" <jostein@secure.kjonigsen.net>
To: emacs-devel@gnu.org
Cc: Stefan Monnier <monnier@IRO.UMontreal.CA>
Subject: Re: Regarding Emacs, js.el, template-strings and syntax-tables
Date: Thu, 24 Aug 2017 14:13:38 +0200 [thread overview]
Message-ID: <1503576818.100758.1083575560.7079FD9A@webmail.messagingengine.com> (raw)
In-Reply-To: <jwvinhd457l.fsf-monnier+gmane.emacs.devel@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3358 bytes --]
On Thu, Aug 24, 2017, at 12:53 PM, Stefan Monnier wrote:
> Indeed this problem has been with us in sh-script.el for many years.
> There are several different aspects at play:
> - how should font-lock display `name`. Should it have a normal
> face as> if it weren't inside a string? Or should have a kind of combination> of string-face and something else?
I'd vote for "plain" face, and name being styled as it would have been
outside the string-context. If a mode-author wants to fancy it up, we
should definitely have a way to easily accommodate that though.
Having a separate expression-in-string-or-comment face is probably the
best approach in that regard.
> - how should we handle nestings of such constructs.
That's a good question, but I think a even better question would be to
ask what that would look like, and *if* we should strive to support it
in the first place.
The most contrived (again JS) example I can think of would be inline code-
references in a comment in a expression in a string. Something like:
let greeting = "Hello, ${ /** @name string here refers to the
employer, not the employee! */ employee_name }";
If we were to support these kind of endless constructs (which I'm sure
someone will find a way to make), we would need to consider this a level
of nesting, just like we do with parens and curly braces and what not.
> - several parts of Emacs like to know if we're inside
> code/string/comment (usually using (nth [3|4|8] (syntax-ppss))).
> Should these all consider "name" as being inside code?
> Or inside string? Or should we revisit all those cases one-by-one?
It's hard to come up with a blanket solution for this, just like that. I
definitely recognize the problem though.
In increasing the expressiveness of the syntax-construction, it's
generally hard to say "all new occurrences of this new construct map
perfectly to this old understanding of the same property" (as in the
Liskov Substitution Principle).
If a change means revisiting cases one by one, the Emacs ecosystem
will be in a state of mess for years to come, so that's clearly not
an option.
How about instead extending (syntax-ppss) to keep all existing
behaviour for all existing properties, but include some new ones
with more information? Then mode-authors which wants to exploit
these new properties can probe for those in a reasonable backwards-
compatible manner?
Ideally these extra properties should contain at least the following:
* is in escape string or comment
* start of this-level string/comment escape-sequence (nth 8 contains the
start of the string/comment)* level of string/comment-expression nesting
As far as I can see, that should about cover it.
> In sh-script, we use syntax-propertize to make sure the whole
> string and> its contents is all considered as a string and nothing else. This was> the simplest solution and probably corresponds to the current behavior> of js.el (and typescript.el) as well.
>
While obviously the simplest, it's syntactically *inaccurate *and this
inaccuracy is causing issues in other packages who rely on accurate syntax-
information.
It would be really nice if we could have our cake and eat it too.
--
Jostein Kjønigsen
jostein@kjonigsen.net 🍵 jostein@gmail.com
https://jostein.kjonigsen.net
[-- Attachment #2: Type: text/html, Size: 4989 bytes --]
next prev parent reply other threads:[~2017-08-24 12:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-08-24 6:56 Regarding Emacs, js.el, template-strings and syntax-tables Jostein Kjønigsen
2017-08-24 10:53 ` Stefan Monnier
2017-08-24 12:13 ` Jostein Kjønigsen [this message]
2017-08-24 12:17 ` Jostein Kjønigsen
2017-08-24 13:47 ` Stefan Monnier
2017-08-24 14:04 ` Stefan Monnier
2017-08-24 12:31 ` Anders Lindgren
2017-08-24 14:20 ` Stefan Monnier
2017-08-27 16:37 ` Dmitry Gutov
2017-08-24 14:22 ` Stefan Monnier
2017-08-24 15:19 ` Anders Lindgren
2017-08-29 13:36 ` Stefan Monnier
2017-08-29 13:49 ` Anders Lindgren
2017-08-30 2:22 ` Richard Stallman
2017-09-01 12:14 ` Anders Lindgren
2017-09-04 23:40 ` Dmitry Gutov
2017-09-05 7:00 ` Anders Lindgren
2017-09-05 8:25 ` Dmitry Gutov
2017-09-05 9:30 ` Anders Lindgren
2017-09-05 9:53 ` Dmitry Gutov
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1503576818.100758.1083575560.7079FD9A@webmail.messagingengine.com \
--to=jostein@secure.kjonigsen.net \
--cc=emacs-devel@gnu.org \
--cc=jostein@kjonigsen.net \
--cc=monnier@IRO.UMontreal.CA \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.