Markdown tables and footnotes are pretty useful, so it would be great if I could use them with gutenberg.

The pulldown-cmark crate already provides optional support for markdown tables and footnotes. It can be easily enabled by passing OPTION_ENABLE_TABLES | OPTION_ENABLE_FOOTNOTES to Parser::new_ext.

While editing a page.
The webserver doesn't seem to send the livereload command on every change for some reason.
Gut feeling is that I tried to make the partial hot reload too smart and I missed some case.

Probably need to add some verbosity level in the app to allow debugging this kind of stuff

Instead of a panic

Currently one has to restart gutenberg serve after one changed something in the config.toml (e.g. the highlight_theme).

Once 0.1 is reached

• AUR: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ripgrep for ripgrep for example

I think brew is used on mac? Any mac user around?

I still can't get the next/previous fields to work. All of the following lead to zero output:

{{ page.next }}
{{ page.next_in_section }}
{{ page.prev }}
{{ page.prev_in_section }}

The pages all have a date field in their front matter, e.g. date = "2015-08-25". Is there something I'm doing wrong?

The last filter of the tera template engine returns the last element of an array. This leads to counterintuitive results when used on an array of pages, since pages|last returns the last page in the pages array, which is actually the first/earliest page (i.e. the page with the lowest ordering). So if one follows the next pointers of a page, one reaches pages|first instead of the expected pages|last.

I want to order my posts manually, so the default Page::previous/next fields don't work for me (they order by date). Instead, I want to specify the next/previous relations explicitly.

Currently, I try to use the front matter for this, e.g. extra = {prev = "a.md", next = "c.md"}. In the template, I then want to automatically create prev/next links with the page titles:

{% if page.extra.prev %}
    {% prev = get_page(page.extra.prev) %}
    <a class="prev" href="{{ prev.path }}">&laquo; {{ prev.title }}</a>
{% endif %}
{% if page.extra.next %}
     {% next = get_page(page.extra.next) %}
    <a class="next" href="{{ next.path }}">{{ next.title }} &raquo;</a>
{% endif %}

So I need some working replacement for my {% prev = get_page(page.extra.prev) %} strawman syntax. Is this possible somehow or is there an alternative way to achieve manual page ordering?

When I try to call a shortcode, the following error occurs:

Failed to build the site
Error: Error parsing templates
Reason: 
* Failed to parse '"/home/…/templates/index.html"'
-- Invalid Tera syntax at line 32, column 8

Line 32 of index.html looks like this:

{{ gist(url="https://gist.github.com/Keats/32d26f699dcc13ebd41b") }}

So releases can be done on github

See trishume/syntect#20 for the syntect issue

Either do a pool in gutenberg or in Syntect as mentioned in the issue above. Doing it in syntect would be nicer as any syntect users will get it instead of duplicating the work in every syntect users but I'm not against having it only in gutenberg.
This currently prevents the markdown rendering from being made parallel but I'm not entirely sure what's the best way to make it work.

Opening this issue in case someone wants to work on that, that would be super helpful!
The code for SyntaxSet should be in rendering/highlighting.rs

Sections and some content don't have dates but we will want to order them somehow. Having weight in the front-matter might do the trick (lighter -> top, heavier -> bottom).

Sections should be able to define how they want to be sorted though. In the _index.md frontmatter, we can add a sort_by key that takes either "date" or "weight".
An alternative is to add a sort_by filter that can handle that from the template itself.

Probably going to wait for some feedback before starting this.

But no. Something like content_index.md is not a section index. The code need to check that the file component is an exact match.

• Markdown
• base64

More?

doesn't seem to work right now.

Or an equivalent. It could hook into the markdown renderer and render a template when encountering one

Currently fails with oniguruma https://ci.appveyor.com/project/Keats/gutenberg/build/1.0.18/job/08aksliyivr1d7lp

If anyone looking at that issue is on Windows, I'd appreciate some help as pushing and waiting for CI to fail is not a good feedback loop.

that I found out while working on a site for Tera:

• Index page is not rendered if there is no _index.md
• Don't count index section in the line shown in the console, it's a bit misleading as it can not exist physically
• Let a section have a body (could solve syntax highlighting on index page at the same time)
• Get syntax highlighting on index page somehow, maybe not needed as it can be done with a js lib but would be nice
• Be able to render a single section when content changed: can check whether it's the body or front matter and can render only the page itself if only the body changed
• Add jinja2 syntax
• Fix the annoying live reload that keeps breaking (#10)

Tracked in #65

One PageFrontMatter and one SectionFrontMatter.
Not sure it is worth it though: not being able to refer a specific variant means lots of matching each time though

Pagination

A few cases to consider:

• simple blog, with/without pagination
• site: typically no pagination
• site + blog: pagination on some bits only potentially (the blog)
• random site with pagination on some sections (like a knowledge base for example)

Default is no pagination at all.

Then people can add paginations for whatever section they want. We need 3 elements for each pagination: (section_name, num_per_page, path_name).

Example of mixed site+blog content folder:

content
 - about.md
 - pricing.md
 - blog
   - article1.md

• section_name: for example you can use blog and it will generate pagination for all the pages in blog. The only way I can see it working for the basic blog is to have a magic name, like base that will work on the first level in the content folder
• num_per_page: how many pages on each page of the pagination
• path_name: what goes in the url for the pagination. For example, if I use "page", the second page will be mysite.com/page/2

We can potentially have several type of contents needing pagination, but since I'm not using pagination at all myself, one basic level should be fine to start with.

EDIT: outdated, see below

Combined with using several config files, that allows doing a/b testing easily without having to duplicate the content around.
That raises the problem of a different static folder too. Maybe make both of them configurable?

It will be a good exercise to find bugs and missing features.

I'm using the sort_by = order setting to order the posts of two sections manually. The problem is that the previous/next fields of a page point to pages of other sections too. For example, if two pages in different sections both have ordering 1, they are currently treated as immediate successors.

Can you add Sublime-GenericConfig (for dotfiles) and VimL (for vimscripts) ?

Thanks!

One of my headings is ## Hello World!! in markdown. The generated html is:

<h2 id="hello-world"><a class="anchor" href="#hello-world" aria-label="Anchor link for: hello-world">
    🔗
</a>
Hello Worldid=""><a class="anchor" href="#" aria-label="Anchor link for: ">
    🔗
</a>
!id="-1"><a class="anchor" href="#-1" aria-label="Anchor link for: -1">
    🔗
</a>
!</h2>

I want to use my own template for the rss.xml. Is this possible somehow?

The syntect crate ships a default set of syntaxes that allows to highlight most common languages, but it does not include syntax files for more exotic languages such as nasm. It is possible to load additional syntaxes for such languages through the SyntaxSet::load_syntaxes method. It would be great if gutenberg could support this somehow, for example by adding support for all needed languages in gutenberg itself or by adding a command line argument.

Lots of repetition between config and front matter

So we can make custom shortcodes like in http://diesel.rs/ homepage code blocks with a title

Hi!
I'm creating a documentation site for my Rust project. I'm stuck at implementing an index side bar with all section&page titles. My content looks like this:

├── doc
│   ├── _index.md
│   ├── intro.md
│   ├── configuration
│   │   ├── advanced.md
│   │   ├── basic.md
│   │   └── _index.md
│   └── setup
│       └── _index.md
└── _index.md

With a global get_section function I could iterate through all subsections of doc and their pages. As an alternative solution, a page could return the section it belongs to. Then I could start with the intro.md page.

On the current section/page I also want to display links to the previous and next section/page. See https://rocket.rs/guide/ as an example. This should be possible with a get_section function, but maybe an additional helper would make sense for that.

Thanks for your work - it looks very promising to me!

currently limited to 15

Takes the Site::permalinks and can build urls like in the markdown content from a path such as posts/something.md

The function need to be re-added to Tera everytime a page is updated on the serve command though so it doesn't stop working for newly added files

See how other tools like Hugo handle it.

Would be nice to have each section's posts in the context of the index.html template to be able to produce summaries for them.

• serve command with basic live reload
• Ordering of posts by date
• Word count + estimated read time
• Sitemap generation
• Add summary via <!-- more --> to do the equivalent of https://github.com/getpelican/pelican-plugins/tree/master/summary
• Generate tags and categories page (allow disabling that since sites don't need that)
• RSS feed generation
• Syntax highlighting
• Split it into lib and crate
• Only livereload the file for css/js/imgs
• Copy asset files from content directory
• Find a way to test site parsing and building
• Generate section pages (see #465 on hugo for a nice example of nested section use)
• Add tags & categories pages to the sitemap

Differentiating sites and blogs (maybe?)

That's the main two use cases and things like date or rss feed don't really make sense on a site.
Could be an option in config.toml site_kind: site | blog that automatically pre-configures gutenberg. The init command would ask which kind and generate the appropriate config.toml file

I'm currently leaving TODOs all over the place so the rebuild_after_content_change will take as little time as possible.
Do it once the new way of handling index is in

• Fill prev/next on pages
• Pagination (#7)
• Prettier command line output
• Choose a different config file (#8)
• Choose code highlighting theme
• Put it on AUR (https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packages/ripgrep for ripgrep for example)

Great Project !

Is ist currently possible to do something like this?
https://github.com/stephenhay/rdw-code-examples/blob/master/ch10-presentation02-browser/mockup/macros/nav.jinja

Since a picture is worth a thousand words:

Somehow, gutenberg serve finds the edit unacceptable and delete all the generated html for that article.

Thanks for this great project!

Is there a way to do internal links similar to hugo's ref and relref?

When you have config.staging.toml etc

That's the only reason I still need npm/yarn to build a theme

Unresolved questions:

• no postcss support?

I want to use a combination of sections and categories to create a custom taxonomy with different types of pages, each one using it's own layout/template.

Issue

When adding the following markdown code:

# [](#configure-solarized-with)Configure Solarized with ...

## [](#xresources)Xresources

> **Xresources** is a user-level configuration dotfile, used to set X resources
> used by X client applications.
....

I get the following code:

Expected behavior

There should be an empty link created before the title, not visible on the page.

Use colors and improve messaging

The Page struct contains lots of useful fields such as summary or previous/next that are not available in templates because they're not serialized. Is there a reason for this or is this just an oversight?

Also, it would probably make sense to change the type of the summary field to Option<String> instead of defaulting to an empty summary.

Hello.
It would be nice to support other input formats, like asciidoctor.
Hugo supports these formats.
Thanks.

I'm not quite sure what the description field in the front matter is needed for, so I use description = "" everywhere. Maybe we can make that field optional (and default to "")?

Focus on features first but then work to make it fast

• Add benchmarks (with test site and generated site with hundreds of pages)
• Parallelize whenever possible
• Only rebuild templates that changed
• Only rebuild pages that changed
• Only copy static files that changed
• Cache sublime syntax files
• Remove clone() as much as possible
• Don't write files, have some kind of virtual filesystem instead in serve
• Use lazy_static! for rss/sitemap templates
• Cache stuff on the filesystem maybe? Hugo does cache some pygments related things in /tmp/hugo_cache