I have an idea of a terminal emulator where you could maximize panes but using a nested structure, does anyone know of one?

Standard "Zoom" features in tmux or iTerm2 only maximize the single active pane to the full window, hiding everything else. If I have a layout like this:

  _____________________
  |         |    B    |
  |    A    |---------|
  |         |    C    |
  |_________|_________|

And I expand B, I want A to hide, while B and C remain visible together. Then I can create a new nested workspace in there and later zoom out when I’m done.

Maybe this could be done arbitrarily deep?

It's not really what you want but in a similar vein check out: zoom.el

https://github.com/cyrus-and/zoom

I guess it's also the kind of thing where screen real-estate is a must otherwise when you're at the "top-level" it would look weird-ish.

This should be simple any time you have panes in a binary tree split view.

The hard part is the UX: making it clear that we're in a zoom state (esp with nested zooms), somehow showing the split-pane tree so that user knows what container will be filled when they zoom, etc.

Fork ghostty and get claude to one-shot it so you can see if you like the idea.

Wouldn't you want a hide option rather than a fullscreen option? so hide A?

When I use zellij, i just move A to a new tab temporarily

You can do this with i3

Hovering it opens a tooltip with details

Not in a single method, no. Watch this talk for more details! https://www.youtube.com/watch?v=wXLf18DsV-I

Well, I did something a bit similar my own language: https://github.com/batiste/blop-language/commit/90e7704e125f... Not sure where classes are an issue with doing anything like this

Why do you care about its style so much?

Because I find that its style reduces code readability.

It's a bit annoying when you have a large project then someone introduces prettier. Suddenly every pull request has dozens of random formatting changes everywhere and it obscures the actual changes. It also completely nullifies the functionality of git blame (I know there are other ways to see the file history).

Run prettier on the entire codebase once and add an ignore-revs-file: https://git-scm.com/docs/git-blame#Documentation/git-blame.t...

How does that help? Genuine question.

> running it on the entire codebase

The autoformatter config file is checked in with the PR that’s runs it on the entire codebase. Everybody’s machine autoformats the same way.

Only things that are changed in the PR will be formatted along with the PR.

The separate problem I’ve found is any outstanding PRs at the time of running it on the whole codebase should merge in the commit before the format all, then the format all change, then current master. It’s made resolving the PR merge conflicts easier

idk what the ignore rev file does

> idk what the ignore rev file does

Sorry - my question was ambiguous. That's the part that I don't understand.

The best way to introduce a formatter is with a git hook on commit/push (for JS projects see Husky), to ensure everyone is onboard and avoid exactly the formatting churn you mention.

Thanks LaurensBER for the ‘git blame’ solution!

https://github.com/typicode/husky

OS X by default lets you rebind the capslock key to esc :)

Might have been this one? https://www.youtube.com/watch?v=RS7IzU2VJIQ&t=0s

https://coneapp.io/?color=#156077 "Blue Stone, aka Green"?

Perhaps it's using one of those luminance-from-RGB vectors somewhere in the calculation? That could overrate the contribution of green to the appearance.

Nope - it's a dull blue, with a _hint_ of green.

FWIW, I don't know if I'm a tetrachromat or not, but I do have a very good colour detecting ability.

Do all 16 million color combinations have names? That would be crazy!

Looks like it chooses from one of 1383 names.

From [0] linked in the footer.

0: http://people.csail.mit.edu/jaffer/Color/resenecolours.txt