[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)).
E.g.:
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,
Stefan
- Regarding Emacs, js.el, template-strings and syntax-tables, Jostein Kjønigsen, 2017/08/24
- Re: Regarding Emacs, js.el, template-strings and syntax-tables, Stefan Monnier, 2017/08/24
- Re: Regarding Emacs, js.el, template-strings and syntax-tables, Anders Lindgren, 2017/08/24
- Re: Regarding Emacs, js.el, template-strings and syntax-tables, Stefan Monnier, 2017/08/24
- Re: Regarding Emacs, js.el, template-strings and syntax-tables, Anders Lindgren, 2017/08/24
- Re: Regarding Emacs, js.el, template-strings and syntax-tables, Stefan Monnier, 2017/08/29
- Re: Regarding Emacs, js.el, template-strings and syntax-tables, Anders Lindgren, 2017/08/29
- Re: Regarding Emacs, js.el, template-strings and syntax-tables, Richard Stallman, 2017/08/29