Add-on: Github Flavored Markdown exporter

Add-on: Github Flavored Markdown exporter

[Lars Tveito]

[-- Attachment #1: Type: text/plain, Size: 490 bytes --]

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.

I think this could be useful because Org is a great tool for writing
README's. Org is supported by Github, but it currently does not support
syntax highlighting and table of contents (and has some other minor
quirks).

Should I contribute this to the /lisp/contrib/?

Best regards,
- Lars


[-- Attachment #2: ox-gfm.el --]
[-- Type: application/emacs-lisp, Size: 6600 bytes --]

Re: Add-on: Github Flavored Markdown exporter

[Thorsten Jolitz]

Lars Tveito <larstvei@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.
>
> I think this could be useful because Org is a great tool for writing
> README's. Org is supported by Github, but it currently does not support
> syntax highlighting and table of contents (and has some other minor
> quirks).
>
> Should I contribute this to the /lisp/contrib/?
>
> Best regards,
> - Lars

This is nice, because I like to reuse the comment-sections of my elisp
libraries as README files on github, but neither the raw org nor the
markdown export looked so nice when I tried, so I used the ascii
exporter. 

When I structure my .el files with outshine headers, with the whole
comment section as one tree, I can simply use M-x outorg-edit-as-outorg
on that entry and then export from the outorg-edit-buffer.

I tried your library with outorg.el itself. Here is the comment section
after converting it to outorg (the org-exporter does not like the
reboxes, so I had to put manually , in front of them - is that a bug?
Same problem with ascii-export):
  
#######################################################################

* outorg.el --- Org-style comment editing

Author: Thorsten Jolitz <tjolitz AT gmail DOT com>
Version: 1.0
URL: https://github.com/tj64/outorg

** MetaData
  :PROPERTIES:
  :copyright: Thorsten Jolitz
  :copyright-years: 2013
  :version:  1.0
  :licence:  GPL 2 or later (free software)
  :licence-url: http://www.gnu.org/licenses/
  :part-of-emacs: no
  :author: Thorsten Jolitz
  :author_email: tjolitz AT gmail DOT com
  :inspiration:  org-src
  :keywords: emacs org-mode comment-editing
  :END:

** Commentary
*** About outorg

[NOTE: For the sake of adding this library to MELPA, headlines had to be
converted back from 'Org-mode style' to 'oldschool', and a few extra lines
of required information had to be added on top of the MetaData section -
just to comply with the required file formatting. All outshine, outorg and
navi-mode functionality still works with this file. See my
[[https://github.com/tj64/iorg][iOrg]] repository for examples of
Emacs-Lisp and PicoLisp files structured 'the outshine way'.]

`outorg' is like "reverse Org-Babel": editing of comment-sections from source
code files in temporary Org-mode buffers instead of editing of Org-mode
source-blocks in temporary source-code buffers.

It should be used together with `outline-minor-mode' and `outshine.el'.
Keep in mind, that `outorg' only works with outshine-style headlines like
those produced by calling `comment-region' on Org-mode style headlines in a
source-code buffer. Take this file as an example for suitable outline
headlines in an Emacs Lisp buffer. In other major-modes, the
`comment-start' character ';' of Emacs Lisp would be replaced by that of
the respective major-mode, e.g. '#' in PicoLisp mode or '%' in LaTeX mode.

`outorgs' main command is accessible via two different keybindings
1. with outline-minor-mode-prefix 'C-c'

, ,---------------------------
, | C-c ' (outorg-edit-as-org)
, `---------------------------

 2. with outline-minor-mode-prefix 'M-#'

, ,---------------------------
, | M-# M-# (outorg-edit-as-org)
, `---------------------------

used in source-code buffers where `outline-minor-mode' is activated with
`outshine' extensions. The Org-mode edit-buffer popped up by this command
has `outorg-edit-minor-mode' activated, a minor-mode with only 2 commands:

,,----------------------------------------
,| M-# (outorg-copy-edits-and-exit)
,| C-x C-s (outorg-save-edits-to-tmp-file)
,`----------------------------------------

If you want to insert Org-mode source-code or example blocks in
comment-sections, simply outcomment them in the outorg-edit buffer before
calling `outorg-copy-edits-and-exit'.

*** Installation

Insert

;; #+begin_src emacs-lisp
;;  (require 'outorg)
;; #+end_src

in your .emacs.

*** Bugs and Shortcomings

`outorg' is line-based, it only works with 'one-line' comments, i.e. with
comment-sections like those produced by `comment-region' (a command that
comments or uncomments each line in the region). Those special multi-line
comments found in many programming languages are not recognized and lead to
undefined behaviour.

*** Emacs Version

`outorg.el' works with [GNU Emacs 24.2.1 (x86_64-unknown-linux-gnu, GTK+
Version 3.6.4) of 2013-01-20 on eric]. No attempts of testing with older
versions or other types of Emacs have been made (yet).


** ChangeLog

| date            | author(s)       | version |
|-----------------+-----------------+---------|
| <2013-05-03 Fr> | Thorsten Jolitz |     1.0 |
| <2013-02-11 Mo> | Thorsten Jolitz |     0.9 |


##########################################################################


And here is the "*Org GFM Export*" buffer after exporting with your library:    


###########################################################################

- [outorg.el &#x2014; Org-style comment editing](#outorg.el-&#x2014;-org-style-comment-editing)
  - [MetaData](#metadata)
  - [Commentary](#commentary)
    - [About outorg](#about-outorg)
    - [Installation](#installation)
    - [Bugs and Shortcomings](#bugs-and-shortcomings)
    - [Emacs Version](#emacs-version)
  - [ChangeLog](#changelog)

# outorg.el &#x2014; Org-style comment editing

Author: Thorsten Jolitz <tjolitz AT gmail DOT com>
Version: 1.0
URL: <https://github.com/tj64/outorg>

## MetaData

## Commentary

### About outorg

[NOTE: For the sake of adding this library to MELPA, headlines had to be
converted back from 'Org-mode style' to 'oldschool', and a few extra lines
of required information had to be added on top of the MetaData section -
just to comply with the required file formatting. All outshine, outorg and
navi-mode functionality still works with this file. See my
[iOrg](https://github.com/tj64/iorg) repository for examples of
Emacs-Lisp and PicoLisp files structured 'the outshine way'.]

\`outorg' is like "reverse Org-Babel": editing of comment-sections from source
code files in temporary Org-mode buffers instead of editing of Org-mode
source-blocks in temporary source-code buffers.

It should be used together with \`outline-minor-mode' and \`outshine.el'.
Keep in mind, that \`outorg' only works with outshine-style headlines like
those produced by calling \`comment-region' on Org-mode style headlines in a
source-code buffer. Take this file as an example for suitable outline
headlines in an Emacs Lisp buffer. In other major-modes, the
\`comment-start' character ';' of Emacs Lisp would be replaced by that of
the respective major-mode, e.g. '#' in PicoLisp mode or '%' in LaTeX mode.

\`outorgs' main command is accessible via two different keybindings

1.  with outline-minor-mode-prefix 'C-c'

, ,&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;
, | C-c ' (outorg-edit-as-org)
, \`&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;

1.  with outline-minor-mode-prefix 'M-#'

, ,&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;
, | M-# M-# (outorg-edit-as-org)
, \`&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;

used in source-code buffers where \`outline-minor-mode' is activated with
\`outshine' extensions. The Org-mode edit-buffer popped up by this command
has \`outorg-edit-minor-mode' activated, a minor-mode with only 2 commands:

,,-&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;
,| M-# (outorg-copy-edits-and-exit)
,| C-x C-s (outorg-save-edits-to-tmp-file)
,\`-&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;&#x2014;

If you want to insert Org-mode source-code or example blocks in
comment-sections, simply outcomment them in the outorg-edit buffer before
calling \`outorg-copy-edits-and-exit'.

### Installation

Insert

;; #+begin<sub>src</sub> emacs-lisp
;;  (require 'outorg)
;; #+end<sub>src</sub>

in your .emacs.

### Bugs and Shortcomings

\`outorg' is line-based, it only works with 'one-line' comments, i.e. with
comment-sections like those produced by \`comment-region' (a command that
comments or uncomments each line in the region). Those special multi-line
comments found in many programming languages are not recognized and lead to
undefined behaviour.

### Emacs Version

\`outorg.el' works with [GNU Emacs 24.2.1 (x86<sub>64</sub>-unknown-linux-gnu, GTK+
Version 3.6.4) of 2013-01-20 on eric]. No attempts of testing with older
versions or other types of Emacs have been made (yet).

## ChangeLog

<table border="2" cellspacing="0" cellpadding="6" rules="groups" frame="hsides">


<colgroup>
<col  class="left" />

<col  class="left" />

<col  class="right" />
</colgroup>
<thead>
<tr>
<th scope="col" class="left">date</th>
<th scope="col" class="left">author(s)</th>
<th scope="col" class="right">version</th>
</tr>
</thead>

<tbody>
<tr>
<td class="left"><span class="timestamp-wrapper"><span class="timestamp">&lt;2013-05-03 Fr&gt;</span></span></td>
<td class="left">Thorsten Jolitz</td>
<td class="right">1.0</td>
</tr>


<tr>
<td class="left"><span class="timestamp-wrapper"><span class="timestamp">&lt;2013-02-11 Mo&gt;</span></span></td>
<td class="left">Thorsten Jolitz</td>
<td class="right">0.9</td>
</tr>
</tbody>
</table>

##############################################################################

Is that the intended output? I did not try it on github ...

-- 
cheers,
Thorsten

Re: Add-on: Github Flavored Markdown exporter

[Thorsten Jolitz]

Thorsten Jolitz <tjolitz@gmail.com> writes:

> Lars Tveito <larstvei@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.

Your library works really good, thanks. I would recommend adding it to
/contrib. I used it to create new README.md files for all three
libraries navi-mode.el, outorg.el and outshine.el, you can find the
repos on github.com/tj64 if you want to take a look.

I like the idea very much to write this documentation stuff once in one
place and then reuse it in all other places. Therefore when I write a
source file, I use outorg to write a more or less sophisticated comment
header for that file. This is then automatically converted back to a
programming language comment section, but I can always convert it back
to Org-mode. From the outorg-edit-buffer, I can then export it to html,
latex, ascii and now to markdown-github-flavor too, whats nice.

I use a little trick to do this:
I narrow the buffer to the first 1st level headline, and then use 

,--------------
| C-1 M-# M-#
| C-u 1 M-# M-#
`--------------

to temporarily insert the default export template, or

,--------------
| C-3 M-# M-#
| C-u 3 M-# M-#
`--------------

to temporarily insert a custom export template from a file.

A few questions and remarks:

- I get the best results with just using example blocks - is it supposed
  to work with source-blocks and other blocks too?

- Just like the Org exporter in general, it does not know how to deal
  with boxes made with rebox2.el, so I replaced them with example
  blocks.

- What about numbered lists with longer text/blocks as item content - is
  the item numbering supposed to work?

-- 
cheers,
Thorsten

Re: Add-on: Github Flavored Markdown exporter

[Lars Tveito]

Hi, thanks for checking it out!

Thorsten Jolitz writes:

> Thorsten Jolitz <tjolitz@gmail.com> writes:
>
>> Lars Tveito <larstvei@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.
>
> Your library works really good, thanks. I would recommend adding it to
> /contrib. I used it to create new README.md files for all three
> libraries navi-mode.el, outorg.el and outshine.el, you can find the
> repos on github.com/tj64 if you want to take a look.
>

I try adding it soon. Checked out your README'S, looks good!

> I like the idea very much to write this documentation stuff once in one
> place and then reuse it in all other places. Therefore when I write a
> source file, I use outorg to write a more or less sophisticated comment
> header for that file. This is then automatically converted back to a
> programming language comment section, but I can always convert it back
> to Org-mode. From the outorg-edit-buffer, I can then export it to html,
> latex, ascii and now to markdown-github-flavor too, whats nice.
>
> I use a little trick to do this:
> I narrow the buffer to the first 1st level headline, and then use 
>
> ,--------------
> | C-1 M-# M-#
> | C-u 1 M-# M-#
> `--------------
>
> to temporarily insert the default export template, or
>
> ,--------------
> | C-3 M-# M-#
> | C-u 3 M-# M-#
> `--------------
>
> to temporarily insert a custom export template from a file.
>
> A few questions and remarks:
>
> - I get the best results with just using example blocks - is it supposed
>   to work with source-blocks and other blocks too?
>

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)
```

Which provides syntax highlighting in Github Flavored Markdown.

> - Just like the Org exporter in general, it does not know how to deal
>   with boxes made with rebox2.el, so I replaced them with example
>   blocks.
>

I am not familiar with rebox2.el. This back-end inherits most
functionality from the markdown (vanilla) exporter, which again inherits
from the html exporter. Since rebox2.el doesn't play nice with any of
those it will cause problems with the github flavored as well.

If you'd like the boxes created with rebox2.el to appear in the exported
version you could possibly wrap it inside an example-block.

> - What about numbered lists with longer text/blocks as item content - is
>   the item numbering supposed to work?

I hadn't tested this, but found an old org-file with notes packed with
different lists. I generated it, and most of it looks good:
https://gist.github.com/anonymous/694b7b5f53dd21850bcd (by the way, the
content is rubbish, and in Norwegian).

The only problems are with latex-code mixed in the document and sloppy
work from the original org file.

- Lars

Re: Add-on: Github Flavored Markdown exporter

[Grant Rettke]

Dumb question, from where should we pull down your excellent exporter Lars?
Grant Rettke | AAAS, ACM, AMA, COG, FSF, IEEE, Sigma Xi
grettke@acm.org | http://www.wisdomandwonder.com/
“Wisdom begins in wonder.” --Socrates
((λ (x) (x x)) (λ (x) (x x)))
“Life has become immeasurably better since I have been forced to stop
taking it seriously.” --Thompson


On Tue, Apr 8, 2014 at 4:39 PM, Lars Tveito
<larstvei@student.matnat.uio.no> wrote:
> Hi, thanks for checking it out!
>
> Thorsten Jolitz writes:
>
>> Thorsten Jolitz <tjolitz@gmail.com> writes:
>>
>>> Lars Tveito <larstvei@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.
>>
>> Your library works really good, thanks. I would recommend adding it to
>> /contrib. I used it to create new README.md files for all three
>> libraries navi-mode.el, outorg.el and outshine.el, you can find the
>> repos on github.com/tj64 if you want to take a look.
>>
>
> I try adding it soon. Checked out your README'S, looks good!
>
>> I like the idea very much to write this documentation stuff once in one
>> place and then reuse it in all other places. Therefore when I write a
>> source file, I use outorg to write a more or less sophisticated comment
>> header for that file. This is then automatically converted back to a
>> programming language comment section, but I can always convert it back
>> to Org-mode. From the outorg-edit-buffer, I can then export it to html,
>> latex, ascii and now to markdown-github-flavor too, whats nice.
>>
>> I use a little trick to do this:
>> I narrow the buffer to the first 1st level headline, and then use
>>
>> ,--------------
>> | C-1 M-# M-#
>> | C-u 1 M-# M-#
>> `--------------
>>
>> to temporarily insert the default export template, or
>>
>> ,--------------
>> | C-3 M-# M-#
>> | C-u 3 M-# M-#
>> `--------------
>>
>> to temporarily insert a custom export template from a file.
>>
>> A few questions and remarks:
>>
>> - I get the best results with just using example blocks - is it supposed
>>   to work with source-blocks and other blocks too?
>>
>
> 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)
> ```
>
> Which provides syntax highlighting in Github Flavored Markdown.
>
>> - Just like the Org exporter in general, it does not know how to deal
>>   with boxes made with rebox2.el, so I replaced them with example
>>   blocks.
>>
>
> I am not familiar with rebox2.el. This back-end inherits most
> functionality from the markdown (vanilla) exporter, which again inherits
> from the html exporter. Since rebox2.el doesn't play nice with any of
> those it will cause problems with the github flavored as well.
>
> If you'd like the boxes created with rebox2.el to appear in the exported
> version you could possibly wrap it inside an example-block.
>
>> - What about numbered lists with longer text/blocks as item content - is
>>   the item numbering supposed to work?
>
> I hadn't tested this, but found an old org-file with notes packed with
> different lists. I generated it, and most of it looks good:
> https://gist.github.com/anonymous/694b7b5f53dd21850bcd (by the way, the
> content is rubbish, and in Norwegian).
>
> The only problems are with latex-code mixed in the document and sloppy
> work from the original org file.
>
> - Lars
>

Re: Add-on: Github Flavored Markdown exporter

[Nick Dokos]

Grant Rettke <gcr@wisdomandwonder.com> writes:

> Dumb question, from where should we pull down your excellent exporter Lars?

It was attached to the initial email that Lars sent to the list. If you
don't have that, you should be able to get it from

   http://thread.gmane.org/gmane.emacs.orgmode/84702

>>>> Lars Tveito <larstvei@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.
>>>

-- 
Nick

Re: Add-on: Github Flavored Markdown exporter

[Charles Berry]

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

Re: Add-on: Github Flavored Markdown exporter

[Lars Tveito]

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

Re: Add-on: Github Flavored Markdown exporter

[Thorsten Jolitz]

Lars Tveito <larstvei@student.matnat.uio.no> writes:

> Hi, thanks for checking it out!
> 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)
> ```
>
> Which provides syntax highlighting in Github Flavored Markdown.

I see, its a feature not a bug ;)

To me it looked as if the exporter had failed on this, but as an Org
user I never digged very deep in (Github Flavored) Markdown syntax.

>> - Just like the Org exporter in general, it does not know how to deal
>>   with boxes made with rebox2.el, so I replaced them with example
>>   blocks.
>>
>
> I am not familiar with rebox2.el. This back-end inherits most
> functionality from the markdown (vanilla) exporter, which again inherits
> from the html exporter. Since rebox2.el doesn't play nice with any of
> those it will cause problems with the github flavored as well.
>
> If you'd like the boxes created with rebox2.el to appear in the exported
> version you could possibly wrap it inside an example-block.

I think this was basically fixed by Nicolas yesterday, at least when I
tried with 'ascii backend the results were quite nice.

>> - What about numbered lists with longer text/blocks as item content - is
>>   the item numbering supposed to work?
>
> I hadn't tested this, but found an old org-file with notes packed with
> different lists. I generated it, and most of it looks good:
> https://gist.github.com/anonymous/694b7b5f53dd21850bcd (by the way, the
> content is rubbish, and in Norwegian).
>
> The only problems are with latex-code mixed in the document and sloppy
> work from the original org file.

I will do some further experiments with this, at first I thought it does
not work, but maybe its just me not complying with Org syntax demands
(and this would most likely not a specific problem of you exporter
neither). 

-- 
cheers,
Thorsten

Re: Add-on: Github Flavored Markdown exporter

[Bastien]

Hi Lars,

Lars Tveito <larstvei@student.matnat.uio.no> writes:

> Should I contribute this to the /lisp/contrib/?

I added your file to /contrib/lisp in the master branch,
thanks a lot!

I updated the copyright section of the file to put you
as the author, instead of the FSF.

Best,

-- 
 Bastien

Re: Add-on: Github Flavored Markdown exporter

[Lars Tveito]

Bastien writes:

> Hi Lars,
>
> Lars Tveito <larstvei@student.matnat.uio.no> writes:
>
>> Should I contribute this to the /lisp/contrib/?
>
> I added your file to /contrib/lisp in the master branch,
> thanks a lot!
>
> I updated the copyright section of the file to put you
> as the author, instead of the FSF.
>
> Best,

Great, thanks!

- Lars

Re: Add-on: Github Flavored Markdown exporter

[Nicolas Girard]

2014-04-11 12:29 GMT+02:00 Bastien <bzg@gnu.org>:
> Hi Lars,
>
>
> I added your file to /contrib/lisp in the master branch,
> thanks a lot!
>
> I updated the copyright section of the file to put you
> as the author, instead of the FSF.
>

Hi, and thanks to Lars for this nice contribution !

=ox-gfm.el= didn't seem to make its way to the org+contrib package
from Org ELPA repo. Could anyone add it ?

Thanks in advance,
cheers,

Nicolas

Re: Add-on: Github Flavored Markdown exporter

[Bastien]

Hi Nicolas,

Nicolas Girard <girard.nicolas@gmail.com> writes:

> =ox-gfm.el= didn't seem to make its way to the org+contrib package
> from Org ELPA repo. Could anyone add it ?

That's because ELPA packages are made from the maint branch of Org's
repository.

-- 
 Bastien

Re: Add-on: Github Flavored Markdown exporter

[Nicolas Girard]

2014-06-09 18:45 GMT+02:00 Bastien <bzg@altern.org>:
>
> That's because ELPA packages are made from the maint branch of Org's
> repository.
>


Hi Bastien,

ooh, I see... nevermind, thanks for your reply !

Nicolas