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 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 > > >