Add "Source Action" entry to the "Edit" main menu

[jwortmann]

Same as #2141, but for "Source Action".

I also moved "Format File" and "Format Selection" into a submenu.

Note that no diagnostics are sent when requesting the "source" and "refactor" actions, but I would expect those actions to not depend on diagnostics, so I think this should be okay.

It would be good if someone could test it with a server that also provides "source" actions.

---

And I've experimented a little bit with the context menu, but I'm not happy with how it turns out if the same submenus for "Refactor" and "Source Action" are applied to the context menu. Because those menu items for the submenus cannot be hidden if they contain no items. That means that they will always be present in the context menu, even if no LSP is running (for example for basic .txt files).

The following example demonstrates this, (here also with the "Goto..." commands grouped into a submenu):

Furthermore, in a quick test it didn't work reliably for me from the context menu, even though (or maybe because) I think I properly took into account that the region for the code actions request should be derived from the mouse cursor / menu position, and not from the selection when triggered from the context menu. (I think this is also a bug currently existing in the lsp_code_action command, which doesn't work from the context menu if the selection/caret is at another position)

Due to these reasons the context menu is unchanged for now.

Closes #2066

[jwortmann]

By the way, the ST core issue for the "hide empty submenu" problem is at sublimehq/sublime_text#1859.

[rchl]

Furthermore, in a quick test it didn't work reliably for me from the context menu, even though (or maybe because) I think I properly took into account that the region for the code actions request should be derived from the mouse cursor / menu position, and not from the selection when triggers from the context menu. (I think this is also a bug currently existing in the lsp_code_action command, which doesn't work from the context menu if the selection/caret is at another position)

As far as that, I've also been thinking about this before and on one hand I agree that ideally the action should be triggered in the place that was right clicked rather than the current cursor position but on the other hand, this could be a little confusing because in ST the cursor doesn't move to the location that was right clicked unlike in many other programs. For example in VSCode it moves. In browsers it doesn't move in plain text field but it does in Discord/Slack input field or Gmail compose field for example.

Even in ST the built-in Goto definition seems to use the event position while the Line History... that opens Sublime Merge doesn't...

But still I'd lean towards using event position.

[jwortmann]

because in ST the cursor doesn't move to the location that was right clicked unlike in many other programs. For example in VSCode it moves.

Interesting, I never particularly noticed that, but you are right. If we were a bit reckless, we could do the same:

import sublime_plugin


class ContextMenuMoveCaretCommand(sublime_plugin.TextCommand):

    def is_enabled(self, event):
        return False

    def is_visible(self, event):
        if isinstance(event, dict) and 'x' in event and 'y' in event and self.view.settings().get('lsp_active'):
            pt = self.view.window_to_text((event['x'], event['y']))
            if not any(pt in selection for selection in self.view.sel()):
                self.view.run_command('lsp_selection_set', {'regions': [(pt, pt)]})
        return False

    def want_event(self):
        return True

    def run(self, edit, event):
        pass

Context.sublime-menu:

[
    { "command": "context_menu_move_caret" },
]

But not that I would reccomend it.

But still I'd lean towards using event position.

I think I do too. It might be an uncomfortable change for a small number of users who got used to click anywhere else in the view to open code actions for the current selection. But on the other hand, the event position is already used for the "Goto..." commands and "Find References" (not for "Format Selection" and "Expand Selection", but for those it wouldn't make sense to not use the selection).