See for example: http://appcachefacts.info/peterlubbers-owc4/index.html

The best part of using Appcache is -- IMHO -- that either all resource files are refreshed or none.
I've noticed a few times when pushing to gh-pages, that for example loading DocGist or GraphGist will end up with a mix of old and new files. Which usually means some things are broken.

The bad part is that the manifest has to be maintained somhow (or generated, I hope).
Also, changes to the resource files won't be picked up (ever!) unless the manifest gets changed (it might just be a change in a comment).

We've been using the convention of setting implicit attributes that identify the runtime environment to allow other settings, such as imagesdir, to be setup properly.

I recommend setting the following implicit attributes for gist.asciidoctor.org:

• env=docgist
• env-docgist
• platform=opal
• platform-opal

This might be used to setup the imagesdir as follows:

:imagesdir: images
ifdef::env-docgist[]
:imagesdir: https://github.com/asciidoctor/asciidoctor/raw/master/images
endif::[]

In contrast, when the document is converted on the GitHub servers, the attributes env=github and env-github are set.

Also use the stylesdir attribute as well, if it has been set.

GitHub now serves raw user content from the domain raw.githubusercontent.com. DocGist should be updated to recognize this domain instead of raw.github.com.

For more information about the switch, see this blog post: https://developer.github.com/changes/2014-04-25-user-content-security/

Add instructions to the README that explain how to run DocGist locally for testing purposes.

We're using DocGist to collaboratively edit a couple of team documents but other than the recently edited list of documents we need to keep track of URIs to those documents. Would be cool if there was a DocGist-native way of doing so.

I am not sure what the safe mode used by gist.asciidoctor.org is.

I am trying to render this document:

• Page on GitHub
• Raw content on GitHub
• Preview in gist.asciidoctor.org

The includes are replaced by links, maybe because we the safe mode is set to secure. This is Ok for me.

It would be great to have the links working and pointing to the corresponding page in the gist.asciidoctor.org preview.

For example the first link ../../../../adoc/CreateNewProject.adoc should point to the preview page adoc/CreateNewProject.adoc.

Pretty amazing tool. I have to say I'm impressed! Real-time collaboration is a big plus that should be highlighted more I think.

Anyway, those interactive documents (with links that start with fp-...) are hosted in firebase, correct?

Where is that data stored? If I don't pay for that storage, what's the catch? Is it an API key shared with all docgist users or a free distributed database service? It's not documented.

I would like to store sensitive documents in my docgist install. Can it be self-hosted?

Thanks,

Interdocument xrefs are a variation on the xref syntax that provide an easy, output format agnostic way to link to another document converted from AsciiDoc. If a document is rendered on docgist, then the interdocument xref should link to a relative document that is also rendered on docgist.

For more information on interdocument xrefs, see http://asciidoctor.org/docs/user-manual/#inter-document-cross-references.

Apparently the Firebase project needs to be imported somewhere on Google Cloud otherwise it will be shut down mid-May.

This error happens when I try to create a new document/copy of GitHub Asciidoc file.

If an interactive checkbox is checked in the preview, then the item should also be checked in the source. This feature helps with collaborative editing. It's possible to use the AST to find the item in the source that was checked and modify the text.

When clicked the edit button

it gives following error

then the editor loads but left are is empty while the rendered content is available on the right.

This will be very cool.

See:
http://gist.asciidoctor.org/?https%3A%2F%2Fpad.riseup.net%2Fp%2Friseup-docgist-test%2Fexport%2Ftxt

Hey everyone! Was testing DocGist to render some random documents I had written on an etherpad instance. It looks like that the asciidoctor version of the footnotes syntax doesn't work on DocGist. Here's the data I tested with.

Input text:: https://notes.typo3.org/p/YPlWzvj6IP
Result:: https://gist.asciidoctor.org/?epsp-notes.typo3.org-YPlWzvj6IP#_footnote_2

Asciidoctor documentation:: https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/#section-footnotes

Asciidoc documentation:: http://asciidoc.org/userguide.html#X92

This would be useful for sharing documents with different settings without having to alter the document itself. This would also come in very handy in testing the rendering of for example the AsciiDoc User Guide.

Have a look at both repos and snippets and see what could be supported.

Maybe some other hosts as well, see:
https://git.wiki.kernel.org/index.php/GitHosting
https://en.wikipedia.org/wiki/Comparison_of_source_code_hosting_facilities

Author, version etc

Replace the navbar with something minimal, like an open-in-new-window link only.
(We might want the button to say it's a DocGist, that could be just enough.)
I think embedding AsciiDoc documents into other tools this way would be great.

Maybe also support resizing the iframe to fit the document. See:
https://github.com/davidjbradshaw/iframe-resizer

According to the homepage

Starting March 30, 2018, we will be turning down support for goo.gl URL shortener. From April 13, 2018 only existing users will be able to create short links on the goo.gl console. You will be able to view your analytics data and download your short link information in csv format for up to one year, until March 30, 2019, when we will discontinue goo.gl. Previously created links will continue to redirect to their intended destination. Please see this blog post for more details.

It is necessary to choose another URL shortener.

In theory, includes should be able to work in DocGist. First, set the safe option to 'server'. Then, set the base_dir option to the base URL of the file being rendered. Some content-origin stuff might need to be set to make this work...however docgist is pulling the original content, the include mechanism needs the same access.

Test page: http://gist.asciidoctor.org/?3adfc089d186c95bd51f

I have received reports of this error and similar when using Safari:

Error
Exception:
asciidoctor: FAILED: : Failed to parse source, undefined is not an object (evaluating 'a.$chr')

I have set up older versions of DocGist, but that doesn't seem to help.
Loading minimal documents usually works, but I haven't been able to track down the actual problem.
The front page of DocGist fails every time (it's a rather complex page).

As I don't have any OSX hardware, it's really hard for me to dig any deeper into this.

NOTE: If window.console doesn't exist when the page is loaded, it's replaced by a fake one that silently does nothing.

@mojavelinux Does the above error message point you in any direction?

Under the Attributes menu, attribute entries which act as booleans should be represented as a toggle button instead of multiple entries. This may either be a two-state toggle or a three-state toggle. We can use a glyph or icon to represent the state.

Ideally, the menu would stay open after a click, though it wouldn't be a showstopper if the first implementation required the menu to be opened each time.

Could you please test that everything is working fine with version 1.5.3-preview.2 ? If this is the case I will release a final version.

Thanks 😄

I try to render the example-manual.adoc page from the maven example repository with gist.asciidoctor.org.

Url of the file:

https://github.com/asciidoctor/asciidoctor-maven-examples/blob/master/asciidoc-to-html-example/src/docs/asciidoc/example-manual.adoc

Links:

• page on GitHub
• page rendered with gist.asciidoctor.org

In the Images section, the image is broken. It looks like this:

The src attribute of the img tag is wrong:

<h2 id="_images"><a class="anchor" href="#_images"></a>Images</h2>
<div class="sectionbody">
<div class="imageblock thumb">
<div class="content">
<img src="images/sunset.jpg" alt="sunset.jpg">
</div>
</div>
</div>
</div>

It should be:

<img src="https://raw.githubusercontent.com/asciidoctor/asciidoctor-maven-examples/master/asciidoc-to-html-example/src/docs/asciidoc/images/sunset.jpg" alt="sunset.jpg">

I think that an absolute image path in a document rendered from GitHub should refer to the root of the repository. Currently, it doesn't work.

You can see an example here: http://gist.asciidoctor.org/?github-powerman%2Fasciidoc-cheatsheet%2F%2FREADME.adoc (look for the screenshot)

This is definitely an edge case and I'm wondering if it should work. Really, a document shouldn't be relying on absolute paths because then it won't work when used locally (only on a web server). But I'm filing this issue for reference in case people come across the use case and are curious about it...regardless of what we decide to do.

In short, create a small build that updates DocGist to some Asciidoctor version.

Document which URLs are supported by DocGist, and how DocGist recognizes them.

Pastebins usually allow users to set garbage collection schedule when submitting a new pastebin.
I want predictability.