Single monitor workflows — which are more ergonomic — make switching spaces a necessity. It might not impact productivity but it is annoying as hell switching around spaces a lot
3 people from my team recently switched to macOS and they never owned a mac before and they are all complaining about window management.
Do you know how dumb it makes me feel to have to tell them they need to install third party apps just to make their system somewhat usable? it's insane.
Exactly! "It just works" used to be true for macos, and linux was for tinkering. Now, ubuntu "just works" (and fast!).
It's not just that macos is slow and window management is strange. Last time I had a macbook (M2 pro) I needed 3rd party software just to use a 4k external monitor without blurring.
Complaining about the distinction between apps and windows isn't a "stupid reason" to complain though.
Say I use Slack, Teams and Outlook. If I use their Electron versions, I switch between them with cmd+tab. If I use them in separate browser windows, I switch between them by using cmd+tab to switch to Firefox, then cmd+` to cycle through windows until I find the one I want. That's weird; how you switch between these three apps depend on the technical details on how you opened them? Why?
Say I have neovim, the mutt email client, and a shell open. These are three separate apps, but because they happen to run in a terminal emulator, I still have to cmd+tab to the terminal emulator, then cmd+` to cycle between them. They're semantically different applications in dedicated windows, but technical implementation details mean they belong to what macOS considers "the same app", just like the "apps in Firefox windows" example above.
It wouldn't be so bad if the cmd+` "cycle between windows in the app" feature worked well. But it doesn't. Unlike cmd+tab, it doesn't show a bar which you get to select from, it just instantly re-orders your windows; and it's impossible to select a window in another workspace. That means, if I have Slack open in Firefox in workspace 1 and Outlook open in Chrome in workspace 2, I can switch between Slack and Outlook with cmd+tab, but if I Slack open in Firefox in workspace 1 and Outlook open in Firefox in workspace 2, there is no way to switch between Slack and Outlook. That's pretty bad.
The (shift+)cmd+` order also resets to match the window z-order whenever you switch apps. So if the order is windows A, B, C, then you select window B, cmd+tab away, then cmd+tab back, the order will now be B, A, C.
I've developed an intuitive understanding of this, but I had to experiment just now to describe the behavior precisely. And my intuition is still wrong sometimes (like if the app has windows on multiple monitors, it's hard to predict the z-order).
> if I Slack open in Firefox in workspace 1 and Outlook open in Firefox in workspace 2, there is no way to switch between Slack and Outlook
My local maximum is to never use workspaces – just cmd+tab, cmd+`, and sometimes cmd+h to reduce screen clutter.
I would also add to this that in order to open two instances of an app the app explicitly needs to support this. For example, you can't open 2 instances of Calculator.app side by side.
If only I could write it down in a text note and refer to it and many more, as opposed to keeping a calculator window open per prior calculation I want to refer to...
Or if only there was a tool like Soulver or Calca...
Yes you can write down the result of calculations and all relevant state and then clear the state of the calculator window before doing a new calculation. But why?
Have your teammates also discovered how macOS handles copy/pasting a folder when the destination folder already exists? How macOS just deletes the entire contents of the destination folder, instead of merging? I remember discovering that for the first time :(
To be completely fair to JJ: you can still use git commands and any aliases with it. I daily JJ in all of my repos but I created these aliases inside of git. That's one of the great aspects of JJ: it's fully compatible with git.
I believe we are thinking about different time horizons, and your language and comparison to <modern editor> reveals a lot about unsaid about your reasoning.
I don't think comparison to other editors is a good basis for deciding what should be pulled in. The vi ecosystem was and remains weird to those outside, but in a way that is internally consistent to the usage patterns of its own user over decades.
Also, percentage of users using X feature is also a bad selection criteria for pulling a plugin provided feature, unless that number is 100% and there is little deviation in configuring it. There is very little friction in pulling in a plugin as a user.
So what are some good criteria for absorbing plugin functionality?
- extensions that provide an API for entire ecosystems (plenary, lazy.nvim)
- plugins that add missing features or concepts that are to useful, and timeless to ignore
- plugins that would benefit themselves or neovim by moving to native code
Honestly, the bar for absorbing plugins should be pretty high. There should be a real benefit that outweighs the cost of more maintenance, coupling, and ultimately cost.
The cost of installing plugins is pretty low, and they are great at keeping the core software simple.
> Any massive infra migration is going to cause issues.
What? No, no it's not. The entire discipline of Infrastructure and Systems engineering are dedicated to doing these sorts of things. There are well-worn paths to making stable changes. I've done a dozen massive infrastructure migrations, some at companies bigger than Github, and I've never once come close to this sort of instability.
This is a botched infrastructure migration, onto a frankly inferior platform, not something that just happens to everyone.
Because we are constantly writing variables that are lowercase. Coming up with a name that is both short but immediately understandable is what we live for. Variables are our shrine, we stare at them everyday and are used to their beauty and simplicity.
Interesting you mention tmux because it itself resembles a terminal emulator. It has its own terminal feature matrix that controls what your parent emulator can render. It sounds like you aren’t using tabs and splits in tmux but it does include them.
It sounds like you could get away with using a tool like https://zmx.sh which only handles session persistence (attach/detach). It also uses libghostty but only for state restoration on reattach.
reply