ghostty-org
GTK: Command palette should accept ctrl+n/p to navigate actions
These are fairly standard keybindings (readline) for navigating lists in the terminal but also in general. On macOS this already works
- Ctrl+N: next in list
- Ctrl+P: previous in list
I kind of disagree with this issue. GTK already has a set of builtin keybinds you can use to navigate between entries and I'd argue that allowing Ctrl+N/P here would be confusing behavior since no other lists in GTK work like this.
Yeah, I understand that. But I think terminals in particular are different in that its jarring to go from an environment where ctrl+n/p navigate nearly everywhere (shells, TUIs, etc.) due to readline and libedit and friends and context switch into "native mode" which is then platform-specific for GUI elements. Ghostty itself being cross-platform exacerbates this.
Especially as I plan to pursue TUI apps being able to create their own GUI elements via escape sequences (such as tabs), I think this will only get more confusing.
We can perhaps walk the line by making these bindable so they can un-bound or re-bound.
I think making them rebindable might make sense, but it's going to be hard — especially since we can't use our usual input handling for existing GTK widgets without a lot of plumbing. No offense to the author, but the code in #7979 isn't particularly elegant. The "TUIs should be able to define their own binds" argument also doesn't really apply here since again our input handling code is specific to each terminal surface and does not at all apply to native GTK dialogs or lists.
I personally don't really know how strong is the demand for this. On one hand I can see how this can make a more "seamless" experience, but on the other hand you already need to navigate every terminal emulator there has ever been with different controls compared to a TUI. Given the completely different presentation and UI/UX expectations I don't think it's fair to equate the two — in fact, I think from a UX perspective it's better to keep the "terminal layer" separate from the "emulator layer" because they are different pieces of software, and introducing new and nonstandard keybinds like these don't really bridge the differences IMHO.
It's like emulating an old console inside an emulator like Retroarch. It doesn't mean that these are the same thing or there isn't going to be a disconnect in UX just because the emulator happens to share the behavior of a few buttons with the actual console.
No offense to the author, but the code in #7979 isn't particularly elegant.
None taken! I'm not very experienced with GTK, but I really liked the idea behind this feature. I use Ctrl+N/P for list navigation in almost all of my daily apps — even beyond TUIs — and noticed no one was working on it, so I thought I’d give it a try.
That said, if this feature would benefit from someone with more GTK experience, feel free to close the issue or take it in another direction. But if you'd like me to keep working on it, I'm happy to continue and improve the PR.
As for the feature itself, I think @pluiedev raised some very valid points. Still, I personally would expect a terminal emulator to be highly customizable in its keybindings — and Ctrl+N/P support would be useful for many users who rely on that pattern. Ideally, the bindings would be fully configurable, so users who prefer alternatives like Ctrl+J/K could set those instead.
Also, the default GTK keybindings for navigating lists are the arrow keys, which I’m not a big fan of — though I admit that’s a personal preference.
somewhat related, but I think having some keybinding options like next_action and previous_action would be useful.
I'm a Ctrl-J/K guy, and coming from something like Raycast it's a bit strange to switch to Ctrl-N/P.
more than happy to contribute this change if this is the right approach
somewhat related, but I think having some keybinding options like
next_actionandprevious_actionwould be useful.I'm a Ctrl-J/K guy, and coming from something like Raycast it's a bit strange to switch to Ctrl-N/P.
more than happy to contribute this change if this is the right approach
I am also in same boat I think making it rebindable is the right choice and would make everyone happy
