captn3m0 6 hours ago

What I want at this point is a classic.github.com which uses the old UI from 2013. That was perfect and fast.

  • iLemming 31 minutes ago

    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?

  • the_biot an hour ago

    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.

Pay08 15 hours ago

Really neat. Out of curiosity, does this need to use the Github API? I hoped something like this could be done with plain http.

  • v9v 12 hours ago

    I use https://github.com/TxGVNN/github-explorer for this and even though it doesn't have a C-x C-f nicety (you just m-x github-explorer then type in the repo name) it works via http (or at least I don't recall giving it any API key or anything).

  • iLemming 14 hours ago

    Of course it needs to use the API. How are you otherwise read the private repos?

    • necovek 14 hours ago

      Authenticated HTTP or even SSH should allow it, especially if you are restricting to GH and know how their web URLs translate into git repo URLs.

      • iLemming 14 hours ago

        Ah, okay. I get now what the question meant. Sorry, it's past midnight here and my brain is ketchup. Git's own protocols let you talk to a remote repo without cloning it, so why not use that, right? Multiple reasons:

        - Tree listing. There's no raw HTTP URL that gives you a directory listing. raw.githubblabla.com can't do directory indexes. You'd have to shell out to git ls-tree ... etc over the ssh, which means essentially implementing a partial git client.

        - Getting subtries is also problematic

        - Branch listing and repo search - no git protocol equivalent for those - need the API

        - Current approach fetches the entire tree in one API call. Doing the same over pack protocol means negotiating a fetch, receiving packfile data and parsing it. Much heavier, much more code.

        We can only imagine a world where git's transport layer gives you a browsable filesystem interface. It doesn't - git's protocols are optimized for syncing object graphs, not random-access file browsing.