Selector interpolation: Shouldn't variables be evaluated before the code parse?

[cusspvz]

I'm working with less for a while. I've used selector interpolation about 4 or 5 times, but I did not had the need to include nested classes over it until now.

So I've came across on what I think it could be a potential issue.
Here's a test case:

Input

@theGoodThings: ~".food, .beer, .sleep, .javascript";

@{theGoodThings} {
  &:after {
  font-weight: bold;
  }
}

Output

.food, .beer, .sleep, .javascript:after {
  font-weight: bold;
}

Output I was expecting:

.food:after, .beer:after, .sleep:after, .javascript:after {
  font-weight: bold;
}

[cusspvz]

ping @cloudhead @lukeapage @matthew-dean @seven-phases-max @Synchro @SomMeri

[seven-phases-max]

See #1546 (also related to #1328).
(It's not really about evaluating variables its more about recognizing a list of selectors in a variable value. For sure, the feature (if implemented) should not involve any escaping as it has the directly opposite purpose).

[seven-phases-max]

Closing as duplicate of #1546.

[matthew-dean]

Right. In this case, you're dumping in a string value as is. Less doesn't know what's in the string.

[cusspvz]

@seven-phases-max @matthew-dean thank you for your answers. Is there anything I could do to help less to recognize selectors as a variable value?

[seven-phases-max]

It's a sort of complicated thing unfortunately. As the feature may require some less or more major things here and there to be reworked/refactored and potentially may require (at least the way I see it) a complete change of how selectors are stored in the tree internally. There were some discussions spread all over a few threads (so I can't redirect you to any particular one for a detailed info), but the main question to decide was about if we'll need a special selector function or not (this then will affect which of two routes the code-base will go and how drastical it could be since internally the selector-tree-storage actually affects quite a lot of the core features (e.g. mixin/extend look-up) and will affect a lot of other proposed features (e.g. mixin/extend look-up of an interpolated selector and so). Initially none such feature as selector interpolation existed at all, so the selector-tree-storage was designed w/o anything like that in mind, so many new related features later come as quite dirty hacks on top of each other (and will become more and more dirty and difficult to improve w/o refactoring).

In other words, to do something one will need to learn how all this works now and then find/estimate what can be done to improve it (or a sort of).

[matthew-dean]

This is fixed in #1421.