Supporting configurable tree pane position

[winzamark123]

Hi!

Just wanted to pretext, that installed revdiff 2 or 3 days ago, really love the project! It was taking me a long time to find a terminal diff viewer that fit the agentic workflow I liked and revdiff is hitting that sweet spot. Anyway heres an issue i'd like to flag with a ready PR if the maintainers allow. I was going to set up a PR initially but read the CONTRIBUTING.md and realized I should put up an issue first in case it doesnt fit the product direction.

Problem

The file tree and Markdown TOC are fixed to the left side. I wanted this to be configurable so that user can put the file tree on the right side in case they wanted to. Since some users (also me) normally use their file trees on the right side for navigation in the IDE.

heres a video of how i imagined it which existed in my fork. if its good ill open a PR for it! the navigation of h and k becomes directional rather than just hardcoded to focus on a specific pane.

rightside.mp4

[umputun]

yeah, this is worth doing and I'm open to the PR. One thing up front: I tried this myself and the hard part isn't swapping the panes, it's making the right side actually look right.

the scrollbar thumb, the «/» horizontal-scroll indicators, the border seam and the background fill are all tuned for tree-left/diff-right. The scrollbar replaces each pane's right border, so with the diff on the left its thumb ends up at the middle seam instead of the far edge. That's where my own attempt looked off.

conditions for a merge:

• default stays left; add a --tree-position left|right flag mirroring --tree-width (same env/ini/default shape)
• h/l become directional (focus by direction, not hardcoded to tree/diff), plus the keybinding doc updates (README, site docs, both plugin config tables)
• the right side is actually correct: scrollbar thumb on the right edge, «/» indicators, border seam, bg-fill, not just the pane order flipped

one more thing: this is a nice-to-have, a taste preference, so whether it's mergeable also depends on how big and complicated the change turns out. If it stays manageable and reasonable I'm fine with it, but past some size it's just not worth it for this.

if the fork handles the visual side cleanly, open the PR and I'll review.