Allow left/right to navigate between panes#14099
Conversation
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 7f99a1f93b
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| hotkey: "ArrowLeft", | ||
| callback: () => { | ||
| focusAdjacentSelectionScope(filesVisible, -1); |
There was a problem hiding this comment.
When the diff pane itself has focus, ArrowLeft/ArrowRight are the browser keys users need to horizontally scroll long diff lines. These new registrations are document-scoped and TanStack hotkeys prevent default by default, so any non-input focus in the workspace (including the diff selection scope rendered in Details.tsx) now moves focus to another pane and suppresses the diff viewer's horizontal scrolling instead. Please target the pane containers or otherwise avoid handling the arrows when the intended receiver is the diff content.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Pull request overview
Adds Left/Right arrow key bindings to switch focus between workspace panes (selection scopes) in the Lite workspace UI, extending the existing H/L navigation.
Changes:
- Register
ArrowLeftto focus the previous selection scope. - Register
ArrowRightto focus the next selection scope. - Reuse the existing “focus previous/next selection scope” command metadata for command palette visibility.
| options: { | ||
| conflictBehavior: "allow", | ||
| meta: workspaceHotkeys.focusPreviousSelectionScope.meta, | ||
| }, |
| options: { | ||
| conflictBehavior: "allow", | ||
| meta: workspaceHotkeys.focusNextSelectionScope.meta, | ||
| }, |
|
I’m imagining that when we add the ability to view files as a tree rather than list, we’ll use left/right shortcuts for expanding/collapsing folders and jumping selection to the parent, as per the AGP tree view pattern. Similarly for the outline tree where we’ll eventually have the ability to expand/collapse stacks, upstream changes, and maybe branches. I’m keen to make sure we follow well established accessibility patterns. I wonder if there’s another shortcut we could use. It would be nice to have a shortcut that works even if you’re focused inside a textarea e.g. commit message. Perhaps we could also have shortcuts for “focus outline”, “focus files” and “focus diff” in addition to the direction shortcuts. Lazygit for example has cmd+n where n is the panel number. |
|
per the discussion we had on this over video the other day - I really don't know. I think in the typical workflow it is much more common to want to navigate between commits, and then go into a commit take a look around, up and down and go back to check another commit. And doing that with the arrow cluster is convenient. What do you think we look into another shortkey patter to use for expanding /collapsing folders (which I think is objectively the less frequent operation in relation the main navigation) |
|
I agree there's an inconsistency there, but I think it may have been a mistake to use I'm open minded but I feel pretty strongly that left/right arrow keys should be used as described in the tree view pattern docs I linked to. If we give this some more thought I think we can find something that's just as convenient. I wonder if these shortcuts could be framed in terms of "ascend/descend the hierarchy" rather than "move selection left/right". Lazygit for example has Note left/right isn't just for expanding/collapsing but also jumping to the parent, e.g. pressing left on a commit should jump to parent branch. See VS Code's file explorer as an example. We currently have |
|
The difference between vscode file viewer and our app though is that we are deliberately choosing not to expand content vertically in-line with the list. E.g. we "expand" the commits's content/files to the right. Because of this i think the file tree comparison is incorrect. What we are doing is more similar to the MacOS finder with multiple columns represent the hierarchy in the data 
And in this view the behavior of the arrow cluster the way you would expect from it. Because my monkey brain has been trained by patterns in existing applications, using the Lite app sometimes can feel highly frustrating, because that pattern and expectation of symmetry in ←↑↓→ File trees are not exactly primary to the app data hierarchy because:
I think this would be a good idea to do for the defaults of the app no matter what. It's all too easy to trigger this by accident and it's a friction point |
|
It’s not just the file tree, it’s also the outline in the left panel. This is also a ‘tree view’, e.g., stacks, branches and upstream changes being branches in the tree. I think what we have is more of a mix of Finder’s tree view and the one you showed. |
|
I dont want to necessarily prescribe a solution, as im not really an UX expert. And perhaps this was a bit of a reaction out of usage-induced frustration. At the end of the day we wanna make a too that is dead obvious to use. I still press 'enter' on commits and it starting a reword is something i run into very consistently and it is very disruptive - hence I try arrow keys and they don't feel intuitive either. Imo, this is the type of stuff we will only get right through usage and iteration, and this is perhaps the main thing to get to |
|
I just thought, we’ll probably have expand/collapse in the diff as well.
I’m curious, when you press enter, what are you expecting to happen? |
probably to "open" it / navigate into it. Not sure if arrow cluster or enter is the way to go but right now it feels very frustrating for me to use |
wdyt?