As requested by @vermiculus on Gitter, filing this as an issue.

Feature Request: Browse GitHub and Gist files directly

I often crib bits of configuration from init.el files on GitHub. (For instance, to find the best use-package incantation for a new package I haven't used before). In these cases, I need the raw file (so e3w and other web browsers are less desirable since they can add or remove whitespace and do other mangling), but I don't want to clone the repo (since this is a one-off use).

Another common case of this is Gists—cloning a Gist can be painful, and you rarely actually need to make modifications.

For these cases, a way to open the raw file content in a (by default) read-only buffer (of the correct auto mode) would be very useful.

Suggested UI

I can think of three frequent entry points:

1. You've searched up a code snippet and are staring at it in a browser. You have a full blob URL like https://github.com/vermiculus/magithub/blob/master/README.md, and perhaps from a search, one with a branch, commit, and/or line number (https://github.com/vermiculus/magithub/blob/e5c7e2d99dec14ad74f52be85db94d1c175856f7/test/mock-data/get/repos.d/vermiculus.d/magithub#L13).
2. You have a Gist and would like to browse its files (probably just one, but sometimes a tree) using only the Gist identifier or URL.
3. You have the username/repo pair, a filename, and perhaps a branch if not master. So, vermiculus/magithub??notmaster??/README.md, with ?? representing "some relatively easy-to-type separator."

Specific interactives seem like the right choice for the first (e.g., M-x magithub-browse-url RET https://github.com/vermiculus/magithub/blob/master/README.md RET) and second (e.g., M-x magithub-browse-gist RET gist-url-or-id RET).

(For the second and possibly the first as well, if the result is a directory tree containing a single file—as will often be the case with Gists—I think the behavior should be to auto-open the single file; I can't think of a case where browsing a dired containing a single file would be useful.)

I would suggest a TRAMP hook as being ideal for the third case, except I don't know if the GitHub API is sufficient for the kinds of requests oft-used packages like Helm will automatically do to allow for completion and displaying sibling nodes interactively.

As an alternative, though, an interactive with some way to enter a file name from the POV of the package—without having to deal with blob/master and such—would be a good compromise.

(Regardless, this feature would need to deal with tree discovery, since you'll have cases like the second Gist case above where the result will be a dired buffer.)

Perhaps a trailing #N should be captured by magithub and translated into a request to place point on that line.

Obvious extensions of functionality for later

• The ability, while visiting a buffer in this way, to do file-oriented operations, including
  • Cloning and/or forking the repo containing the buffer's content, and perhaps adding it as a submodule to an existing repo magit is tracking
  • Viewing a dired of the buffer content's sibling or parent nodes
  • Perhaps, in addition to C-x C-w to write out the file locally, a way to write it and immediately commit it to your own repo.
• The ability to make the buffer read-write (in the usual way, toggling C-x C-q) modify it, and "save" directly into a new commit on GitHub, a la "Edit" in GitHub's web browsing interface. (Provided you have permission to do so, of course.)
• Hooks/customization to use gitlab, bitbucket, and other non-GitHub sources.

Thanks very much!

Thanks for the great write-up! I'll note that for now, github will be prioritized over other content providers. Overall support for others (gitlab, etc.) are being tracked in #81.

Related to #160