[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Regarding Emacs, js.el, template-strings and syntax-tables

From: Stefan Monnier
Subject: Re: Regarding Emacs, js.el, template-strings and syntax-tables
Date: Thu, 24 Aug 2017 10:04:55 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.50 (gnu/linux)

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

If we want to handle nesting, the easiest solution is either "color
everything like a string" or "color `name` as if it weren't in a string".

Anything in between will tend ask "how do I distinguish
a string-within-a-string from a string-not-within-a-string, and what
about a string-within-a-string-within-a-string?".

So I tend to agree with you here.  But Anders Lindgren seems to disagree.

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

For sh-script we definitely need to support it, because it's often used
for things equivalent to nesting function calls as in (f1 (f2 z (f3 x) y)).

   x = "blabla $(echo "$foo" | bar $(find . -print))"

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

Yes, at the level of syntax-tables (and parse-partial-sexp) we'll
definitely want to handle arbitrary nestings.  W.r.t how to display it,
we will probably prefer to disregard the nesting level and only pay
attention to the top-level or the bottom-level (or both).

> How about instead extending (syntax-ppss) to keep all existing
> behaviour for all existing properties, but include some new ones
> with more information?

Yes, of course, that's what we'd do.  I think we'd add yet-another
element which would work a bit like the (nth 9 ppss) but would keep
a stack of states (POS . PPSS) rather than a stack of buffer positions.

> It would be really nice if we could have our cake and eat it too.

I love cake,


reply via email to

[Prev in Thread] Current Thread [Next in Thread]