camertron/rux

Maintain the same number of code lines?

Opened this issue · 2 comments

Admirer of Rux from afar, just starting to play around with it in earnest…super cool.

One question I have is: I think Rux's Ruby output code has more lines of code…aka additional newlines in places. Something ERB tries to do for example is have the source code on the same output code lines, so when there's an error, the line where the error occurred matches up with the source. I've had to jump through some hoops when working on Serbea to keep that 1:1 line correlation.

Any thoughts on how/if Rux could keep a source/output line correlation for stacktrace purposes?

Awesome, thanks for taking it for a spin!

This is a good question and one I've been thinking about quite a bit lately. I didn't know that ERB emits code on the same line as the original, that's pretty cool. Originally I was thinking about implementing something akin to source maps. The gem could provide a method for converting a Ruby stack trace to a Rux one, for example. Lots of complexity and possibility for bugs down that road though. Correlating lines could be a good way forward. It's really nice to be able to emit source code without worrying about spaces, newlines, etc, but in service of making the dev experience better, that's probably worth reconsidering.

mbj commented

Speaking as the author of unparser, the library that is used underneath rux. Its very unlikely that unparser can support this use case.

The reason is mostly: Unparser is a "generic" unparser, meaning it exlusively looks at the AST nodes turning them into concrete syntax that parses to the same AST nodes. It does not take any other piece of information, by design.

The extra information on when to create a new line and when not: Is not part of unparsers signalling. And its unlikely to be added. Ruby is not a particularly friendly language to generate. And is in a tight local optimum right now in terms of maintenance I wish to spend on it.

I wounder if there may be a better mechanism, like source maps (which would be easier to add to unparser), to allow correlation of stack traces with rux templates.