There is no possible to assign a shortcut for compare command in HISTORY view

[Golyshkin]

Version

6.8.0.202311291450-r

Operating System

Linux/Unix

Eclipse version

No response

Bug description

The full bug description can be found in eclipsesource/megit#52

Actual behavior

The full bug behavior can be found in eclipsesource/megit#52

Expected behavior

The full bug expected behavior can be found in eclipsesource/megit#52

Relevant log output

No response

Other information

No response

[tomaswolf]

Ack. This is evidence of the confused menu implementation in parts of EGit. Historically, many context menus were done directly in code with Eclipse Actions instead of using the Command-Handler framework. Sometimes commands were also duplicated. (For instance I just discovered that EGit still has two different commands for "Show Revision Information". It should have only one, with different command handlers active on different types of selections.)

The context menu in the CommitFileDiffViewer must be rewritten to be extensible and to use the Command-Handler framework, and we need to define new handlers for existing commands, then drop the current Actions. Then a keybinding assigned to a command will also work in that viewer in the history page.

This is not exactly difficult, but it needs quite a lot of code changes, plus proper handler and menu definitions in plugin.xml, which also requires a new property tester of FileDiff objects to get activation and enablement expressions right. Some complications arise because the history page has multiple viewers with different context menus, so the selection provider in the GitHistoryPage needs to be improved. Luckily we already have all the needed framework glue bits and pieces, we just have to use them and modernize this history page implementation a little.

The CommitFileDiffViewer is also used in the commit viewer (class CommitEditor; it's a (read-only) editor because it shall open in the editor area). That CommitEditor is a multi-page editor and needs similar changes to the selection provider. Only that these changes will all a bit different and slightly more complicated because it's a multi-page form editor that even has collapsible sections.

Changes to the selection providers must be checked carefully for unexpected side-effects, and other commands may need to be adapted to get the right objects from the new selections.

I'll work on this, but it will take some time.