Customize initial size for quick terminal

[lucymhdavies]

In macOS, it looks like we're setting the default sizes here:
https://github.com/ghostty-org/ghostty/blob/main/macos/Sources/Features/QuickTerminal/QuickTerminalPosition.swift#L10-L29

For example, when showing at the top of the screen, we're setting the height to be 1/4 the height of the screen.
(specifically, this is whichever screen quick terminal first loads on. there's some edge cases around quick-terminal-screen=mouse if you have monitors of varying sizes, which I'm not going to go into right now)

I couldn't figure out from https://github.com/ghostty-org/ghostty/pull/2320/files how this is implemented on other systems. Am I missing something, or is this a macOS-only feature for now?

There are two options we could go for here:

• Allow the user to specify a multiplier in their config, which would default to 0.25
• Allow the user to specify a fixed height

(plus the option of both)

In my case, I would want my multiplier to be 1. i.e. the quick terminal takes up the entire screen. For my specific example, I see no value in specifying a fixed height. My instinct is that most people who use quick terminal have a preference for it to fill "a bit of the screen", "a lot of the screen" or "all of the screen". I imagine pixel-precision sizing of the quick terminal would be a niche desire.
(I could of course be wildly wrong these assumptions)

So were I to implement this myself (and I'm thinking I probably will), my proposal is:

• Add a new config item, e.g. quick-terminal-size-multiplier, with default value of 0.25
• Update where we set the window size, for example height: screen.frame.height * multiplier

There are a few edge cases I'd have to consider (e.g. making sure the multiplier is > 0, and <= 1), but otherwise this feels like it would be a fairly simple thing to implement.

If you're happy with the proposed implementation, I might get a PR raised for it over the weekend.

[mitchellh]

We have a precedent for supporting multiple units within a single config, so my preference would be something like the following:

• quick-terminal-size single configuration
• A value ending in % is a percentage (similar to adust-* configs) of the max
• A value ending in px is a raw pixel value, clamped by max height/width
• A value with no unit is a config error
• A single value is for the dimension that is growable depending on position (for top/bottom its height, for left/right its width).
• A value separated by a comma specifies the secondary dimension with the same format.
  • This doesn't have to be part of an initial PR.

Example valid values:

quick-terminal-size = 25%
quick-terminal-size = 42px
quick-terminal-size = 25%,75%
quick-terminal-size = 300px,80%

Thoughts?

[mitchellh]

Am I missing something, or is this a macOS-only feature for now?

It is macOS only.

[vibe]

We have a precedent for supporting multiple units within a single config, so my preference would be something like the following:

• quick-terminal-size single configuration

• A value ending in % is a percentage (similar to adust-* configs) of the max

• A value ending in px is a raw pixel value, clamped by max height/width

• A value with no unit is a config error

• A single value is for the dimension that is growable depending on position (for top/bottom its height, for left/right its width).

• A value separated by a comma specifies the secondary dimension with the same format.

  • This doesn't have to be part of an initial PR.

Example valid values:

quick-terminal-size = 25%
quick-terminal-size = 42px
quick-terminal-size = 25%,75%
quick-terminal-size = 300px,80%

Thoughts?

Sounds good to me.

This approach is simple enough to allow configuration on one dimension by default, while remaining flexible enough to support full customization of both axes.

My only feedback would be that mixing units feels a bit unintuitive but I’m not opposed to it at all, especially since we already have existing precedents for handling mixed units.

[mitchellh]

My only feedback would be that mixing units feels a bit unintuitive but I’m not opposed to it at all, especially since we already have existing precedents for handling mixed units.

I agree, I'd hope people don't do it, but I don't see a reason to outright reject it.

[mitchellh]

I should add: I imagine people will want different aligned quick terminals too. My proposal with quick-terminal-size is to always center align it vertically or horizontally depending on the position. We can discuss an alignment configuration if that is requested enough but I think we can ignore it for this proposal.

[mitchellh]

Marking this as accepted, if someone wants to PR it as proposed I will accept it. I'm still open to further feedback though.

[vibe]

Marking this as accepted, if someone wants to PR it as proposed I will accept it. I'm still open to further feedback though.

Quick question: Should the parsing and validation of quick-terminal-size happen in zig or swift?

[mitchellh]

It should go in Config.zig with a dedicated type. That type should have tests. You can see some of the other types as examples. I think there is a function you can implement to control how it gets converted to C for the API.

[lucymhdavies]

Good call on quick-terminal-size = 25% or quick-terminal-size = 42px. I hadn't considered that, and it's certainly a more elegant solution.

And...

• A value separated by a comma specifies the secondary dimension with the same format.
  • This doesn't have to be part of an initial PR.

Agreed on that part, I think unless it turns out to be super easy to implement multi-value, the initial implementation can be single value only, and then multi-value support later on.

As for mixing units, quick-terminal-size = 300px,80%
Yeah, it does feel kinda unintuitive, but it's also the kind of thing I can't rule out somebody wanting to do. If we're not implementing this part yet, it's something we can decide on later if/when we do support multi-value.

The only other thing I'd suggest as part of this... unless I missed something, the docs don't explicitly mention that this is a macOS only feature. So I'd also suggest updating the docs somewhere to make that part explicit.

[mitchellh]

The only other thing I'd suggest as part of this... unless I missed something, the docs don't explicitly mention that this is a macOS only feature. So I'd also suggest updating the docs somewhere to make that part explicit.

I thought I put it for the toggle_quick_terminal binding action but I don't see it so I'll add that there.

[JakeWharton]

We talked about this briefly on Discord in the context of a maximum quick terminal width, but for height as well being able to specify the number of display rows would be nice.

[mitchellh]

For the initial work I suggest just doing % and pixels. Rows/columns can come later since the API around that is messier.

[lucymhdavies]

Making a start on this, by defining that new dedicated QuickTerminalSize

The initial implementation is only 1 dimensional, but as we've said, we can make it 2 dimensional later if we want to.

I'm still super new to Zig, so I've spent a lot of time figuring out how to even get this working. I'm expecting a lot of this code is not at all idiomatic.
(and similarly I wouldn't be surprised if there were much simpler ways of achieving this)

d2cf51a

But the tests pass... so I think this part at least works. Unless this needs major changes, the remaining work is on the macOS side.
(Plus docs updates, of course)

I don't know when I'll have time to do any further work, so if anybody wants to pick up what I've got so far and run with it, please feel free!

[futurepaul]

Building on d2cf51a, I added the frontend macOS stuff so I can hardcode my own use case (fullscreen). Unfortunately my naive attempts at using ghostty_config_get to actually read the config didn't work, so I'll need to learn more about what's actually happening in the zig->swift config parsing.

https://github.com/futurepaul/ghostty/commit/66afff7988eb32498fc2a9641b0d359cfdba9007

[lucymhdavies]

Nice! As may have been obvious... I just didn't have the time to finish what I was doing on this 😂
Teamwork :D

So remaining tasks as I see it:

• Zig - Docs
• Zig - implement the formatEntry function
• Swift - Get the zig->swift config parsing working

[futurepaul]

🤝

After playing with my version more I realized it was going off the screen on the bottom.

https://github.com/futurepaul/ghostty/commit/8f70f8a2bd464a37df617c497362a7a26ba10610

Getting the height from screen.visibleFrame fixes it for my use case (100%, coming from top) but it seems like the left orientation is busted and I haven't tried the others (likely something to do with the animation in / out?), so I'll add:

• fix left position when full height
• Test that most reasonable sizes and orientations display correctly,

[donaldguy]

I see the PR is in flight, so maybe preaching to the choir but

I would strongly appreciate some ability to dial in quick-terminal width when in top b/c

I use a 49" ultrawide (LG 49WL95C-W) and the ergonomics for top are pretty bad here:

(cf iTerm:

)

and center is ... okay:

(but top IS much better than center when I unplug and am on the 13" display of the MacBook air that regularly drives that display; right now I deal with switching, but since its a requires-restart config, its not great)

[if anyone is wondering, Safari was being weird about previewing the image uploads; that's why it gets replaced by arc between screenshot 1 and 2)

[donaldguy]

Alas, having chosen to rebase and build first, read Swift later, I discover that even with the 2 number forms of quick-terminal-size that #3742 currently still hard-sticks top and bottom to full-width, e.g. here:

ghostty/macos/Sources/Features/QuickTerminal/QuickTerminalPosition.swift

Lines 65 to 69 in 8f5f432

	func restrictFrameSize(_ size: NSSize, on screen: NSScreen) -> NSSize {
	var finalSize = size
	switch (self) {
	case .top, .bottom:
	finalSize.width = screen.frame.width

(and the other 2 versions)

I suppose the ~problem is that [either you could still default to center OR] you need an additional config here (or a 4 number format?) to specify not only per-se width but also offset from edge

[donaldguy]

Umm, so ... I opened #4716 as a draft PR because it does contain a partial implementation that I probably plan to continue on.

(and I originally was just gonna make a gist of a patch or indeed a ```diff block in a comment on #3742, as I mostly wanted to give @dmehala et al a heads up I was working on an alternative. What would have been the rest of that comment more or less ended up as first comment on this draft: #4716 (comment) )

but then I also got a little carried away and wrote, in order, 3 more lengthy comments:

• 1 one which perhaps would belong more in one or more issues: Mouse resizing behavior

• 2 which almost certainly really should be a discussion?
  "Is this whole approach [to quick terminal (size)] wrong?":

  • (pt 1.) - contemplating whether "quick terminal size" is/ought-to-be handled in terms of a window, or rather more like a pane within a fullscreen (partially transparent) "window"
  • (pt 2.) - contemplating wether adding any more than the existing (pretty specific) quick-terminal-* configs makes sense.

I… don't really think those are in the right place but I also don't know that they could be moved at this point and make sense (but mitchell or any other project admin types, feel free to do so anyway if you disagree)

I also think I'm burned out on thinking about this for the day or at least the next several hours, so … I wanted to go ahead and point these out to potentially interested parties before I give computing a break.

Cheers 😅

[abjugard]

It would be great to be able to specify size in "characters", e.g. old style rows/columns. Perhaps if specified without unit, e.g. quick-terminal-size = 120, 32?

[okuuva]

It would be great to be able to specify size in "characters", e.g. old style rows/columns. Perhaps if specified without unit, e.g. quick-terminal-size = 120, 32?

I don't know if it's in any way feasible (or even a good idea), but I've found it intuitive what some neovim plugins do when defining dimensions: values <= 0 are proportional (percentage of the available space) while values > 0 are absolute (meaning rows or columns. The one (or at least the most) unintuitive thing about it is that fullscreen (either by width or height) means the value needs to be set to 0.

Making it so that floats would always be proportional and and ints absolute would fix that. But then it might be confusing that 30 and 30.0 might be completely different depending on the font size and the screen.

[afanjul]

Hi, is any of the "quick terminal height/size" feature already released? thanks

[avamsi]

Do I understand correctly that 100% will basically be fullscreen and will dynamically adjust to different display sizes (switching the quick terminal between the native display vs an external monitor, for example)?

[lmBored]

For now, a workaround I found it to set window-save-state to always, open quick terminal, use cursor to drag the bottom corner and expand the height of quick terminal to your liking, and that's it!

[avamsi]

@lmBored I don't think that works with multiple displays (of different sizes).

[lmBored]

@lmBored I don't think that works with multiple displays (of different sizes).

That's a good point, haven't tried it with 2 monitors yet, but resizing quick terminal manually is in pixel, so it should work in multiple displays in the sense that quick terminal size remains the same (instead of changing dynamically to scale with screen resolution)

[lucymhdavies]

@lmBored

For now, a workaround I found it to set window-save-state to always, open quick terminal, use cursor to drag the bottom corner and expand the height of quick terminal to your liking, and that's it!

alas, that doesn't seem to persist across application restarts

[lmBored]

@lmBored

For now, a workaround I found it to set window-save-state to always, open quick terminal, use cursor to drag the bottom corner and expand the height of quick terminal to your liking, and that's it!

alas, that doesn't seem to persist across application restarts

Fair point, I made this script to get the window_id of the quick terminal and resize it automatically with yabai. For usage, you can add something like ctrl + alt + shift + cmd - r: ~/script_name to .skhdrc and press hyper + r to resize. It works just perfectly fine for me. (Dont forget to do chmod +x script_name first)

edit: You can also add an event listener so this script only runs when a new instance of yabai is created, like yabai -m signal --add event=window_created action="bash -c '$HOME/script_name'"

edit2+3: Cleaned script, old one is ugly, and handle string returned empty first try.

#!/usr/bin/env bash

LOG_FILE="/tmp/ghostty_handler.log"

function log {
    echo "$(date): $1" >> "$LOG_FILE"
}

function ghostty_manage {
    local window_id
    log "Starting ghostty_manage"

    while true; do
        # Get Ghostty window ID
        # window_id=$(yabai -m query --windows | jq -r '.[] | select(.app == "Ghostty" and (.title | test(":~$|^~$"))) | .id')
        # Get the first matching Ghostty window ID
        window_id=$(yabai -m query --windows | jq -r '[.[] | select(.app == "Ghostty" and (.title | test("^~$"))) | .id] | first')

        if [[ -n "$window_id" ]]; then
            log "Found Ghostty window ID: $window_id"
            GHOSTTY_WIDTH=$(yabai -m query --displays | jq -r '.[0].frame.w')
            GHOSTTY_HEIGHT=$(yabai -m query --displays | jq -r '.[0].frame.h / 2 + 97')

            yabai -m window "$window_id" --resize abs:$GHOSTTY_WIDTH:$GHOSTTY_HEIGHT
            log "Resized Ghostty window $window_id to ${GHOSTTY_WIDTH}x${GHOSTTY_HEIGHT}"
            break # Exit loop once a valid window is handled
        else
            log "No matching Ghostty window found, retrying..."
            sleep 0.5  # Prevents excessive looping
        fi
    done
}

# Check if Ghostty is open before running
if yabai -m query --windows | jq -e '.[] | select(.app == "Ghostty" and (.title | test(":~$|^~$"))) | .id' >/dev/null; then
    ghostty_manage
else
    log "Ghostty is not running, skipping script execution."
fi

[DoctorRyner]

For now, a workaround I found it to set window-save-state to always, open quick terminal, use cursor to drag the bottom corner and expand the height of quick terminal to your liking, and that's it!

@lmBored umm, it doesn't work for me, the quick terminal does not resize at all

[lmBored]

For now, a workaround I found it to set window-save-state to always, open quick terminal, use cursor to drag the bottom corner and expand the height of quick terminal to your liking, and that's it!

@lmBored umm, it doesn't work for me, the quick terminal does not resize at all

You have to hover your cursor to the edge of the screen until the leftrightarrow appears and drag manually. Otherwise you can use the script above to do that automatically, just paste it to some file foo, run chmod +x foo and then ./foo