But github now handles so much more traffic, without a doubt. I'm not so sure their infrastructure is keeping up, but if it is, the current sluggishness may just be its speed under any load.
If you want to see what it should be, check any forgejo/codeberg repo.
The bigger point is not about "a better UI", it's about having control over plain text. My issue with things like Jira/GitHub/Slack is not that they don't provide nice UI/UX but that they do that each on their own terms - I can't easily edit a Jira comment without having to deal with their shittiest wysiwyg bullcrap; I can't quickly and easily extract a code snippet from a Slack message without wanting to smash my keyboard in anger. If I can see that crap on my screen and can read it, why the heck they make it so vexatiously difficult to extract it and deal with it in something else? Why do I have to go through enormous hoops, every fucking time?
Using Emacs liberated me from wasting my energy for crap like that. Why would I ever complain about GitHub changing/not having/breaking their UI, if I just want to browse files and the well-trodden path for doing just that has existed in my tool belt for years, why wouldn't I just use that?
A lazy-clone virtual filesystem? That is way out of scope for this project.
FUSE needs a userspace daemon and Elisp is not a practical choice for implementing it - you're gonna need to build a CLI companion. Ripgrep and LSP both need access to most or all files. You'd have to fetch every blob, at which point you're fighting the GitHub API's rate limits - not worth it, easier just to clone. CoW would add a local mutation layer, which means state management, conflict detection, and by the time you get there, you're reimagining git itself.
The point about ripgrep worth considering though - maybe search command that hits the search API would be nice. There are some constraints though - 30 requests/minute (I think); it would only work with indexed branches (non main branches may not be); it only indexes files under certain size (something like less than 400Kb); there's no regex; All that makes me think maybe it's better to make it easy to clone/jump to cloned repo instead.
10 comments
[ 2.6 ms ] story [ 35.1 ms ] threadIf you want to see what it should be, check any forgejo/codeberg repo.
Using Emacs liberated me from wasting my energy for crap like that. Why would I ever complain about GitHub changing/not having/breaking their UI, if I just want to browse files and the well-trodden path for doing just that has existed in my tool belt for years, why wouldn't I just use that?
For changed files we could implement CoW, so we could keep modified files without uploading them to remote.
For speedup we could cache files locally.
.... oh yeah, I guess we have all this (dired, ripgrep, lsp, speed) for free when running `git clone <url>` ?
The point about ripgrep worth considering though - maybe search command that hits the search API would be nice. There are some constraints though - 30 requests/minute (I think); it would only work with indexed branches (non main branches may not be); it only indexes files under certain size (something like less than 400Kb); there's no regex; All that makes me think maybe it's better to make it easy to clone/jump to cloned repo instead.