I used to be a fan of tiling window managers, but I found out that I tend to use fairly visually heavy apps on a Mac. By this I mean apps that need quite a bit of screen real estate to show everything that needs to be shown:

The mail program has a folder tree on the left, the list of messages in the center, and the current message on the right. The IDE has all these tool windows that need showing, in addition to the actual editor. Websites also like it if the window size is a bit more.

Back when I was using Emacs and xterm, mainly, it was nice to show Emacs in the left half and then two xterms on the right.

So instead of tiling, I've come to realize that I only need a couple of window positions and sizes: Mail program and IDE are full screen. The browser occupies 70% width and height, in the top right corner, and the terminal is in the bottom left corner, 200 columns by 44 rows or so. (Lazygit works better if the terminal is a bit larger.) The chat program is full height, 60% width, left edge.

In this way, while the IDE is building or running tests, I can summon the web browser and still see at the bottom and on the left what is the progress of build or test. Also, when I use the software through the browser, I can see a couple of lines of log messages, which is enough to tell me whether to switch.

So I'm now happy with hotkeys in Hammerspoon that reposition and resize the current window to one of these presets, and to jump to a specific app with a keypress. I use a modal for this.

I dig the idea of having multi-level modals, somehow this idea never occurred to me.

I switched from screen to tmux due to rumor about the screen code base. Maybe not a good reason. But I don’t regret it, tmux works well.

Just an honest opinion of someone who didn’t have skin in the game. Not sure if it helps.

Telnet was available in the 90s. I reckon /dev/tcp is way more recent. GP did say a long time ago.

It sounded like something a screen reader would say to help visually impaired visitors. But I don’t actually have a clue what screen readers do say.

For the keys you don’t need to type quickly, M-x can also be typed as ESC x. For any character x.

So it works well with M-|, but not so well with M-f, for example.

Your parent explicitly said amd64 which is the same thing as x86_64. Perhaps you misread amd64 and thought it was saying arm64?

I used to use tiling window managers on Linux, but I found out that my Mac usage contains lots of “graphical” apps that don't like to live in a quarter of the screen or something like that.

So I've embraced overlapping windows. I strategically place them so that the import parts are visible. For example, my IDE is full screen, but the browser is only 70% with and height or so (so that the left 30% and the bottom 30% of the IDE are visible, which conveniently lets me peek into the log of the currently running program.

I have a Hammerspoon configuration that conjures up a modal window on a keypress, and then additional keypresses move the current window to a predefined position and size, e.g. m to maximize and p for the top right corner (70% width and 70% height).

I also have some keybindings in that modal window to jump to an app, e.g. w for the browser, i for the IDE, t for the email client, space for the terminal.

I very very rarely manually move a window around, one of the preset positions/sizes usually works for me.

> I've embraced overlapping windows.

Same. My eyesight getting worse has been a big factor for me. The days of having all my active tools neatly organized and visible simultaneously is over, even with multiple large monitors.

Why not just have all your windows fullscreen and three finger swipe between them like macOS was designed to be used. If you dont like the extremely opinionated macOS window design why not just use Linux?

Here is one thing: I work on a feature branch off of main. It takes me a bit and I want to rebase my branch onto the newest changes.

It seems with the git command line the way to do it is to switch to main then pull then switch back to my feature branch then rebase.

With lazygit i hit f on the main branch which pulls its changes then i can rebase (r) right away.

I also like to review the diff of each file before staging it. I get a nice list of changed files, i can select one and see the diff in it, then I can stage it.

> It seems with the git command line the way to do it is to switch to main then pull then switch back to my feature branch then rebase.

In case you haven't figured it out yet, you can do `git fetch origin` to fetch the latest branches from origin. And then `git rebase origin/main` to rebase the current branch against origin/main. origin/main doesn't have to be the same as local `main` so you don't need to switch branches at all.

I use lazygit as a ui. I like it. I think magit can do way more.

lazygit is a TUI app, IMHO that's a step back. I have many reflections on the widespread anachronism that is emulating a 60s piece of hardware - wanna make a blog post about it, but tl;dr imagine you're writing software for a GameBoy Color instead.

You can't even select multi-line text or use ctrl-c to copy text. It's not all that far from being limited to A/B/start/select/d-pad.

That’s true but boy howdy does pausing the program at a breakpoint change timing!