This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Append "(fix available)" to diagnostic message when fixes are present.
ClosedPublic

Authored by ioeric on Jan 31 2019, 5:44 AM.

Diff Detail

Repository
rL LLVM

Event Timeline

ioeric created this revision.Jan 31 2019, 5:44 AM

Dropping by: Maybe add (fix available) as a prefix rather than suffix. Since long texts might end up getting truncated(especially in vim)

sammccall accepted this revision.Jan 31 2019, 7:44 AM

Dropping by: Maybe add (fix available) as a prefix rather than suffix. Since long texts might end up getting truncated(especially in vim)

Yeah truncation is definitely a problem, and on the other hand putting it at the start could get in the way and reads kind of backwards.
Eric: up to you - if you move it to the front probably shorten to "[Fix]" or so.

Another alternative is to use a prefix symbol like a bullet like we did with include insertion. As there, it's less explicit but also less intrusive.

clangd/Diagnostics.cpp
164 ↗(On Diff #184488)

I'd consider passing the number here, and distinguishing between "Fix" and "Fixes" in the message.
Reasoning: when multiple fixes are available the user will have to make a choice. This may use a distinct UI (YCM) or not (VSCode), but foreshadowing the need for a choice will make the flow more predictable.

I'd suggest *not* printing the actual number though, seems too noisy.

This revision is now accepted and ready to land.Jan 31 2019, 7:44 AM
ioeric updated this revision to Diff 184510.Jan 31 2019, 8:07 AM
ioeric marked 2 inline comments as done.
  • address comments

Dropping by: Maybe add (fix available) as a prefix rather than suffix. Since long texts might end up getting truncated(especially in vim)

Yeah truncation is definitely a problem, and on the other hand putting it at the start could get in the way and reads kind of backwards.
Eric: up to you - if you move it to the front probably shorten to "[Fix]" or so.

Another alternative is to use a prefix symbol like a bullet like we did with include insertion. As there, it's less explicit but also less intrusive.

Yeah, this could be a concern for plugins that truncate messages (YCM+Vim). There are other editors that do not truncate e.g. vscode. So I'd suggest we start with something less intrusive like suffix and try it out. If it turned out to be a problem too often, we can explore options with prefix.

clangd/Diagnostics.cpp
164 ↗(On Diff #184488)

Sounds good. Done.

This revision was automatically updated to reflect the committed changes.

Could this be made optional for VSCode?
As mentioned in the discussion before, I would personally prefer to turn it off, even though I do acknowledge the need for this for some clients, e.g. vim.

Could this be made optional for VSCode?
As mentioned in the discussion before, I would personally prefer to turn it off, even though I do acknowledge the need for this for some clients, e.g. vim.

Yes, but a new option seems a bit of an overkill here. The text is appended and doesn't seem to affect the readability of original diagnostic message much (IMO). Could you elaborate why this is undesirable in vscode for you?

Yes, but a new option seems a bit of an overkill here. The text is appended and doesn't seem to affect the readability of original diagnostic message much (IMO). Could you elaborate why this is undesirable in vscode for you?

It's basically just noise, as VSCode shows the bulb icons whenever you hover over the diagnostics with errors.
Having a standard suffix in half of the diagnostics seems undesirable.

Adding a suffix like this should be left to the client, i.e. it's clear this is desirable in vim which does not have other UI indicators and adds noise in VSCode, which uses bulb icons for those purposes.
I do agree that plumbing the parameters is annoying, but this does look like a thing where different clients might diverge in how they present results and it's totally looks fine.
Note that command-line argument is not the only way to do this, e.g. we could also have a special capability as an extension that would turn these messages of (clangd.addFixAvailableMessage) and send it from VSCode. That's totally doable, since we control the extension.

ioeric added a subscriber: hokein.Jan 31 2019, 10:39 AM

Yes, but a new option seems a bit of an overkill here. The text is appended and doesn't seem to affect the readability of original diagnostic message much (IMO). Could you elaborate why this is undesirable in vscode for you?

It's basically just noise, as VSCode shows the bulb icons whenever you hover over the diagnostics with errors.
Having a standard suffix in half of the diagnostics seems undesirable.

I don't think it's pure noise. Vscode displays diagnostics in the "PROBLEMS" tab. A suffix allows you to tell whether fixes are available without hovering on the errors.

That said, I'm not opposed to a config option. Would love to hear others' thoughts tho. @sammccall @hokein @kadircet

FWIW, I don't think this is worth adding an option or protocol extensions for at this point.

There are pros and cons to showing this in VSCode (pros are visibility without hovering, particularly in problems view and cross-editor consistency, cons are certainly noise for main-editor hover).
But this seems pretty minor either way.

If it turns out to be a big problem, a protocol extension and updating the editor extensions where relevant seems like a reasonable way to go, but it's certainly more complicated.

I don't think it's pure noise. Vscode displays diagnostics in the "PROBLEMS" tab. A suffix allows you to tell whether fixes are available without hovering on the errors.

And it shows bulb icons when you hover over diagnostics in this dialog too. To be clear, it's my personal preference to not have it, that's the reason I call it 'noise', others might like the message and it feel more useful to them.

But this seems pretty minor either way.

Sure :(