[FR] Expose ParserState of currently invoked function

[am11]

As per the discussion that transpired at: sass/node-sass#646 (comment)

As an implementer I want to propagate the contextual information, in particular, the file path, line and column numbers to the end-user so that they know from where the function was called.

[mgreter]

Technically this translates to beeing able to access the ParserState of the currently invoked function.
This is pretty much the same as the API for accessing the import stack (just return a new sruct type).

[chriseppstein]

Related: #1227

[mgreter]

This is pretty much possible now, beside fetching line and column numbers!

[bdkjones]

Any updates on this? I'm looking to access the filename and line numbers in my custom function that handles @warn and @debug statements.

[xzyfer]

We have no plans to further this until we reach Sass compatibility it 3.4. This increases the maintenance surface area and our hands are full atm.

[mgreter]

Some ground work was already done and included in libsass, but not that we could yet craft a good and future proof API (we need to further refactor how we internally account for these states).

[bdkjones]

Could it potentially be easier to simply have @warn and @debug handled by Libsass itself, rather than rely on the custom function approach?

99% of people are just going to write functions that log the message, line number and file of these warnings, right? Since there's no real customization to be done, what benefit is there in relying on the custom function approach? Does it maybe just make more sense to have Libsass log the output like it does for any other error?

Sent from my iPhone

On Apr 21, 2016, at 04:46, Marcel Greter notifications@github.com wrote:

Some ground work was already done and included in libsass, but not that we could yet craft a good and future proof API (we need to further refactor how we internally account for these states).

—
You are receiving this because you commented.
Reply to this email directly or view it on GitHub

[mgreter]

Both warn and debug already take the same path as other custom functions. So no, it would rather be more difficult to handle warn etc. different that other custom functions.

Quoting from corresponding node-sass issue: sass/node-sass#895 (comment)
I don't think that sass_compiler_get_last_import will work reliably for custom functions. I stated before that the main problem is that libsass does not preserve the information needed ATM. The problem is that we read/parse/resolve the input/import files into an AST tree that will contain a function call op. Once we evaluate/execute that function call, the context of the actual import is no longer available (we only have one ast tree). That is what #1037 is all about. As I also wrote above IMO there is currently only one way to actually get that info via fb->pstate().path already. But that would be just a "crutch" for now, as the import stack should be available to custom functions (as other stuff). But nobody yet came around to actually solve/implement the missing pieces for libsass.

The easiest way I currently see is to add a new "import" stub ast node to the ast tree, so we can re-create the actual import stack in the eval phase where custom functions are actually executed. Once that is done, it should be straight forward to implement the rest. Biggest part here is probably to design a forward compatible and future proof C-API.

[mgreter]

This was implemented with #2251

[am11]

@mgreter, this is a huge feature and we can do much on consumer side IMO. Kudus! 🏆 🎉

For node-sass, it would require a non-CAPI implementation via V8/nan wrappers, for which I can spare sometime if no one else is taking it. :)

For libsass-net, I will try to take inference with perl-libsass implementation as we did for all the other features in FFI way.

@chriseppstein, @darrenkopp, is it a valid option if we have a dontnet bring-up under Sass organization account? If so, on which repo we can further this discussion? This will give the project some boost and comparatively fast updates. Out of interest, I am willing to contribute to keep all projects under organization in sync, with all these kind of awesome auxiliary features Marcel has implementing 😎

[darrenkopp]

@am11 fine with me.

[xzyfer]

@darrenkopp please join us in Slack https://libsass-slack.herokuapp.com/