shift+(end,home,left,right,up,down) not working inside term editors

[msmafra]

Trying to use one of these combinations shift+(end,home,left,right,up,down) to select text inside nano or micro doesn't work inside Ghostty.
Not sure if the keybind settings related to each one should be set in the configuration file, but setting it, if I understood it correctly, made it worse: not allowing to select anything.

keybind = shift+up=adjust_selection:up
keybind = shift+down=adjust_selection:down
keybind = shift+right=adjust_selection:right
keybind = shift+left=adjust_selection:left
keybind = shift+end=adjust_selection:end_of_line
keybind = shift+home=adjust_selection:beginning_of_line

[EDIT]
I mean for selecting text, not even tried to check if moving inside those editors was broken.

[rhodes-b]

Im not 100% sure how adjust_selection works but my assumption is that they are related to the scrollback buffer which does not exist for tui applications that run in the alternate buffer (ie nano, micro etc)

ghostty/src/Surface.zig

Lines 4319 to 4321 in 0f2f0ab

	// If the selection endpoint is outside of the current viewpoint,
	// scroll it in to view. Note we always specifically use sel.end
	// because that is what adjust modifies.

this comment makes me really think it requires the scrollback

im not sure how the selection inside these editors work but they arent using the scrollback.

Maybe sending that the cursor moved would work although im not too sure what the escapes are for keybinds I know that left is ^[A for example

[00-kat]

It's definitely scrollback. Adding performable: would be the solution if one wants it to work in both nano/micro/etc. and the scrollback.

[jcollie]

It's not quite so simple as primary/alternate screen. There are apps like less that use the alternate screen but do not manage their own selection (like editors do).

[odalet]

I bumped into this as well, and (in micro as well as nano):

• I have no issue with Shift + left/right/up/down arrow to extend a selection
• Shift + home/end/Page up/Page down do not work

Disclaimer: I understand very few of what's going on but...

I've been experimenting a bit with Ghostty code and:

• I've noted than when using micro, I never enter in Selection.adjust
  • This is because, in .adjust_selection, we return soon (as there is no selection)
• However, I managed to have shift+end/home working in micro by commenting out some default configuration in Config.zig: Key bindings in the Viewport scrolling section conflict with selection extension.
• Removing those bindings reactivates these ones.

With this change,

• shift + home/end works in micro but shift + Page up/Page down does not (I think this one is on the micro side as it does not work either when using konsole or gnome terminal)
• shift + home/end/page up/page down works as expected in nano

As I said, I have no idea if my change might have side effects and break things somewhere else, so I keep it as a private version for now. If this proves useful, I might submit a PR though.

NB: my modifications are based off this commit: 747c43f

[nyngwang]

Hi, Neovim user here. I will elaborate the problem and some reasoning for solving it in this comment.

The Problem

I encountered this issue in Neovim today where one of my plugins' default-keybind <S-Up>, i.e. shift-up that was mentioned by OP, stop working.

Problem Scope

1. The keybind itself is not a big deal, as it is just to scroll the preview of the result provided by the plugin. That "<S-Up> does not work anymore" doesn't destroy it for daily work, as I expect that they will just fallback to their dear old friend - mouse - to scroll the buffer.
2. But, many people might be affected by it. The Neovim plugin shipped with <S-Up> as a default keybind is ibhagwan/fzf-lua, which is a bundled-plugin of a prominent distribution folke/lazy.nvim. Notice that people picked up a distribution usually lazy to do further customization, thus my point.

But worry not,

• I will open a discussion thread there(update: did) and search if there is any related report.
• This is probably not a bug in Ghostty. I will explain it in the next section.

Reasoning & Solution

It's probably just that "some defaults of Ghostty" can easily conflict with some common keybinds of existing terminal programs, e.g. neovim, nano, and micro that have been mentioned in this thread.

EDIT: prefer unconsumed: instead of comment-out
I solved "The Problem" in my case by prefixing unconsumed: to these four lines of keybind:

keybind=clear
# ... (skipped)
keybind = unconsumed:shift+up=adjust_selection:up
keybind = unconsumed:shift+down=adjust_selection:down
keybind = unconsumed:shift+left=adjust_selection:left
keybind = unconsumed:shift+right=adjust_selection:right

I guess the following ideas might help:

1. We could change the default like keybind = unconsumed:shift+up=adjust_selection:up, etc.
2. I haven't read the source code, but if Ghostty could know itself in "visual mode" (like what vim/neovim did) then adjust_selection: could be improved by:
   • If it's not in "visual mode", do nothing.
   • If it's in "visual mode", go into route of existing implementation.

[rhodes-b]

There is a discussion for a copy mode like tmux (which would be visual mode) but I dont think that would just make adjust selection keybinds useless outside of that case as there would be many people who dont want to use the copy mode

[nyngwang]

@rhodes-b Understood. I didn't try to convey that "that would just make adjust selection keybinds useless" (so I proposed that unconsumed: might be a good idea), but that tmux indeed helps as a workaround for my usecase. Ty for quick reply btw.

[00-kat]

by comment-out these four lines of keybind

keybind = clear

I'd suggest doing it like this instead:

keybind = shift+up=unbind
keybind = shift+down=unbind
keybind = shift+left=unbind
keybind = shift+right=unbind

That way you won't have to have every single default keybinding in your configuration file, just the ones you change.

[nyngwang]

@00-kat I appreciate your advice. But my setting of keybind = clear and the other ones explicitly is to ensure a fixed set of default keybinds I can remember, without worry about Ghostty might change the "sensible default" in the future (so I won't accidentally trigger a keybind I don't know). Just saying that this is just my personal preference, and I'm fine with this redundancy.

(I will update my section to use unconsumed: instead, so it might not confuse people that I were recommending people to remove them forever. These keymaps are still useful when I run programs outside tmux for sure. update: did)