Re: Add-on: Github Flavored Markdown exporter

[Lars Tveito <larstvei@student.matnat.uio.no>]

Charles Berry writes:

> Lars Tveito <larstvei <at> student.matnat.uio.no> writes:
>
>> 
>> Hi, thanks for checking it out!
>> 
>> Thorsten Jolitz writes:
>> 
>> > Thorsten Jolitz <tjolitz <at> gmail.com> writes:
>> >
>> >> Lars Tveito <larstvei <at> student.matnat.uio.no> writes:
>> >>
>> >>> Hi!
>> >>>
>> >>> I have written an exporter for Github Flavored Markdown, which is a
>> >>> derived back-end from the Markdown (vanilla) exporter. It adds
>> >>> Github-style src-blocks, strike-through and table of contents.
> [snip]
>
> Nice!
>
>> 
>> Getting it to work with source-blocks was the feature I missed the most
>> from the vanilla markdown exporter. If you specify a language in the
>> source-block it will be added to the exported version as well; a problem
>> occurs if you specify a language not supported by Github. Emacs lisp is
>> an example of this, so there is a alist `org-gfm-lang' which by default
>> has the value:
>> 
>>     (("emacs-lisp" . "lisp") ("elisp" . "lisp"))
>> 
>> So a source block like this:
>> 
>> #+begin_src emacs-lisp
>>   (defun foo ()
>>     'foo)
>> #+end_src
>> 
>> exports to this:
>> 
>> ```lisp
>> (defun foo ()
>>   'foo)
>> ```
>
> In 
>
> https://github.com/github/linguist/blob/master/lib/linguist/languages.yml
>
> I see this:
>
> ,----
> | Emacs Lisp:
> |   type: programming
> |   lexer: Scheme
> |   color: "#c065db"
> |   aliases:
> |   - elisp
> |   - emacs
> |   primary_extension: .el
> |   filenames:
> |   - .emacs
> |   extensions:
> |   - .emacs
> `----
>
>
> so doesn't '#+BEGIN_SRC elisp' just work? 
>
> And shouldn't '(("emacs-lisp" . "elisp")) be the value of `org-gfm-lang'?
>
> HTH,
>
> Chuck

I have visited that file, and found this as well, but it does not seem
to work. I double checked this now with these tests:
https://gist.github.com/larstvei/8e06967dd099e0bd2c4c

If elisp was a language recognized in Markdown (github flavored), then
you'd be right about the value of `org-gfm-lang'.

Now it serves as a workaround to be able to work with languages that Org
deals with just fine, but does not export nice. If there is a language
with similar syntax, one can tell the gfm-exporter to use that language
instead.

I am not very fond of this workaround, but I haven't found a better
solution yet. Suggestions are very welcome!

- Lars