Default binding for ctrl-shift-plus

[kaddkaka]

On some keyboard layouts plus is produced by holding shift. On both en_US, and en_GB keyboard my computer will cause the inspector to output "Shift+Ctrl+plus" for this combination.

Surprisignly this does not increase the font size.

Other applications like firefox does accept this keybinding to enlarge font size.

For a more expected default behavior, I propose to add keybind = ctrl+shift+plus=increase_font_size:1 to the default config.

(experienced on ghostty version: 1.1.4-main+2b4f1f8b)

Previous discussion held on discord: https://discord.com/channels/1005603569187160125/1367430523361824779

[mitchellh]

Interesting. Just as a note: we can add multiple bindings to a single action, and the last binding usually wins for showing up in menu accelerators (since those usually only one).

[kaddkaka]

What is menu accelerator?

[mitchellh]

That's the keyboard shortcut that shows up for a menu bar (in macOS or GTK). GUI frameworks only allow one of those. It's not a problem because Ghostty will handle all of them but users can't see the other bindings by looking at the menu. I was just making a note of it.

[00-kat]

GTK doesn't currently seem to have font size in the menu.

[00-kat]

Other applications like firefox does accept this keybinding to enlarge font size.

Firefox also allows ctrl+shift+-, but I'm not sure how common that is among other applications.

[00-kat]

Just tried a bunch of terminal emulators, only Kitty and WezTerm seem to bind ctrl+shift+- out of the box.

[rhodes-b]

I think the confusion here comes from how plus is generated ghostty binds two keybinds for increasing font size by default

keybind = ctrl+equal=increase_font_size:1
keybind = ctrl+plus=increase_font_size:1

https://github.com/ghostty-org/ghostty/blob/main/src/config/Config.zig#L4394-L4407

On US style layouts and (GB in this case) it is impossible to generate the plus keycode without shift this happens at a operating system level and does not match how modifiers affect other keys for example like how a capital A is generated.
Typically how keyboard input works is that you will get a raw keycode again lets use a in this example and then you also get modifiers which you apply to that keycode to get a new keycode so to generate A its shift and a put together (you can see this in the terminal inspector)

plus is the only key that I found on a us layout which does not match this behavior where you would expect that plus is shift and equal together (again you can see this in the terminal inspector it will show shift+plus)

on your note about firefox

1. Ghostty does not need to match every default keybind of firefox they are entirely separate programs ghostty should attempt to match keybinds for other popular / default terminal emulators first
2. Firefox accepts if shift is in the combo or not in the combo for increase/decrease font size as in both ctrl+equal and ctrl+shift+plus and ctrl+minus and ctrl+shift+minus (how ghostty represents these keys in the inspector) as such ghostty does already match one of the options for firefox
3. Firefox doesn't even document that shift should even work take a look at their keyboard shortcuts document nor in their developer guide (in the first link its called zoom in the second link its called increase/decrease font size)

Here is another discussion about this "odd" behavior of the plus keycode
#4007 (comment)

I've tried to find a answer to why this happens online but I can't find any information on this topic some reason, I do know that this is how ghostty receives the keycode from GTK though and there is not anything ghostty can do to change that

[00-kat]

The first half already mentioned in the Discord #help thread, FYI.

match keybinds for other popular / default terminal emulators first

How's Kitty and Ptyxis and BlackBox and Foot and WezTerm and GNOME Terminal and GNOME Console and Konsole and QTerminal (LXQT's) and Terminator and Tilix and XFCE4 Terminal for an argument?

[rhodes-b]

Looking at the default keybinds for
wezterm

• supports both with and without shift (increasing and decreasing)

kitty

• requires shift (increasing and decreasing)

ptyxis

• requires shift for increase font size but requires not using shift for decrease font size

blackbox

• matches ptyxis

foot

• supports with/without shift for increasing requires not using shift for decreasing

konsole

• same as foot

terminator

• same as ptyxis

tilix

• same as ptyxis

xfce4

• same as ptyxis

gnome console

• no keybinds work for me? (I see increase works then I get some dbus error and it resets to default but requires shift to increase)

gnome terminal
(I dont want to setup the systemd service to test right now)

[00-kat]

Yep, that's what I got too.

[kaddkaka]

@rhodes-b just listing ctrl+plus in the keybind table is reasonable as that is arguably how most people would think of the key combination. At least to me who is used to a sv_SE layout.

Seems like most terminals support this as well. Any reason to not go ahead?

[kaddkaka]

Can I just go ahead for a PR?

[ilvez]

I haven't looked into whether it was this particular PR that broke increase_font_size:1 for with default configuration on my keyboard layout (+/= are similarly like US qwerty). Currently on keypad Ctrl++ and - work, but on actual Ctrl+= does not work anymore. I added keybind = ctrl+shift+plus=increase_font_size:1 it's still akward, since I would expect Ctrl+= should work for increase_font_size:1, but currently it just printing 1;5u :)

@kaddkaka What your PR was about? I hope you have similar issue as me at this point and your PR targets that issue I have.

No big issue, but worth to ask :) I used to compile new ghostty every day, but like month ago or so fell off the wagon, starting it again. Very nice to be part of bleeding edge..

[ilvez]

Hm wait, I discovered that on my layout Ctrl+] works for increase font. I switched to US qwerty, and it's the same key that has =/+ mapped to it. A key left from right backspace.

[kaddkaka]

I have not had the opportunity to make a PR for this. The idea was just to add one more default binding.

[kaddkaka]

Has someone looked into doing this?

What's the simplest way to do a PR using my phone?

I'm very well versed in git. I'm not well versed in Github forking and PR flow.

Can I just do a one line source code change and supply that as a PR?

[kaddkaka]

Also @mitchellh does your pr "Key Binding Rework"
PR: #7320 affect how this default binding should/needs to be updated? I wasn't able to understand the release notes.

[kaddkaka]

I created a PR to add default keybinding: #9688

[danielwe]

Adapted from #9688 (comment) for any further discussion. Some of this is probably repeating/summarizing info already contained in the various threads here, but in any event this is how I would frame it.

The basic issue is that Ghostty does not match shifted keys to unicode bindings. Ghostty does bind ctrl++ to increase_font_size, but Ghostty doesn't match the shift+= keystroke to + even if that's how your keyboard layout works, and thus the ctrl+shift+= keystroke doesn't match a ctrl++ binding. A binding involving the + can only be matched if your layout has a key for typing + without using shift.

Despite this, cmd+shift+= does work on macOS, because the cmd++ binding is added to the menu accelerator, so it's matched by the OS and triggers the menu action, rather than being matched within Ghostty and triggering the keybind action. macOS matches shifted keystrokes with equivalent unicode bindings.

I think the right thing to do here is for Ghostty to start matching shifted keys to equivalent unicode bindings, like macOS does, rather than explicitly adding extra bindings like ctrl+shift+= on an ad-hoc basis. This is also necessary for creating things like layout-independent vim key tables, which must match, e.g., :, regardless of how that character is typed on your keyboard.

Basically, I think a binding specified as modifiers+unicode should be matched against the keystroke's unconsumed modifiers+codepoint, not all modifiers+codepoint like it does now.¹ (Or maybe both? Or maybe every subset of all modifiers that's also superset of unconsumed modifiers?)

Footnotes

1. Unconsumed modifiers aren't always (ever?) reported by the OS, but the macOS frontend already has a heuristic implementation of this concept that seems to work well and should be applicable in this case too. ↩

[qappell]

My PR #13053 solves this.