Add Github permalink support

[OriR]

Having this plugin analyze Github permalinks would be great if you want to reference an existing code in a repo!

One way I thought it could be implemented was that instead of supplying the user & gist hash you could just point to a specific url and download the contents of it (keeping the highlighted rows search as is).

Something like
gist:https://github.com/weirdpattern/gatsby-remark-embed-gist/blob/66bb462203a990cdba85ea594c1cc1431845cba0/src/index.js#L29-L34

If there are no highlighted rows just preview the entire file.
If the entire file or the amount of highlighted rows is too big, show only a certain number of lines, let's say 15 (allow the user to configure this number in gatsby-config.js).

[weirdpattern]

Thanks for this great suggestion @OriR

I though of adding this feature when I was building this plugin, but figured a shorter more concise version would be better. Having said that, I still think the plugin should honor permalinks, kind of the same way dependencies are managed in the package.json...

I will work on this over the weekend and post a PR for you to review.

Thanks

[weirdpattern]

@OriR and others (if anyone else is following this)...

Two approaches...

First approach

• Expand the gist: tag to accept gist URLs

1. Keep support for the short version (current).
2. URLs can use github's own highlighting syntax (e.g. https://.../#file-example-sh-L10).
3. URLs can use the plugin's own highlighting syntax (e.g. https://.../#file-example-sh?highlights=1,4-5).
4. URLs can use a combination of both (e.g. https://.../#file-example-sh-L10?highlights=1,4-5).

• Add a new github: (or glob: - github blob) tag that will behave exactly like gist:, but for blobs (the permalinks you are describing in here)

Second approach

• Deprecate gist
• Add a new github: (or glob: - github blob) tag that will handle both gists and blobs.

--

In any case the blobs will require some parsing as these URLs return actual pages and not JSON structures...

[OriR]

@weirdpattern Awesome! thank you so much for looking into this (can't believe I missed your first comment)

In the second approach, if you mean removing the highlights parameter as well, then I think it should still be supported.
The github highlighting API doesn't seem to support sparse highlights while this does which is a cool feature!
I also think that glob is confusing because it has a different meaning of matching files.

I would favor the second approach because all that differs between gist and github is the URL, which you already pass and makes the distinction between gist & github. What would happen if you were to do (by mistake) gist:<github-url> or github:<gist-url>? would it fail? would it follow-through to the right API?
Because it's unclear, I'd say it's better to combine them.

[weirdpattern]

@OriR

In the second approach, if you mean removing the highlights parameter as well, then I think it should still be supported.

No, I wasn't planning on removing the highlights, on the contrary, I want it to be supported by both. As you said, github doesn't support sparse highlights, which is something I use a lot...

What would happen if you were to do (by mistake) gist:<github-url> or github:<gist-url>? would it fail? would it follow-through to the right API?

In the first approach, it would fail... I see no point in having two tags if both are capable of doing the same... that's why I like the second approach too... Only one thing bothers me... the name of the plugin... not sure if this will lead people into believing it only works with gists... anyway... not a deal breaker...