From: Anders Lindgren <andlind@gmail.com>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: emacs-devel <emacs-devel@gnu.org>
Subject: Re: Regarding Emacs, js.el, template-strings and syntax-tables
Date: Thu, 24 Aug 2017 14:31:22 +0200 [thread overview]
Message-ID: <CABr8ebb6Spqapjbp3shWL-Jz4LMkpbY4zer9wC8KNV7Uh_8QRA@mail.gmail.com> (raw)
In-Reply-To: <jwvinhd457l.fsf-monnier+gmane.emacs.devel@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 3718 bytes --]
Hi!
I've been playing around with constructs like that for quite some time,
here are some thoughts on the matter:
--------
If you use a string face with, say, both a background and a foreground
color, it will matter if you *replace* the existing face as opposed to
*prepend* a new face on top of it.
For example, the default Ruby mode replace the face, which doesn't look
good when the string face has a background color:
"Hello #{name}"
With *prepend* it would have looked like:
"Hello #{name}"
In other words, the font-lock rule should use "prepend" and not "t" as the
override flag. (I've got it on my todo-list to change a lot of "t":s to
"prepend" but haven't had time to do it yet.)
--------
One question is if the delimiters around the expression should be
highlighted as well? In Ruby they are highlighted. In my cmake-font-lock[1]
package I have opted not to highlight them, as it makes it easier to read
the variable name:
"Hello ${name}"
Another reason for this is that CMake supports nested such constructs,
which look better this way:
"Hello ${name${tail}}"
[1] https://github.com/Lindydancer/cmake-font-lock
--------
> 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?
In all cases I've seen, the content is displayed using
`font-lock-variable-name-face', even for the cases where the content is
more complex than a plain variable. I would say that this is OK, as they
stand out and, most of the time, it is a plain variable anyway.
As I said above, using *prepend*, the end result will be a mix of
font-lock-variable-name-face and font-lock-string-face.
--------
> 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?
I see this as a pure syntax highlighting thing, so I would say that
syntax-ppss should treat them as strings.
--------
A side note: I've started to make an inventory of syntax highlighting in
various modes in Emacs, as part of a font-lock regression test suite I've
accumulated over the years. The suite and the inventory is far from
complete, but it might be worth looking into:
https://github.com/Lindydancer/font-lock-regression-suite/blob/master/doc/CommentsOnMajorModes.org
One mode that stands out in this respect is "bat" mode, it handles "%alpha"
but not "%alpha_beta", and doesn't support the construct in strings at all.
-- Anders
On Thu, Aug 24, 2017 at 12:53 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:
> >> function getGreeting(name) {
> >> let greeting = `Hello, ${name}!`;
> >> return greeting;
> >> }
>
> 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?
> - how should we handle nestings of such constructs.
> - 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?
>
> 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.
>
>
> Stefan
>
>
>
[-- Attachment #2: Type: text/html, Size: 6287 bytes --]
next prev parent reply other threads:[~2017-08-24 12:31 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
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 [this message]
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=CABr8ebb6Spqapjbp3shWL-Jz4LMkpbY4zer9wC8KNV7Uh_8QRA@mail.gmail.com \
--to=andlind@gmail.com \
--cc=emacs-devel@gnu.org \
--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.