[Feature] Allow rearange diffview index buffer position

[SuperBo]

Description

Right now the current window order is putting index as following

the entries under "Changes" will have the index buffer on the left side, and the entries under "Staged changes" will have it on the right side)

Expected behavior

I came from lazygit experience, so I expect the with "Changes" files, the index should be in right and similar with "Staged", index should be in left.

Please allow one config option to let the user config the index buffer orientation.

Actual behavior

Index is put on fixed position without any option to configure.

Steps to reproduce

:DiffviewOpen

Health check

Output of :checkhealth diffview

``` ####################### ### PUT OUTPUT HERE ### ####################### ```

Log info

Relevant info from :DiffviewLog

``` ############################ ### PUT LOG CONTENT HERE ### ############################ ```

Neovim version

NVIM v0.9.4
Build type: Release
LuaJIT 2.1.1700008891

Operating system and version

macOS 14.0

Minimal config

No response

[sindrets]

The windows are ordered chronologically (assuming left-to-right, top-to-bottom order). This means that you always get the older state first, followed by the newer state, which is intuitive.

What's the justification for arranging the layout in the inverse chronological order?

[SuperBo]

Let take a look at this screenshot.

In the file panel, top-to-bottom direction, we apply a reverse chronological. This means we have newer file first (unstaged) then older (staged).

However in the file window buffer, we apply a reverse order (chronological order). This means we have older file first (index) on the left, and newer file (working dir) on the right.

This inconsistent make me feel very strange at the first time I use Diffview.

[sindrets]

The sections in the file panel are not ordered by chronology. They're ordered by urgency ("what requires the users attention first?"):

1. Merge conflicts are always first: these require immediate attention.
2. Unstaged changes: this is always the changeset you're currently working on, and is where you're going to be determining what to include in a commit.
3. Staged changes: the changeset you've already marked to be included in the commit.

But this is unrelated to how the diff windows are arranged. Practically every tool that has a diff viewer displays diffs in chronological order, the same way we do in diffview.nvim. Off the top of my head I can think of:

• vim-fugitive
• GitHub
• GitLab
• BitBucket
• Delta
• VS Code
• All JetBrains IDEs
• Sublime Merge

If lazygit does something else here, they are clearly the outlier.

---

Anyway, you have now indirectly made the case for rearranging the sections in the file panel, which I'm willing to discuss. However, you haven't made an argument for why we should offer an option for arranging diff windows in reverse-chronological order.

[SuperBo]

I think you are correct, I have check other clients, all have the same arrangement with diffview.

My wrong impression really comes from this layout (unstaged changes are on the left, staged changes are in the right).

Actually these are two inline diff windows, not the same as side-by-side diff window.

For file panel, I have just take a look at Gitlense, they put staged changes before unstaged changes.

[sindrets]

Closing as completed as at seems we came to an understanding with regards to the original issue.

If you think we should rearrange the sections in the file panel, please open a new issue with arguments for why think so, and we can discuss it further. Mind you, the arguments need to be more meaningful than "it's what VSCode does".