allow configuring diff gutter source

[doy]

following up from #7805

this implementation removes the diff provider cascading fallback behavior in favor of allowing the user to configure which diff provider to use (currently just vcs, file, or none). this should allow maintaining the current behavior in the normal case, but also allow using :set diff-source file to see a diff against the state of the file on disk.

this does not yet support per-buffer configuration of diff sources because helix doesn't really have a good mechanism for per-buffer configuration in general at the moment - it feels like something that would be easier to add once the more general feature exists.

[pascalkuthe]

Thabks fir working on this! Please try to keep your PRs as minimal as possible that nkes them easier to review and merge. This contains multie changes at once.

Some if them (see my review comments) are entirely orthogonal and also not the direction I want to go.

[doy]

i think this addresses the comments you had so far, let me know if there's anything else!

[pascalkuthe]

I think this should be just editor.diff-source since the diff is also used for the reset-diff-change command and ]g and also for a side by side diff in the future so it doesn't just pertain to the gutter

[doy]

this actually is just editor.diff-source, i guess the comment is a bit misleading. i'll clean up the docs etc once the feature itself is more finalized.

[pascalkuthe]

ah sorry github collapsed the code so that it looked like it was a gutter config field and the comment reinforced that idea 😅

[doy]

alright, how's this?

[pascalkuthe]

I think this is getting pretty good now. I want the git diff provider to be configurable (so you can diff against any revision like upstream/master or v23.5.0 and even stage. You don' t necessarily have to implement that in this PR (you can if you want to) but I think we should think about how that will be handled in the config to avoid future breaking changes

[doy]

i thiiiink the current config should be extensible? like right now we have

[editor]
diff-source = "git" # or "file" etc

but this would probably still allow

[editor.diff-source]
type = "git"
rev = "main"
staged = true

or whatever in the future? i think it'll be easier to do that in a followup pr, but it seems pretty doable to me.

[doy]

(the test failures look like upstream repositories having problems)

[pascalkuthe]

LGTM now 👍

[poliorcetics]

I strongly disagree with forcing people to have a repo-local config each time they want to change the diff provider.

I want to configure helix once and have that config be enough for 99.99% of my usage, not have every repo on which I use JJ/git/no VCS (file) have a different configuration file and have to remember to copy some cargo-culted file from somewhere else.

Not only is it repetitive for very little gain, it also pollutes repos with local files, which mean adding git worktrees will not work the same for example, because the ignored files won't be copied over. Plus, Helix doesn't respect the .config/ format for local configs, which also pollutes listings with "ls -la" for example

[poliorcetics]

Some stats for example:

Currently on my personal machine, I have 14 repos using JJ, two using no VCS (playgrounds to try things out in Python and Rust) and 22 using git (I think I counted them all, I may have missed some in some deep folder tree)

By this PR, if I want to minimize configs, I have to write 16 different files for JJ/no VCS and set git at the default. That's not a good state.

In comparison, the fallback behavior means I can set "JJ, Git, File" once and just move on, for all my repos at once

[pascalkuthe]

the assumption is that you very much will be working with a single vcs system 99% of the time (really always git) and if you are forced to use something niche like mecurial adding a config file isn't too bad.

The fact that you seem evenly split between two different vcs is incredibly niche.

If anything I would not allow this to be configured at all and instead just hardcode the detection with the option to explicitly overwrite (which would be the same as this PR. We weren't planning to support vcs other than git when this was created which would mean the autodetectin would always return git)

[poliorcetics]

If autodetection is a thing then yes, this PR will work well. Is there an issue for it ?

[pascalkuthe]

clsoign thi onein favor of #9951, thanks for working on this on!