Ghostty's "Zero Config" Defaults

[mitchellh]

(Inspired to ask since I just read: https://arne.me/blog/we-need-more-zero-config-tools)

I've always endeavored Ghostty to be generally acceptable out of the box such that a lot of people can install Ghostty, run it, and not feel a need to customize anything. Of course, there will always be people that want to tweak behaviors and there will never be a one-sized-fits-all config. But, I think we can get a one-size-fits-most.

A lot of the beta feedback already has been the Ghostty already feels really good out of the box compared to other terminal emulators. I'm glad, because I've tried!

As a data point, my configuration right now is only this. I'm not proposing this become the default, just highlighting what my diff is:

macos-non-native-fullscreen = true
macos-titlebar-style = tabs
window-save-state = never

I think that shows that the config out of the box is very good since I only feel the need to have three entries. But it's been a very long time since I took a look at our defaults.

So I went to raise the question: Before we release Ghosty 1.0, are there any configurations the community thinks we should change the default for? If so, please share them here and explain your reasoning. Please think not only of yourself, but of configurations you think that most would want set.

[mitchellh]

Agree, made an issue to track this: #2364

[ldemailly]

My config on macOS is just

$ cat ~/.config/ghostty/config 
theme=Dark+

which if there was a menu to change the theme in the UI I wouldn't even need/know about

speaking of which, even though that's somewhat off topic... I think "New Window" menu should have a sub menu with themes

I realize Ghostty has a million themes so can't have them all in a drop down yet... some sort of short list plus a UI to add/remove which preferred themes the user wants to see in that list would be nice for out of the box experience

[jcollie]

speaking of which, even though that's somewhat off topic... I think "New Window" menu should have a sub menu with themes

Right now, Ghostty does not have the ability to create a new window with a different config. You have to launch a completely separate instance.

I'd love to see this too, although my purpose would not be for a window with a different theme.

[mitchellh]

Right now, Ghostty does not have the ability to create a new window with a different config. You have to launch a completely separate instance.

This isn't true. The core data model supports this and the GTK apprt could definitely do this. But we don't have it all wired up 100% correctly (in core or GTK or anything). But yes, this is definitely a separate discussion topic 😄

[gpanders]

There are frequent questions from macOS users about creating the Option+{Left/Right} mappings to mimic Terminal.app. I think that could be a good thing to configure by default (on macOS only obviously).

[MillerApps]

@injust Yes, that works, but I was hoping to not need a mouse.

[mitchellh]

#3107

[fprotazio]

Is there a way to add the shift modifier so instead of moving back or forward it also selects the text in either direction?

I was hoping for the same. When I read about Ghostty being native, I thought that I would finally have text editing on terminal.

[ringods]

I would also like Shift-Cmd-{left/right} or Shift-Option-{left/right} to make a selection.

[oscar-b]

@mitchellh Any comment on @ringods suggestion to allow selecting stuff on the input?

Skarminspelning.2025-02-05.kl.15.15.08.mov

[mattrobenolt]

macos-non-native-fullscreen = true

I like native fullscreen, I'm curious why that's your default to not use that.

And I have:

window-save-state = always

I've personally always though this was a better experience, especially given frequent updates, restoring between restarts has always been clutch for me even coming from iTerm2. Same as restoring tabs in a browser.

Beyond these differing from you, I set several other things that I acknowledge are personal preferences.

My full config

config-file = ./Dracula
font-family = "Hack Nerd Font Mono"
font-size = 13
adjust-cell-height = 10%

cursor-style = bar
cursor-style-blink = true
shell-integration-features = true

window-padding-x = 8
window-padding-y = 8

command = /opt/homebrew/bin/zsh

confirm-close-surface = true

window-save-state = always
cursor-click-to-move = true

macos-titlebar-style = tabs
window-vsync = true

minimum-contrast = 1

unfocused-split-opacity = 0.8

macos-secure-input-indication = false

[mitchellh]

Oh yeah I totally agree I’m not proposing making it a default. It just shows what my config is.

[mattrobenolt]

Ah, I misunderstood your original intent. I though you were saying "I use these options, so I think they should be the out of the box defaults". But I get what you're saying now.

[ldemailly]

just +1 on window-save-state = always
that should be the default or at least be there for upgrades

plus a FR: save the directory too

[ldemailly]

learned since I needed - sorry for not reading the doc

shell-integration = bash
shell-integration-features= no-cursor

[injust]

Personally, I disabled reopening windows on startup in macOS, and I like that Ghostty defaults to the system behaviour.

As for what's missing, It'd be nice if I could configure windows to restore after an update -- it's all or nothing with the current settings.

[net]

font-thicken = true

better matches the text rendering in Terminal.app and in other apps on macOS (although it still needs #2125 to be perfect).

macos-option-as-alt = true

alt is a common modifier in terminal programs, and disabling it by default on macOS discourages users from becoming more familiar with the terminal.

window-colorspace = display-p3

has arguments for and against it, but subjectively speaking I find that things look washed out without it.

[net]

I wonder if there could be a setting to render Nerd Font symbols with font-thicken = false.

[chaezwav]

It could also be cool if the behavior for icons would just be the unthickened version and then a separate option if you really want them thickened

[mitchellh]

#2930 another stab at macos-option-as-alt

[naruaway]

I think we should not make window-colorspace = display-p3 default. The default should be sRGB.
I even think we should remove display-p3 as an option or we should at least document that this can have unintended effect.
More details are in #4202. In long term, we might want to come up with new terminal escape sequence to specify color space such as P3 like web does.

[jrood]

I agree sRGB should be the default (for parity with browsers) but I definitely want to keep display-p3 as an option.

[rockorager]

window-theme=ghostty

Very much an opinion, but at least on linux I think it's safe. Even ptyxis, which will supposedly be the default gnome terminal has this as the default.

[skatkov]

@tristan957 1.6.2-1

[tristan957]

@skatkov what gtk version? On 4.16, this setup works perfectly.

[valpackett]

The tabs get unstyled with gtk-titlebar = false. Also the overview and the hamburger menu are always unstyled.

[tristan957]

I have a patch for the overview, but it will require libadwaita main. The hamburger menu is fixed on main.

[tristan957]

It would be good to open a bug for window-theme=ghostty not working when gtk-titlebar=false. Thanks 😄

[mitchellh]

I just learned this also works on macOS by default with native tabs. We should definitely be binding this.

[mitchellh]

#2387

[jacakira]

A broader suggestion is have a couple of onboarding prompts on a new install. For example, give people the option to pick a theme, font and titlebar style.

Whilst it is true that the majority of people who use Ghostty will be comfortable making their way around a cli-preference list, I would guess that most people simply won't be bothered. Having an onboarding screen means that even people who would normally find configuration a hassle will be able to easily have a terminal experience that suits them best.

[mitchellh]

I'm not a fan of onboarding screens.

As for CLI-preferences, the plan longer term (but not that long) is to have GUI based preferences as an option as well: #2354

[stepanbujnak]

One thing I love and surprisingly haven't seen in other terminals is window-padding-color = extend and it works well enough to be default.

[gpanders]

This used to be the default but was reverted because there are enough surprising corner cases that a lot of new users were confused by it.

[jcollie]

And there are quite a few of us that don't find it as aesthetically pleasing as others.

[stepanbujnak]

This might be an off-topic discussion but can you elaborate what do you find aesthetically not pleasing? I'm genuinely curious.

[net]

window-padding-color = extend ends up unbalancing TUI elements. Notice how the leftmost "N" and "0: config" have much more left padding than the other elements.

It really only looks good for full-width status bars that span the full native window or pane (so when not using tmux or Vim splits).

[stepanbujnak]

Ah, yes that doesn't look nice. Thanks for the explanation.

[stepanbujnak]

Any reason for window-padding-balance = true to not be the default? I have abandoned my vision to have perfect no-border setup with

window-padding-color = extend
window-step-resize = true

because resizing is broken and window-padding-color doesn't work well as described in the post above, but at least having consistent padding and borders seems like a no-brainer, e.g. when opening a neovim with different colorscheme, mc, k9s, ...

[piechologist]

There are a few bindings that feel a little weird on macOS. My suggestions:

(1) Equalize Splits

keybind = shift+opt+equal=unbind
keybind = ctrl+cmd+equal=equalize_splits

The default hijacks the ± character on US keyboards. Believe it or not, I do use ± in the terminal. Ctrl+cmd+equal matches the arrow key bindings in the Window > Resize Split menu and thus looks more elegant and is easier to memorize.

(2) Jump to Prompt

keybind = cmd+up=jump_to_prompt:-1
keybind = cmd+down=jump_to_prompt:1

These are the bindings in Terminal.app. The default shift-cmd-up/down is usually associated with extending a selection. Cmd-up/down are available (they currently act as simple up/down). I bind them additionally to the defaults.

[mitchellh]

I agree with all of these. Doing them now.

[injust]

I agree with 1) and have had it in my config for months now. I don't use the ± character (TIL that's how you type it!), but it definitely matches the arrow key bindings better.

[injust]

For 2), I'm concerned that binding cmd-up/down by default steps on default keybindings for TUI applications. The first example that comes to mind is nano scrolling using cmd-up/down, which became a no-op after #3078.

cmd-up/down doesn't work great in Terminal.app (with fish) + nano, either -- it jumps between prompts while nano is still running. But at least you can kinda tell that Terminal.app is handling the binding ("Edit" in the menu bar blinks to show that "Edit > Navigate > Jump to Previous/Next Mark" was triggered).

[piechologist]

For 2), I'm concerned that binding cmd-up/down by default steps on default keybindings for TUI applications. The first example that comes to mind is nano scrolling using cmd-up/down, which became a no-op after #3078.

I'm surprised a TUI application binds the super/command key at all. Nano's cheat sheet mentions only control and alt combinations. I may be wrong as I'm not familiar with nano, pico, joe etc. — Are you sure you don't have custom bindings?

[injust]

I'm not too familiar with nano anymore (I switched to micro a while ago) and don't know where cmd-up/down is documented. But I blew away my nanorc and it still works, so it shouldn't be a custom binding.

I'm surprised a TUI application binds the super/command key at all.

I didn't realize this is uncommon. If nobody else runs into this, then I suppose it's a reasonable default.

[bep]

I just installed it and so far so good.

The only option I had to track down was "window padding":

window-padding-x = 15
window-padding-y = 15
window-padding-balance = true

To me, and I suspect I'm not alone, it looks just weird with no padding, so I would nominate "some padding" as a new default.

[z0al]

I agree with the principle but your values are way too high for me 😅 . For reference, iterm2 defaults to 5 horizontal padding and 2 vertical which I find more reasonable.

[net]

I use

window-padding-x = 4
window-padding-y = 4
window-padding-balance = true

[dnut]

Why do you want to waste space with blank pixels? I'm genuinely curious.

I checked all the terminals on my system, and none only one of them adds padding by default:

• tilix
• alacritty
• terminator
• wezterm (actually it does)

[z0al]

@dnut I think your information about wezterm is likely outdated. See official docs here:

The default padding is shown below. In earlier releases, the default padding was 0 for each of the possible edges.

config.window_padding = {
  left = '1cell',
  right = '1cell',
  top = '0.5cell',
  bottom = '0.5cell',
}

[lelopez-io]

I found window-padding-x = 8 works best for me, as it matches the traffic lights on macOS.

[mefengl]

theme = tokyonight

This theme fits better with the website and icon's style.

It's also the default theme in dhh's omakub, see https://omakub.org/#whats-the-dress-code

[pluiedev]

The default theme is actually Mitchell's personal theme and I don't think it's going away any time soon.

[wchargin]

Suggestion, to make Ctrl-Enter and Shift-Enter behave the same as Enter:

keybind = ctrl+enter=text:\r
keybind = shift+enter=text:\r
keybind = ctrl+shift+enter=text:\r

Rationale: I often happen to be holding a modifier key when I press Enter at the end of a command. For instance, I might have just typed a capital letter and still be holding Shift, or I might have just typed Ctrl-P and still be holding Ctrl. macOS Terminal.app and Linux gnome-terminal accept these sequences with no complaint. But in Ghostty, they instead insert codes like ;5;13~ in Bash or Zsh, or 7;5;13~ in Sh or readline applications like python3, or ;5u in Bash in Vim 9's terminal.

Since it seems to be very common for applications to not handle these sequences in what is presumably the intended manner, it's not clear to me why a user might prefer this behavior. Perhaps the default should be that Ghostty instead send just \r when Enter is pressed with any modifiers. There may be other mappings here that I've not covered. (I had to teach iTerm2.app about Shift-Space, but Ghostty handles that fine.)

See also #3151 for more discussion.

[m1keil]

keybind = cmd+i=inspector:toggle should be probably the default as well to mimic Terminal.app and other macos utils that usually default to CMD + i for similar style of info (although safari seems to prefer cmd+alt+i).

Right now, the default seems to be: keybind = cmd+alt+i=inspector:show

[EviLuci]

Just my personal opinion, but i am not a fan of having Ctrl + Enter as the default keybinding for toggling fullscreen. In my opinion, most operating systems already have built-in shortcuts to maximize or toggle fullscreen for windows. Adding this keybind as a default feels unnecessary for me. I have been using Ctrl + enter for custom keymap and in my opinion, most terminal users have ctrl + enter custom keymap for other purpose already which may conflict with the default keymap of ghostty.

font-family = "Firacode Nerd Font"
font-size = 10
theme = "tokyonight"
background-opacity = 0.9
window-decoration = false
confirm-close-surface = false
command = /usr/bin/fish --login --interactive

keybind = ctrl+shift+/=new_split:right
keybind = ctrl+shift+-=new_split:down
keybind = ctrl+shift+x=close_window
keybind = ctrl+enter=unbind

this is my config so far. I am pretty okay with other defaults. The other 3 keybinds are my personal preference but they seem better sensible keybind than the defaults like Ctrl+Shift+e and Ctrl+Shift+o for me at least.

[daviewales]

Cmd + Enter is the default keybind for toggle full screen in iTerm 2.

[EviLuci]

that may be true but it still doesn't justify having it as a default for Ghostty as well. I use linux and most linux distros allows to set up a global keybind to toggle fullscreen that works not only for terminal but for any window. I don't know about mac but i believe it is possible with mac as well to set up a global keymap to maximize a window. So I believe, relying on the global fullscreen shortcut is better for consistency across apps. so why not remove that default leaving users free to repurpose Ctrl + Enter for other terminal tasks if needed.

[daviewales]

On Mac the global full screen shortcut is Command+F. iTerm 2 uses Ctrl+enter to toggle maximising the window, which is different to the native full screen on Mac. For example, my main use for it in iTerm 2 is to maximise and unmaximise my dropdown terminal. Normally it is only half the screen height, but sometimes I want to briefly expand it without entering the native full screen mode.

[pluiedev]

Personally I find it also a kind of confusing keybind for Linux. Linux doesn't have the same native/non-native fullscreen concept and so the distinction doesn't really make sense. As for the specific replacement I think KDE's (maybe former?) default Ctrl+Shift+F is pretty sensible, although perhaps F12 also works. (Maximize is Meta + PgUp, which is honestly kinda stupid...)

[00-kat]

Isn't F11 usually the fullscreen keybinding? Or is that only a browser thing?

[samhh]

I only have around a dozen things in my config, mainly making Ghostty behave more like the terminals I'm used to. The one thing that I think should be a default is something similar to:

background-blur-radius = 20
background-opacity = 0.9

It feels appropriate to me on macOS as a platform, and given the platform's unique hardware situation there's not much to worry about in terms of performance. I've seen countless folks similarly configure iTerm over the years.

I'd guess therefore that most macOS users are configuring something like this; of course if I'm wrong about that then this doesn't apply.

[jdelStrother]

Just wanted to chime in as a counterpoint - speaking as a macOS user who lives in the terminal, I don't understand the trend of making your terminal less legible with transparency.

[inoperable]

That was my point in the first place- but to know that how to get there, assumes you know the needed options you can modify. I don't know the options, nor could i find those

[softprops]

Moving thoughts in #4320 here

I found a few cases where configuration I have could be reduced

1. provide a consolidated window-padding setting as an alt needing 2 settings, window-padding-x and window-padding-y.
   For consistent window padding I'm using the follow

window-padding-x = 10
window-padding-y = 10

I believe this could be expressed more simply with window-padding: 10. If I needed different x and y padding I could opt for window-padding: {x},{y} and if I needed different x1,x2,y1,y2, window-padding: {x1},{x2},{y1},{y2}. This is roughly inline with the semantics of today's version

2. have window-title-font-family inherit from font-family
   When I set font-family today, several settings inherit from that which I benefit from because it means less configuration is needed to get a consistent font-family. Today window-title-font-family does not inherit font-family which, for me, requires setting two font-family settings instead of one for a consistent font-family experience.

Given the setting

font-family = "Comic Mono"

I see the follow resolved config

ghostty +show-config | grep font-family
font-family = Comic Mono
font-family-bold = Comic Mono
font-family-italic = Comic Mono
font-family-bold-italic = Comic Mono

I would love to see window-title-font-family included in that list.

I'd be willing to chip in to help on either or both of these config reduction opportunities of folks are open to the idea

[bulletmark]

I quite like the simple idea of vim ctrl+shift+j to easily be able to search and/or mine my screen history. However, I find it very odd that the current screen is not included in the scroll-back record. Then I found some issues and discussions here to discover thatwrite_screen_file exists as an alternative to the default write_scrollback_file. Surely 99% of users would prefer write_screen_file and thus it should be the default for ctrl+shift+j?

[daviewales]

I've configured the following:

keybind = ctrl+shift+s=new_split:auto

But I feel that new_split:auto might be a good candidate for a default keybind.

[daviewales]

For a more 'native' feel, consider setting the default font to match the default font in the default Terminal on a given platform. For example, on Ubuntu based systems, it's probably:

font-family = Ubuntu Mono

On Windows, assuming Ghostty gets a Windows release, the default font would be Cascadia Code.
On Mac, I believe it's SF Mono, and on older releases it was Menlo.

Also, on low-dpi Linux systems, I've found it's good to set the following to avoid fuzziness:

font-style = Medium

[alec-c4]

I believe this binding will be useful too :)

keybind = cmd+r=clear_screen

[neitsab]

I'd like to suggest making the default theme switch between light and dark mode depending on OS settings, like modern GTK4/libadwaita apps.

See #4875 for details on the motivation/user scenario.

This would entail two things:

• create/choose a default light theme to go with the current dark one
• name the default theme so that it can be set using the theme=light:default-light,dark:default-dark config syntax.

I feel it is a reasonable user expectation for a modern terminal app to respect their OS theme mode and switch appropriately, and was really surprised/confused when I realized it wasn't the case and I had to manually look into themes for this to work.

This and scrollbars (#111) are my current most desired items.

Thanks for the great work!

[00-kat]

I believe they are talking about theme and not window-theme.

[mitchellh]

I know. But we're not "ignoring the OS theme," programs like iTerm and Terminal.app also ship out of the box with only a "dark" theme (while the window is light). I just wanted to clarify that point. I'm not rejecting this idea, just pointing out a detail in case someone misunderstands.

[apparebit]

I wrote "ignoring the OS theme" because when I set theme to system, the window remained white text on a very dark background. I just tried setting it to light too, with the same result.

I couldn't find an iTerm option for following the system mode (to avoid the overloaded "theme"), but changing that at Settings > Appearance > General is straight-forward. You are right that ITerm doesn't change the color theme, i.e., assignment of abstract ANSI colors to actual RGB color values. Terminal.app is more dynamic: It automatically adjusts to the system's dark or light mode. Based on sampling one color (a bright green), it also adjusts color values. Though oddly, it increased brightness for dark mode, which runs against best practices recommendations for dark mode appearance.

If the majority of Ghostty users prefer sticky mode, then I would suggest adding a user interface for changing the mode without touching the config file directly. To me, that does run counter the "zero config" claim because I need to configure Ghostty in addition to my system. A UI would make that contradiction much easier to ignore 🤪

Also, how about changing window-theme to light-dark-mode or window-mode to avoid confusion with theme?

[net]

Terminal.app does by default adapt to the system theme. The Terminal.app window theme always matches the system theme (not the terminal theme), and the terminal theme Terminal.app ships with out of the box uses colors from the Developer palette that automatically adapt to the system theme.

I wonder if your Terminal.app settings were initialized on an older version of macOS before they switched to using the Developer
palette for the default theme @mitchellh.

[00-kat]

• create/choose a default light theme to go with the current dark one

FYI #5437 exists for this now.

[net]

I just saw #4531, which adds font-thicken-strength. Ghostty renders fonts thinner than other macOS apps, and font-thicken = true renders fonts thicker. (See #2122 for an example.)

I played around with font-thicken-strength, and it seems like a value of around 70 matches the rendering of Terminal.app, iTerm2, and TextEdit (@qwerasd205 might know the exact value).

Therefore, I propose setting a default so that font-thicken = true matches macOS font rendering out of the box:

font-thicken-strength = 70

---

I also propose reconsidering adding the default

font-thicken = true

A quick search of the Discord reveals a lot of recent users with a preference for font-thicken = true. Just a sample from the past few days:

I just gave Dank Mono another go, with the font-thicken set to true, and the strength set to 100 rather than 255, it looks so good, has normal 7s, strike through 0 rather then the dot, that sexy af symetrical Q. I'll give it a few days but I'm pretty convinced I'm going to buy it! It is really nice with those settings and size 11.

Hi all,
Fairly new to terminals, nvim etc etc so bear with me, but have previously used iTerm2 with some kitty ad well. When comparing ghostty I note the font weight to be quite thin - is this something I can alter in settings?

Its all good. Just increasing the font weight and the font-thicken option helped to get rid of most of it. Kinda just depends how crisp you want your fonts.

Seconding font thickening. Also generally having the font a lil bit bigger helps. It definitely depends on the font though.

I use font-thicken, it did the job for me

Does anyone know how to improve the font antialiasing on macOS? It seems to render fonts too thin compared to other apps (e.g. VS Code, iTerm, Terminal, ...pretty much anything). font-thicken helps but it also results in the text not being crisp.

with all that in mind, i’d personally suggest not having the strength of font-thicken be an option. rather, the strength should depend on foreground lightness on a per-glyph basis. i’d also say that font-thicken should be on by default on macos to match other native apps on the platform.

"SF Mono on Ghostty doesn’t look the same as TextEdit and terminal.app until I enable font-thicken, on a Retina display" 💯 Retina 27" here, need thicken enabled to match how SF Mono looks on Terminal.app, otherwise it's too thin.

---

From @mitchellh https://discord.com/channels/1005603569187160125/1005603569711452192/1324863135915708517:

I haven't been able to find the docs for this for awhile, but Apple's recommendation is that its only enabled for non-Retina screens. You can see this to be true since Qwer did a bunch of analysis and found our fonts to render pixel perfect with things like TextEdit (no font-thicken).

I've been meaning for awhile to change font-thicken to an enum auto, false, true where "auto" would automatically enable thickening on non-Retina screens.

I believe iTerm2 does this, actually.

I don't know where this came from, but this is not what TextEdit and Terminal.app do when I test them on a 14-inch MBP screen and on 5K LG UltraFine screens. Both always render a thickness that matches Ghostty's font-thicken = true; font-thicken-strength = 70.

iTerm does have this in its docs (emphasis mine):

Anti-aliased text will be drawn with thinner strokes by default on Retina displays when the background color is darker than the foreground color. The effect may be more or less visible depending on your particular hardware and OS version. You can configure when thin strokes are used depending on display type and colors.

But I believe iTerm actually defaults to never.

[hartzell]

I've been using v1.0.1 for a couple of days now and so far only have these two changes. I've been typing at terminals for quite a while and long ago gave up trying to keep track of where various keyboards put the escape and tab keys; my fingers are trained to hit ctrl-i for tab and ctrl-[ for escape.

keybind = ctrl+left_bracket=text:\x1b
keybind = ctrl+i=text:\x09

[hartzell]

FWIW, the most surprising thing that I did not configure and that just worked is mouse scrolling in emacs in terminal mode (emacs -nw):

• In iTerm2, scrolling the mouse scrolls the terminal window.
• In Ghostty, scrolling the mouse is like leaning on the arrow keys.

My new-to-me LazyVim config also responds to mouse scrolling more sensibly.

I'm not sure why it's happening by default, but I like it.

[00-kat]

The alternate screen which TUIs use doesn't have a scrollback, so Ghostty has two choices when you scroll:

• Do nothing.
• Send arrow keys, since many TUIs use arrow keys to scroll or navigate up/down.

And as far as I can tell, Ghostty chooses to do the latter.

I'm not sure why iTerm2 scrolls the terminal window.

[hartzell]

@00-kat -- Thank you for the explanation!

[injust]

On a MBP Retina display, the bar or block_hollow cursors seem too thin at the default cursor thickness (which I believe is 0.5pt/1px).

For block_hollow, depending on the position of the cursor, some edges appear to be grey or dim white. This happens at any font size. I can't really capture this in a photo, though.

When I set the config to:

cursor-style = block_hollow
shell-integration-features = no-cursor

and spam open a bunch of splits, it's more noticeable.

I ended up adding this to my config to fix it:

adjust-cursor-thickness = 1

However, on a non-Retina external display, the cursor already looks fine. The above config makes the cursor much too thick.

[frangio]

The system-wide default on macOS is to hide the mouse while typing. Currently Ghostty defaults to mouse-hide-while-typing = false which feels out of place with the rest of the OS. I believe true would be the right default for macOS for the "zero config" goal.

[timvisher]

From #4809 (reply in thread)

I just had to add

keybind = alt+left=unbind
keybind = alt+right=unbind

to my config to support the expected behavior for me in TUI Emacs on macOS.

I find it especially odd that by default Ghostty is translating M-<left> into M-b and M-<right> into M-f but M-<up> and M-<down> are both passed to the underlying process verbatim. I'd expect them all to be translated or none to be translated. ¯\_(ツ)_/¯

[00-kat]

The rationale for that change is #2363 (comment).

[00-kat]

It's also worth noting that these two keybindings are very problematic in that many people end up unbinding it, but also many people would complain if they were removed.

[timvisher]

👂 That's helpful to know.

It's also worth noting that these two keybindings are very problematic in that many people end up unbinding it

Meaning that many people do what I have highlight here?

but also many people would complain if they were removed.

And a potentially equal number of people would be sad if unbinding was the default?

[00-kat]

Meaning that many people do what I have highlight here? […] And a potentially equal number of people would be sad if unbinding was the default?

Precisely.