-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature Request: Parser Friendly Output #169
Comments
Let's split this issue. I've opened the color issue in #171 Do you think that providing a JSON output would make it easier to integrate? |
IMO all that it really needs to be easier to integrate is to have colors removed and the code and message swapped. The big issues I was running into (with Lua pattern matching anyway) is ignoring the control characters was verbose and weird, and it wasn't possible to ignore the spaces after the message. Ironically enough, the control codes were actually the only reason I was able to separate the message and code at all. We could even keep the spacing between the elements if the code and message are swapped, since after I match the code ([%l-], lowercase and hyphens), I can just start matching the first non-whitespace character and match until the end of the line for the message. I went a little bit further than that with the PR I linked yesterday, having Granted, being unable to match the message without matching the trailing whitespace is pretty uniquely a lua problem, I'm pretty sure regex can specify it should only match single spaces. I couldn't find any way to do that in Lua pattern matching. JSON would also work, but I wouldn't say it would be easier, just equally as easy, at least for my use case. It's probably the safer bet in terms of compatibility with the widest range of tools, but parsing linter cli output with regex or other forms of pattern matching seems to be fairly standard practice to me. I can change my PR to add a json mode instead, should be relatively simple to swap that in later today. |
There are too many things that could go wrong with pattern matching, I would support the use of JSON instead 😅 |
That's fair, I'll change my PR later today and I'll also look at doing something else for |
PR Updated with JSON output support. |
Since a separate color issue was opened and the JSON output option was merged, this issue can be closed. |
I recently managed to make this into a null_ls source in my neovim config, but it was a real pain thanks to the color control codes and spacing in the output. The Lua pattern is borderline unreadable, and the message being before the code with spacing between them makes the pattern capture a bunch of empty space after the message. Not a big deal but looks kinda janky. The color and spacing are, of course, user-friendly, and I wouldn't want them to go away completely, but for null_ls (or whatever its successor ends up being) and similar tools that parse CLI output, a way to output with no colors and some delimiter character instead of the current output would be a good idea.
For reference, here's what I had to make the Lua pattern be in order to parse out the row, column, severity, message, and code (respectively, whatever is captured in the parentheses goes into those variables)
[[(%d+)%.(%d+)[%c%s%d^[;m]*([erowan]+)[%c%s%d^[m]*([%w: ]*)[%c%s%d^[;m]*([%l-]+)]]
And here's a picture of what that extra space after the message getting captured looks like.
Might be willing to take a stab at this myself if it's not already on someone's docket.
The text was updated successfully, but these errors were encountered: