Suggestions for Source Action... menu handling

[rchl]

From #2064 (comment):

• remove the "Source Action..." entry from the context menu (because source actions are not bound to a particular point or selection, but apply to the entire file)
• Add "LSP: Source Actions..." to the "Edit" main menu, and either add another argument full_range: bool = False (or so) for the code actions command, which would be activated for the source actions menu entry, or alternatively derive this from whether only_kinds includes "source". So that the request for source actions would use the range of the entire file and also include all of the diagnostics in the file (this could be useful for the source.fixAll kind)

[rchl]

@jwortmann

Your two points make sense on the surface but what makes me a bit unsure is seeing how VSCode doesn't follow those.
It has Source actions... in the context menu and sends current selection range for the request. So I'm not sure we should be removing it from the context menu. If we did, then should we also remove "Format file" since it's a file-level action? And also, if we look outside of LSP, there are other actions in the view context menu that are file level rather than selection-level.

[jwortmann]

VSCode [...] sends current selection range for the request.

Maybe the range is ignored anyways by the servers when using "only": ["source"] in the request params. But from my point of view it would make more sense to use the whole content range and also include all of the diagnostics in the file. If in doubt, maybe we should ask what's expected for this request in https://github.com/microsoft/language-server-protocol/issues?

If we did, then should we also remove "Format file" since it's a file-level action? And also, if we look outside of LSP, there are other actions in the view context menu that are file level rather than selection-level.

Personally I would be okay with removing "Format file" from the context menu. But probably it's not only about the file-level action, but should also depend on the expected usage frequence whether an entry should be included in the context menu. I guess most users run "Source Action..." only very rarely, while "Format file" is maybe used more often (and probably more often than "Format Selection", because it's simpler and not all servers are also documentRangeFormattingProvider).

---

I would probably also remove "Expand Selection" from the context menu, add a

def is_visible(self, event: Optional[dict] = None, point: Optional[int] = None) -> bool:
        return self.is_enabled(event, point)

method to all of the commands in order to hide them when not activated, and then remove the "LSP" submenu.

[predragnikolic]

but from my point of view it would make more sense to use the whole content range and also include all of the diagnostics in the file

This comment is related, it contains examples why sending the current selection makes sense #779 (comment)

[rchl]

I've asked some related questions in microsoft/language-server-protocol#1554

This comment is related, it contains examples why sending the current selection makes sense #779 (comment)

It makes sense for normal code actions (especially the quickfix ones) as those depend on specific diagnostics and location. And we are sending selection range and all intersecting diagnostics in that case already.

source ones are typically not specific to location. With that said, I agree that it makes more sense to send whole range and all diagnostics in that case but in practice servers might be fine either way.