Skip to content

scroll_* bindings should respect "performable" and do nothing in alt screen #6765

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
mitchellh opened this issue Mar 17, 2025 · 2 comments
Labels
input Keyboard or mouse input

Comments

@mitchellh
Copy link
Contributor

Discussed in #6719

Originally posted by sirburpalot March 14, 2025
Key bindings for actions like scroll_page_up, scroll_to_top, etc., when marked with the "performable:" prefix, should be ignored in fullscreen applications like nano or far2l, because such applications do not typically utilize the scrollback buffer.

How to reproduce the bug:

  1. Add keybind = performable:shift+home=scroll_to_top to Ghostty's config.
  2. Launch nano.
  3. Type a string of random characters and press Shift+Home. The Shift+Home shortcut will not be passed to nano.

Notes

I am constraining this issue specifically to alt screen, but technically scroll should respect performable in ANY scenario where there is no scrollback, so if we fix it that way that'd be best. ❤

Marked as a feature because performable is documented as not working for everything yet.

@mitchellh mitchellh added the input Keyboard or mouse input label Mar 17, 2025
@jcollie
Copy link
Member

jcollie commented Mar 19, 2025

This isn't going to be as easy as I first thought, basically because scrolling is an asynchronous operation that has to send a message to the IO thread. The keybind requires a synchronous response.

ghostty/src/Surface.zig

Lines 4066 to 4070 in bd7c5cc

.scroll_to_top => {
self.io.queueMessage(.{
.scroll_viewport = .{ .top = {} },
}, .unlocked);
},

@mitchellh
Copy link
Contributor Author

We can grab the IO lock for this and inspect the terminal state. We could probably do this whole operation with a lock rather than a message but I’d have to double check the implementation…

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
input Keyboard or mouse input
Projects
None yet
Development

No branches or pull requests

2 participants