Skip to content
This repository has been archived by the owner on Jan 3, 2023. It is now read-only.

gitlab flavored preview? #408

Open
briochemc opened this issue Jun 20, 2018 · 3 comments
Open

gitlab flavored preview? #408

briochemc opened this issue Jun 20, 2018 · 3 comments

Comments

@briochemc
Copy link

Hey,

I was wondering if there are settings that would work to be able to preview gitlab-flavored markdown? (Note: gitlab and not github)

Cheers!

@lierdakil
Copy link
Collaborator

Hello! Thanks for your inquiry.

We have support for two parsers/renderers: markdown-it and Pandoc. The first one follows CommonMark spec (with a few optional extensions), while the second one... well, frankly, doesn't really follow anything, but is one of the more rich Markdown dialects out there.

So... No, we don't really do gfm (whatever "g" is here).

However, GitHub Markdown loosely follows CommonMark spec, so we kinda support it by the merit of following the same spec.

I don't know enough about GitLab Markdown to comment on it's relation to CommonMark, but I know they're planning to switch to CommonMark-compatible parser in the future (e.g. https://gitlab.com/gitlab-org/gitlab-ce/issues/43011)

For reference, GitLab uses redcarpet, which is based on sundown parser, which has node bindings, so while 100% compatibility would likely be impossible (can't run Ruby in Node), basic support could be relatively simple to add.

The caveat is redcarpet is actively maintained currently, while neither sundown (last commit 2012) nor it's node bindings (last commit 2013) are. So, in all likelihood, simply adding sundown parser would create more problems than solve.

All in all, I don't see much merit in trying to add support for redcarpet, considering GitLab plans to switch to something else, and that it's likely not going to be simple. Feel free to try to convince me otherwise, but bear in mind this is mostly a one-man operation at the moment. One chronically tired man operation. So there aren't many resources to spare.

@briochemc
Copy link
Author

Hey thanks or your reply!

Sorry to hear you're alone working on this... To be frank, I do not understand much of the things you said, so I don't think I can even help you at all.

Anyway, I did not mean for your to work more 😄, I was just hoping that some choice of settings would work for my problem. Specifically, I just want to write LaTeX

  • inline using $` some_inline_latex `$
  • and centered using
```math
some_centered_latex
```

which is the Gitlab's way to write LaTeX. This would allow me to work on the ReadMe's offline and fast, and it would look as expected when I push it to the online remote on Gitlab. I tried to play with the LaTeX separators in the settings but I failed to achieve this simple result.. Maybe you know how to do just that?

@lierdakil
Copy link
Collaborator

lierdakil commented Jun 22, 2018

Not with the markdown-it parser, I don't think, considering math is inline-level, and code blocks are block-level, so code block will invariably take precedence. I mean I probably could add/change math parser to work with this syntax, but it will take a while -- as I said, little resources to spare, and writing markdown-it parsers is not especially easy.

There is another option though. You could try using Pandoc with a custom filter that would apply a few straightforward transformations to the parsed document, something along these lines: https://gist.github.com/lierdakil/00d8143465a488e0b854a3b4bf355cf6
(if on *nix, you can make this executable, and add --filter=/path/to/gitlab-math.py to 'Pandoc Settings' → 'Commandline Arguments' in the package settings; not really sure how that would work on Windows though, since, you know, can't make text file executable, but I'm sure there's some way). You can run it by passing --lua-filter=/path/to/gitlab-math.lua to Pandoc. It won't be 100% compatible, but probably close enough to use.

P.S. Relevant Pandoc issue: jgm/pandoc#3977

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

2 participants