As someone who probably has a similar setup on Linux to the author: why do you have 10 windows for an app open?
For me, grouping by app is terrible. Yes, they may all be "Terminal" or "Firefox" windows, but they are for very different things. I'd rather see things grouped by project regardless of "app". But that is what tagging window managers are for :) .
Given that macOS forces that (IMO) braindead tunnel vision paradigm, I think the response should be "Wù".
For example, because the app restores its state and you have a few "projects" within the app.
> I'd rather see things grouped by project
Ok, and what if that project is encapsulated in an app window? Why introduce an extra level of indirection for no reason and spend time configuring it? If you frequently need a set of "5 firefox tabs, 2 terminal tabs, 4 text editor tabs, each in a separate app window", sure, spend time tagging it, set it as a WM project and launch/activate it with a key, but not everything is like that.
If you have projects that fit within an app, sure. I do not. The only "apps" seen on my machines are terminal windows hosting tmux processes and Firefox. Everything else is ephemeral (mpv, dialogs, rofi, dunst). App-centric behavior is just the wrong axis for this setup.
I'm saying that given what details are there, I think the author is closer to "my" end of the spectrum than one where the question makes sense at all.
Ok, how does that address my initial question (which was not about you) then? Not everyone's setup is so primitive as to only be centered around two apps
Though in this case I don't get what is so terrible about app groups if you don't group anything else anyway since it's ephemereal, so wouldn't any grouping work (except for 2 apps)?
The Sapir-Whorf is strong in this thread. MacOS' app-centric model makes it hard to even imagine other people's workflows. Stop thinking in apps, think about a task. I have multiple tasks (workspaces). Each task has multiple aspects (windows). Apps are a distraction, an accidental complexity. I want to switch between tasks and then subparts of those tasks.
I know I am weird, but I detest using a MacBook trackpad. However, recently having used Asahi on one, I've found that it is the Apple software that makes it so. I find it really difficult to drag and drop (I would rather open Terminal and standard Unix tools than try anymore) and gestures are way too greedy IMO. Under Linux it is bearable for me (though I still have preferred others slightly for a better texture than the glassy feel).
I wonder if the author is like me in that respect? Not sure I would spend time like this, but I also spent months building my Linux environment from a tty in 2009-2010 (landed on XMonad, finally on River this year after 5 months in GNOME purgatory to force myself to move to Wayland). Last macOS machine I set up, I turned off a bunch of stuff in Settings and was instantly bored because I just didn't want to deal with the window manager at all. It is now my video chat machine because of Dell's "wise" decision to use IPU7 hardware…but I really don't like using it for much else (Asahi reboots are tedious).
They are. If you rewrite history, you get a different hash. You can do some shenanigans with git-replace, but those are usually for stitching history across gaps (like hooking pre-publish history to public release for internal archaeology at least.
What you actually want is a ban on rewriting tags or accepting branch updates to commits that do not have the current commit as an ancestor. These hooks do exist, but are not on by default (beyond the toilet paper protection of needing --force).
You also have to ban deleting branches because otherwise you just delete and push a new one with the same name. Maybe we should store topic branches in repos under refs/topics/ to distinguish integration branches from development/review branches?
That works great for those that only use those tools. I, at least, do not and would appreciate something that doesn't care what editor I use or what forge happens to host the project.
This is truer now that `git bisect --first-parent` exists. But it didn't always. And even then, there are times you find out that there is "prep work" to land your feature. And a PR just to do some deck chair moving that makes a follow-up commit easier is kind of useless. I have done prep work as a separate PR, but this is usually when it is more extensive than the feature and it is worthwhile on its own.
Another instance is a build system rewrite. There was a (short) story of the new system itself and then a commit per module on top of that. It landed as 300+ commits in a single PR. And it got rebased 2-3 times a week to try and keep up as more bits were migrated (and new infra added for things other bits needed). Partial landing would have been useless and "rewrite the build system" would have been utter hell for both me developing and anyone that tries to blame across it if it hadn't been split up at least that much.
Basically, as with many things in software development, there are no black-and-white answers here.
While I also find git-annex more elegant, its cross-platform story is weaker. Note that LFS was originally a collaboration between GitHub and Bitbucket (maybe? Some forge vendor I think). One had the implementation and the other had the name. They met at a Git conference and we have what we have today. My main gripes these days are the woefully inadequate limits GitHub has in place for larger projects. Coupled with the "must have all objects locally to satisfy an arbitrary push", any decently sized developer community will blow the limit fairly quickly.
I also find editing on an iPhone to be an exercise in futility. Is it no longer possible to place a cursor in the middle of a word? I end up having to go to a word boundary and erase from there and retype everything.
The keyboard touch areas also seem offset from Android and I end up one row off too much of the time.
Yes, the UI is so overloaded you can never tell what it's going to do. It might do two or three totally different things. Obviously you want to have the magnifying glass with a cursor. But then the cursor might just decide to jump to the end of the word. Sometimes it's impossible to get the cursor in front of the first letter if the UI is cramped. Maybe it will copy the text into a floating clipboard if your finger drifts a few pixels south. Maybe it will bring up a context menu? If you're using Safari, maybe it won't even let you select any text at all. Then you can take a screenshot and select text from an image to work around that.
Yes but sometimes it doesn't work, weirdly. The cursor just doesn't go where you put it, jumping to the end of the line or next line entirely, where it gets lost in limbo because it's a single line text box. It's ridiculously broken sometimes.
Now that's not a big deal until it happens 3 times in a row randomly and now something that would take less than half a second on a keyboard is taking over 20 seconds. Not only that the random behavior is extremely frustrating which just makes you avoid it in the future.
I use that on Android all the time. But I feel I've only gotten it to work once or twice on iPhone. And even then the word boundaries were very "sticky" (IIRC) and precision placement still very difficult.
I don't know! I remember where I was standing when i realized you could do it, by accident! so i know it's been there since at least 2018, because the building whose smoking area i was standing in got knocked down the next year ^^
I do more writing on my iPhone (it's the one with the largest screen) than I do on a computer. I can do about 40wpm. To move the cursor you just hold down on the space bar. These complaints kind of sound like someone from the 90's saying that the close window button is on the wrong side
Just yesterday I had to edit something on an iPhone. I finally managed to put the cursor at the front to add a word before what was there already. But when I started typing, auto correct (or whatever) put the cursor back at the end of the word. I ended up just removing everything and typing from scratch because figuring out Apple logic behind such a behavior just wasn't on the agenda.
40wpm is 33% less than what a bad typist can do. Repeating "just hold down the space bar" doesn't make it behave any less erratically. We had Palm Pilots in the 90s and they ran on AAA batteries and editing text on them was certainly more consistent than the current state of iOS.
It's not "just", because you have to switch from the more natural "tap where you want to edit" to a separate gesture, which also takes longer and is less precise. You might also use a different keyboard with better layout/symbol visibility that doesn't support this gesture
Coming from android I have to agree, it's terrible. The only help I can offer is that if you press and hold the space bar you can drag to go through to where you need to be, but it's still painful. I can only bear ios because I am using SwiftKey - the default keyboard genuinely stopped me from switching to an iPhone, I found it that bad. And some apps force you to use the default ios one which is even worse!
One big benefit of symlinks (really, "not storing it in the deployment") is that my Git repo doesn't have a bunch of hidden files in it because they can appear in the link's path rather than the repo's path. I can also split up files based on "why it exists" rather than "where it lives". For example, I can have the "enable Rust support" group of configurations:
- add Rust things to the list of packages to install
- add any Rust-specific configurations for Neovim and `zsh`
- bring in any Rust-oriented Neovim plugins
These files all then live next to each other rather than being scatter-shot between Neovim, zsh, and some giant list of packages. Additionally, if I later decide to disable "Rust support" on a machine, the broken symlinks in `$HOME` let me clean up easily without having to actually excise things from the repository.
That said, I have my own system that I built up years ago and it's never been abstracted out for anyone else to use so of course it's going to fit my needs better than anything else.
For me, grouping by app is terrible. Yes, they may all be "Terminal" or "Firefox" windows, but they are for very different things. I'd rather see things grouped by project regardless of "app". But that is what tagging window managers are for :) .
Given that macOS forces that (IMO) braindead tunnel vision paradigm, I think the response should be "Wù".
reply