Second, I think the evaluation stack needs to be re-thought a little bit.
Well, now. I reworked the API so that every Evaluate call returns an IEnumerable<Node>. While working through that change, I also eliminated a bunch of weirdness regarding e.g. mixin guards -- now, when a guarded call results in nothing, it no longer produces a spurious empty line.
Ideally, the Node itself should know how to evaluate itself given the current environment.
That way, lookups should become noticeably cheaper, and eventually I hope to get rid of Env.Frames entirely.
Have I mentioned how much I dislike the regex-based parser already? Having semicolon-separated argument lists in mixin calls is really hard to get right. I spent about an hour on Friday cooking up a regex that would reliably let me detect them. It worked -- except in one case, where the tokenizer has helpfully already recognized the first argument as a quoted string, and hence only matches against that string so it's difficult if not impossible to work with the surrounding context.
See above :)
There's been a nasty threading bug since 1.5.0. :(
It should have been obvious to me, given that I know the parser is stateful. But noooooo.
And it doesn't help that I've let the issue lie unfixed for several months after the first report. In my defense though, I bought a house and have been renovating it. :P
I've got a little question, I don't think it's covered by the doc (I don't even know if it's implemented yet): I'm looking to build a mixin where you can pass @property-name and @property-value ( @{property-name}: @{property-value}; ) such as explained in this less.js thread: less/less.js#36
It seems to work when I prefix the property-name variable but not when a line starts with @
Am I doing something wrong ? Is there a proper way to achieve this ? Should I open an issue ticket ?
can`t find any news about this project
is it alive?
is it alive?
I try to fix bugs every now and then, but my motivation for that is not very high at the moment -- the reason being that parts of the dotless codebase are hard to work with, and for newer projects, using less.js directly is fairly straightforward.
The Regex-based parser is a bit of a pain in my opinion -- adding support for complex constructs is a lot more difficult than it would need to be. I'm sort of tinkering with a potential replacement, but it's still a long way from being complete. It's an ANTLR4 grammar based parser, with an evaluation pipeline that tries very hard to be more straightforward than some of the hairier parts of dotless.
I have a lot of projects like that as well.
i have to
And I'd love to support detached rulesets and whatnot, but while not impossible, it's tedious to make work with the current parser.
ok. today i have to organize my less files like this
//main.less file
@import "one-cool-stuff.less";
@import "another-cool-stuff.less";
@import ....and my bundle definition looks like
bundles.Add(new LessBundle("~/bndls/css/").Include(
"~/Content/less/main.less"
));thats only the way if i want share variables and mixins in this separated less files
is this correct?
Of course, that does have the benefit of supporting tooling better (for autocompletes and such).
assume i have this file structure
app
control1
control1.js
control1.html
control1.less
control2
control2.js
control2.html
control2.lessand so one
so i allready can bundle js - its native
i have own bundle for html templates, its simple
and i have to get the last one - less bundle for that purpose