Re: [O] Add-on: Github Flavored Markdown exporter
2014-04-11 12:29 GMT+02:00 Bastien b...@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: [O] Add-on: Github Flavored Markdown exporter
Hi Nicolas, Nicolas Girard girard.nico...@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: [O] Add-on: Github Flavored Markdown exporter
2014-06-09 18:45 GMT+02:00 Bastien b...@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
Re: [O] Add-on: Github Flavored Markdown exporter
Hi Lars, Lars Tveito larst...@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: [O] Add-on: Github Flavored Markdown exporter
Bastien writes: Hi Lars, Lars Tveito larst...@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: [O] Add-on: Github Flavored Markdown exporter
Lars Tveito larst...@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: [O] Add-on: Github Flavored Markdown exporter
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: [O] Add-on: Github Flavored Markdown exporter
Thorsten Jolitz tjol...@gmail.com writes: Lars Tveito larst...@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: [O] Add-on: Github Flavored Markdown exporter
Hi, thanks for checking it out! Thorsten Jolitz writes: Thorsten Jolitz tjol...@gmail.com writes: Lars Tveito larst...@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: [O] Add-on: Github Flavored Markdown exporter
Dumb question, from where should we pull down your excellent exporter Lars? Grant Rettke | AAAS, ACM, AMA, COG, FSF, IEEE, Sigma Xi gret...@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 larst...@student.matnat.uio.no wrote: Hi, thanks for checking it out! Thorsten Jolitz writes: Thorsten Jolitz tjol...@gmail.com writes: Lars Tveito larst...@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: [O] Add-on: Github Flavored Markdown exporter
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: [O] Add-on: Github Flavored Markdown exporter
Grant Rettke g...@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 larst...@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
[O] Add-on: Github Flavored Markdown exporter
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 ox-gfm.el Description: application/emacs-lisp
Re: [O] Add-on: Github Flavored Markdown exporter
Lars Tveito larst...@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:
