VCS changes picker

[poliorcetics]

When I code I often need to go back to the places I modified.

Now that helix supports VCS (i.e., git for now), we could add a VCS picker that would list all changes, for easy navigation.

For the sorting order I propose:

• Current file, current change,
• Current file, other changes,
• Other files, changes sorted by line number

Including the first line of the change (or the line just before the deletion) would probably help searching too:

path/to/file:73 fn added_function() {

I have no idea what to pick for the picker key, Space + v maybe ?

[lukepighetti]

I think we should use <space>g and <space>G and rebind debug to <space>e

[pascalkuthe]

I agree that it would be nice to keep it consistent here altough it also feels kind of bad repeatly moving the debug binding around. It was just recently moved from <space>d to <space>g

[lukepighetti]

I totally understand that, but it feels like it's worth putting in the effort to find it a forever home, and it is still an experimental feature so I would expect folks to be open to a little minor chaos

[haikyuu]

space e might be taken by tree explorer as well *

[xJonathanLEI]

After looking at #5472 I think we need 2/3 pickers:

1. untracked/modified/deleted FILE picker
2. current document diff blocks picker (implemented in Feat: Add VCS change picker for current document and workspace #5472)
3. current workspace diff blocks picker (not exactly implemented in Feat: Add VCS change picker for current document and workspace #5472 - see Feat: Add VCS change picker for current document and workspace #5472 (comment))

IMHO picker 1 is actually the most useful - it's basically a git status picker. I don't see any issue or PR tracking it yet.

Regarding key binding, I think binding to <SPACE>g makes the most sense given the existing [g and ]g bindings. But I think <SPACE>g should be a node itself, with the subsequent key selecting one of the many VCS pickers.

[lukepighetti]

Regarding key binding, I think binding to <SPACE>g makes the most sense given the existing [g and ]g bindings. But I think <SPACE>g should be a node itself, with the subsequent key selecting one of the many VCS pickers.

I can only find one keybinding dialog that is two levels deep, and that is Window via <SPACE>w..., but that one can be brought up with c-w. If we're going to nest it like that, I think we should plan for a shortcut with c-g as well

[xJonathanLEI]

Actually. I changed my mind. I think pickers 2&3 are quite useless - for 2 you might as well just do [g and ]g with better UX; and 3 is just 1 + 2.

That's why in my PR implementing 1 (#5645), I actually just did the <SPACE>g binding, no nesting.

[poliorcetics]

I don't agree at all, all three pickers are useful, and the numbers of reactions on my initial message say I'm not the only one who thinks so.

We have workspace and current file diagnostic pickers despite navigation+file picker bringing the same functionalities, dismissing the VCS ones simply because you prefer navigation is not a good argument. Not everyone has the same workflow or preferences in how they use their tools.

We can have both modified files and modified blocks (current, workspace) pickers and only bind one of them by default if we want to avoid cluttering the keybinds (and that's a good idea), but arguing against them when wholly we already have equivalent is shortsighted IMO.

Sorry if that comes off too strongly, I'm not intending to insult anyone, I just want to be sure to remind everyone that helix is not used only by its developers and that "I don't see a use for that therefore it is useless" it not a good argument when people have expressed a used for "that" and taken time to make issues and PRs