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).

[injust]

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

@MillerApps This already exists by default -- shift+{up,down,left,right} is bound to adjust_select:{up,down,left,right}.

Have you tried selecting with the mouse and then using those keybindings to adjust the selection?

IIRC Ghostty needs to have an active selection for the keybindings to work, to prevent Ghostty's keybindings from stepping on other TUI applications that also want to bind shift+arrow keys.

[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.

[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.

[mitchellh]

#2457 for macOS-option-as-alt

[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.

[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 checked all the terminals on my system, and none of them add padding by default:

• wezterm
• tilix
• alacritty
• terminator

[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

[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.

[mitchellh]

Use a new Q&A discussion to ask a specific question of what you need help with. This is off topic.

[valpackett]

adjust-cell-height = +15%

The vast majority of fonts feel super claustrophobic with a 1.0 line height. +15% feels good for JetBrains Mono.

[tristan957]

I disagree with this. I like the current default 😄

[CasEbb]

A 1.2 line height is actually recommended for JetBrains Mono (https://www.jetbrains.com/lp/mono/ -> "Recommended settings for the font")

[daviewales]

I find even the default JetBrains Mono feels much too tall.

[nervenes]

My config on macOS

font-size = 12 # the default (13) was too large compared to all other apps on macOS by default, so i'm kinda between 11 and 12 here
font-family = SF Mono # like to use the apples mono space font as it matches with the rest of the system i.e Terminal.app, Xcode.app, Console.app, Instruments.app, etc...
font-thicken = true # similarly here, to match with the rest of the system

# cursor config to match close to Terminal.app
cursor-color = grey 
cursor-style = block
cursor-style-blink = false
adjust-cursor-thickness = 2
shell-integration-features = no-cursor

# i prefer the native titlebar
macos-titlebar-style = native

# the rest of the config is just colors and themes
...

I do also want to change the font line/cell height and window padding to match better with the rest of the system, I've just never gotten around to it yet

[vunhatchuong]

Since I use Tmux and Tiling WM, I disable every keybinds except copy, paste and change cursor size.

theme = dark:sequoia-monochrome,light:NvimLight

window-decoration = false
window-padding-x = 8
window-padding-y = 8
window-padding-balance = true
background-opacity = 0.9

cursor-style = block
cursor-style-blink = false

font-size = 15
font-family = JetBrainsMono Nerd Font Mono

mouse-hide-while-typing = true
resize-overlay = never

copy-on-select = clipboard
confirm-close-surface = false
shell-integration = zsh
shell-integration-features = no-cursor

# Disable default keybindings
keybind = super+ctrl+shift+up=unbind
...

Disable almost all keybinds

# Disable default keybindings
keybind = super+ctrl+shift+up=unbind
keybind = super+ctrl+shift+equal=unbind
keybind = super+ctrl+shift+left=unbind
keybind = super+ctrl+shift+down=unbind
keybind = super+ctrl+shift+right=unbind
keybind = ctrl+alt+shift+j=unbind
keybind = super+ctrl+right_bracket=unbind
keybind = super+ctrl+left_bracket=unbind
keybind = ctrl+alt+up=unbind
keybind = ctrl+alt+left=unbind
keybind = ctrl+alt+down=unbind
keybind = ctrl+alt+right=unbind
keybind = ctrl+shift+a=unbind
keybind = ctrl+shift+o=unbind
keybind = ctrl+shift+q=unbind
keybind = ctrl+shift+n=unbind
keybind = ctrl+shift+page_down=unbind
keybind = ctrl+shift+comma=unbind
keybind = ctrl+shift+left=unbind
keybind = ctrl+shift+w=unbind
keybind = ctrl+shift+j=unbind
keybind = ctrl+shift+right=unbind
keybind = ctrl+shift+page_up=unbind
keybind = ctrl+shift+t=unbind
keybind = ctrl+shift+tab=unbind
keybind = ctrl+shift+e=unbind
keybind = ctrl+shift+enter=unbind
keybind = ctrl+shift+i=unbind
keybind = alt+five=unbind
keybind = alt+eight=unbind
keybind = alt+three=unbind
keybind = alt+nine=unbind
keybind = alt+two=unbind
keybind = alt+four=unbind
keybind = alt+one=unbind
keybind = alt+six=unbind
keybind = alt+seven=unbind
keybind = ctrl+comma=unbind
keybind = ctrl+page_down=unbind
keybind = ctrl+enter=unbind
keybind = ctrl+page_up=unbind
keybind = ctrl+tab=unbind
keybind = shift+insert=unbind
keybind = shift+up=unbind
keybind = shift+left=unbind
keybind = shift+page_up=unbind
keybind = shift+end=unbind
keybind = shift+right=unbind
keybind = shift+page_down=unbind
keybind = shift+down=unbind
keybind = shift+home=unbind

[00-kat]

It would be easier for you to do something like this:

keybind = clear
keybind = ctrl+shift+c=copy_to_clipboard
keybind = ctrl+shift+v=paste_from_clipboard
keybind = shift+insert=paste_from_selection
keybind = ctrl+equal=increase_font_size:1
keybind = ctrl+minus=decrease_font_size:1
keybind = ctrl+zero=reset_font_size
keybind = ctrl+plus=increase_font_size:1

[vunhatchuong]

Oh I didn't know you could do that, thanks

[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.

[00-kat]

I ended up unbinding it because I often hit Ctrl+Enter when meaning to hit Enter and Ghostty becoming full-screen all of a sudden is disorienting for me.

[EviLuci]

yeah, I feel like new users might accidentally trigger it without realizing what happened, especially if they're accustomed to using it for other purposes as Ctrl + Enter is a common keybind i see people using.

[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.

[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!