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.
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.
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.
Data point: I develop in Java and I use IntelliJ. I run everything in debug mode. So it’s really easy for me to enter the debugger.
But I find that if I have to step around more than a handful of times to find the issue then I forget what happened five steps ago. So I teach for print debugging quite often.
It’s very interesting. I’ve tried to observe myself. It seems that if I can see a breakpoint somewhere and then examine state and then see what the problem is, a debugger is great.
If, however, it’s something where I need to examine state at multiple times in the execution, I lose track in my mind of the state I’ve seen before. This is where print debugging shines: I can see how state evolved over time and spot trends.
You’re misunderstanding. In those other apps the behavior is this: you open a document. You put the cursor on line 3 column 3. You use the mouse wheel or trackpad to scroll down to line 600. You hit cursor right. The cursor is now on line 3 column 4.
In emacs the cursor would be somewhere around line 600 instead.
It should be possible to save the cursor position, hide it if it moves away from view during scrolling, and restore it back on any command but scrolling, or at least at the firs cursor-movement command.
