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?

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

It is macOS only.

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.

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.

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.

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

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?

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.

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.

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.

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.

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

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!

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

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

🤝

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,

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)

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:

(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

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 😅