Rust: debug log can be formatted by rustfmt into multiple lines

[xixiaofinland]

For example, if the line is beyond the max_width, rustfmt will auto-formatted it into multiple lines:

            eprintln!(
                "gopro[6]: rewrite.rs:213: try_add_standalone_suffix={:#?}",
                try_add_standalone_suffix
            );

then the command to delete debug lines will only delete one line.

            eprintln!(
                try_add_standalone_suffix
            );

[andrewferrier]

Thanks for the issue. Yes, I'm aware of this one. I don't have an easy "fix". Generally, I avoid formatting a file until the very end of my changes (i.e. when I've finished using debugprint and removed all the lines), but I'm aware that not everyone works this way. Maybe there is something clever I can do with extmarks or similar. I also don't want to over engineer either though; this is supposed to be a relatively basic tool. I'll mull this one over… Any suggestions welcome.

[xixiaofinland]

This issue is OK for me as either a fix or to be passed over. It's really not a big issue and is reported here in case people are unaware. @andrewferrier

I haven't examined the debugprint code in detail. Naively, I believe 'debug' is also a normal AST node in tree-sitter. Would it be relatively straightforward to identify it by the node and keyword combination, rather than just a single line and keyword?

[andrewferrier]

For now, I can't think of a straightforward implementation for this. extmarks can't practically be used to track where debug lines are added as they are lost on quitting NeoVim, and for the type of person who's doing regular formats, they are likely often quitting/reopening NeoVim, so tracking this way seems of limited value.

Identifying the statements might theoretically be possible using treesitter, although that would require a different set of queries for each language debugprint.nvim supports, and I think could still have quite a few false positives/negatives.

For now, I'm going to deliberately not implement this, as I don't want the scope of debugprint.nvim to grow too complex, it's supposed to be a "poor man's" debugging tool, after all. I will document this, though.

[andrewferrier]

Thanks for your feedback and input @xixiaofinland. Hopefully you understand why I chose not to implement this for now, I have documented this as a limitation. If someone is interested in doing the work and opening a pull request, I would certainly discuss it.

[xixiaofinland]

sure, totally understand.

I'm also using it with Salesforce Apex language, and trying it out for different scenarios for a couple of weeks.
Once it's baked into my working flow and my setting is stable, I will make a PR for supporting Apex :)

Apex is a language that needs to be sent to the cloud to be compiled thus lacks many local debugging features. The good old debug log way is really how I use most often.

Thanks again Andrew for this great tool!

[andrewferrier]

No problem, Apex support would be very welcome - feel free :)