mathstuf (u/mathstuf)

mathstuf commented on Making macOS Bearable seg6.space/posts/making-m... · Posted by u/seg6

dzhiurgis · 6 days ago

> difficult to drag and drop

Old trick is to enable three finger drag. Does linux have that?

mathstuf · 6 days ago

I don't think so? But I've never had issues on Linux to need to bother with alternatives (as a terminal dweller, drag and drop is very rare there).

mathstuf commented on Making macOS Bearable seg6.space/posts/making-m... · Posted by u/seg6

eviks · 6 days ago

> why do you have 10 windows for an app open?

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.

mathstuf · 6 days ago

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.

mathstuf commented on Making macOS Bearable seg6.space/posts/making-m... · Posted by u/seg6

eviks · 6 days ago

> The "Where's Waldo" Problem

What's your solution to finding one of 10 widows within an app?

mathstuf · 6 days ago

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ù".

mathstuf commented on Making macOS Bearable seg6.space/posts/making-m... · Posted by u/seg6

GolDDranks · 6 days ago

"But for 90% of web browsing, lifting my hand to the mouse is unnecessary friction"

By this point, I realized that the OP uses a normal mouse. The MacBook trackpad is so good that I feel weird using a mouse these days. Also, the travel between the keyboard and trackpad is much smaller.

mathstuf · 6 days ago

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).

mathstuf commented on My Git history was a mess of 'update' and 'fix' – so I made AI clean it up github.com/f/git-rewrite-... · Posted by u/fka

UltraSane · a month ago

Git commit histories should be immutable.

mathstuf · a month ago

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?

mathstuf commented on Announcing Development on Flirt blog.buenzli.dev/announci... · Posted by u/senekor

nsm · a month ago

> But at present, there is a big gap in the workflow: You leave your editor, open a browser, navigate to some page or tab, then navigate to the exact same place in the code you were just looking at, click on a line to open a text box, and finally you can write your comment.

Jetbrains can review GitHub PRs right in the IDE.

mathstuf · a month ago

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.

mathstuf commented on The Theatre of Pull Requests and Code Review meks.quest/blogs/the-thea... · Posted by u/todsacerdoti

IshKebab · 3 months ago

IMO there's no point having a clean history of commits within a PR. With rare exceptions, if you have a PR with a clean history of commits and each commit compiles and passes the tests... they should be separate PRs! If it isn't clean then it should be squashed.

A few exceptions:

1. When refactoring often your PR is "do an enormous search and replace, and then fix some stuff manually". In that case it's way easier to review if the mechanical stuff is in a separate commit.

2. Similarly when renaming and editing files, Git tracks it better if you do it in two commits.

3. Sometimes you genuinely have a big branch that's lasted months and has been worked on by many people and it's worth preserving history.

Also I really really wish GitHub had proper support for stacked PRs.

mathstuf · 3 months ago

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.

mathstuf commented on Git-Annex git-annex.branchable.com/... · Posted by u/keepamovin

fragmede · 4 months ago

GitHub really embraced the Microsoft-esque NIH with LFS, instead of adopting git-annex.

mathstuf · 4 months ago

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.

FD: I have contributed to git-lfs.

mathstuf commented on Apple vs the Law formularsumo.co.uk/blog/2... · Posted by u/tempodox

woah · 5 months ago

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

mathstuf · 5 months ago

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.

mathstuf commented on Apple vs the Law formularsumo.co.uk/blog/2... · Posted by u/tempodox

sorrythanks · 5 months ago

if you hold down the space bar you can use that to slide the cursor around :)

mathstuf · 5 months ago

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.