Make the code generator emit proper line numbers and positions from .vugu files about vugu

[bradleypeabody]

@erinpentecost I'm going to try adding in parse.go and the related files so that Parse() works in htmlx. Wish me luck! :) (And let me know if you have any feedback or comments on this.)

[erinpentecost]

I split out some of the requirements into other files, so you'll probably spot some duplicates if you add in everything I removed. I'm slowly working on an io.Reader wrapper that should let us use the normal module.

[bradleypeabody]

Okay awesome, thanks for the info!

[erinpentecost]

Ok, I finally finished a writer/reader middleware that can convert between byte offsets and lines/columns. Columns won't be accurate if you use runes that encode to more than one byte. Here's the thing: byteline

I'm working on an edit to vugufmt that uses it. Hopefully it works out.

[bradleypeabody]

Awesome! Yeah looks like that could work well. I guess golang/go#31312 never got any further response, bummer.

I'm using your fork of x/net/html for line numbers in some new code I'm writing. If this byteline thing ends up working well, I could switch over to doing that instead.

[bradleypeabody]

Note to self on this:

code generator emit proper line numbers

I actually tried this and it was a disaster for this use case. Trouble is generated Go code has lots of code generated stuff in it that doesn't correspond directly to anything in the vugu file (and it's not uncommon for the error to be at this part). And the //line directive does not provide a way "unset" the line back to the original value.

Possibly just the <script> part could be done - if it's place at the bottom of the output .go file and has a line directive, that could, should be tried.

[morpheus747]

Maybe the best solution is the easy one and just remove the code from inside html and put in a file with a name.
index.html
index_code.go

mymodule.html
mymodule_code.go

So when compiled the errors are in place.

[bradleypeabody]

@morpheus747 You can achieve something close to this right now by having myfile.vugu and myfile.go right along side each other. The component struct definition and methods, etc. can be in myfile.go and that works well and handles most of the issue. However you still end up with things like vg-if attributes that can have expressions in myfile.vugu. So far my only idea of how to provide line numbers for that case is in a regular comment in the generated code. So if vg-if="x" appeared in myfile.vugu on line 100, the generated code could be:

// myfile.vugu:100
if x {

That would probably be better than nothing.

[morpheus747]

two thinks came to mi mind.
1st i don't see that myfile.vugu and myfile.go in the documentation, maybe is a good idea to add that more clearly, i can do that.
2nd if i understand the problem correctly, the vg-if inside the .vugu files are "extracted" converted to "gocode" and inyected in one file. after that, the file is compiled?
In that case maybe a good "start point" is to just leave the temporal pre-assembled file somewhere so you can see it.

Let me understad this more by checking the code so i can add to this problem, because i face this. And can't found the error in the code and was so frustrating.

Can you give me some orientation about where is the code generator or where start to read the code ?

[bradleypeabody]

The generated code (from running vugugen or using tooling that calls it) goes into a file that ends with _vgen.go. Depending on the options used, this can be in a file with the same prefix as the input e.g. myfile.vugu -> myfile_vgen.go or it can be combined into 0_components_vgen.go.

You should be able to see the emitted if statement(s) that correspond to vg-if and so on.