Re: [O] Agenda items refer to the wrong headline
getting out of sync is possible even with non-buggy code. i wonder if it would make sense to do a quick and dirty comparison of the headline to error if it is different? feel free to disregard if this is not a good idea.
Re: [O] Agenda items refer to the wrong headline
Fletcher Charest writes: > Nick, you say you could not reproduce the bug using version > 8.2.5h-667-g971dc4, but you did with version 8.2.5h-888-g798bb8d. Just > out of curiosity: does the '888' in '8.2.5h-888-g798bb8d' is a number > that is incremented chronologically? If this is correct (I'm not > familiar with this at all), FWIW, the bug was not caused only by the > patch '8.2.5h-888-g798bb8d', since I observed it also with version > 8.2.5h-94-g91175a. > 888 is the number of commits since the commit that was tagged '8.2.5h'. Unfortunately, that number can be misleading: in the face of merges, there may be multiple paths that lead from some commit back to the tagged commit (run `gitk master' if you want to see the multiple paths), so the "number of commits since the tag" is ambiguous. It is only unambiguous if the history is strictly linear. If you do `git log --oneline -100' on master, you'll see that there is a merge commit d25846b that looks like this: , | $ git show d25846b | commit d25846b2340e32dea93fc89ea432f74a7f64d950 | Merge: f261833 91175a3 | Author: Nicolas Goaziou | Date: Sat Mar 29 15:02:10 2014 +0100 | | Merge branch 'maint' ` The merge commit has two parents: f261833 and our old friend 91175a3. Try git describe on this commit: git describe d25846b It's only one commit ahead of 91175a3 but I get release_8.2.5h-873-gd25846b so it's 873 commits ahead of 8.2.5h, not 95! But that's because `git describe' takes a different, much longer, path back to the tagged commit: it follows the first parent of the merge commit. So I'm pretty sure that the patch that the bisection fingered is indeed the culprit. I believe this is correct but if not, Achim will correct me:-) -- Nick
[O] [ANN] org-watchdoc.el --- Watchdog for exported Org-mode trees
Hi List, I wrote a little library that is just a small toolbox, but quite useful in combination with outshine.el and outorg.el. This was mainly inspired by the new announcement of the new ox-gfm.el exporter, because it enables the export of nice looking README.md files for github from Org-mode. org-watchdoc takes care of keeping such exported files in sync with the associated Org file. Its prime use case is the reuse of the comment-section of Emacs Lisp libraries as README file and other types of documentation. I wrote an excessively long comment-section for the small library org-watchdoc.el such that it can serve as a good example for its own usage. The ASCII export of this comment section is attached. Note that I added 5 export targets (md, org, html, ascii and latex). In this case, the .md file is actually used on github, and the .org file on Worg, the others are just examples. When I want to change the comment-section of this library, I do it in full Org-mode with outorg, and org-watchdoc makes sure that all registered targets are reexported when I exit the outorg-edit-buffer. This saves me a lot of work: I write documentation only once, and I edit it in only one place, very comfortably in full Org-mode. But I'm a good citizen and add a README on github, a doc on Worg, maybe a HTML post in a Blog and a LaTeX/PDF doc for download. And I want a very readable ASCII version for the announcement email. With org-watchdoc I only have to add the export targets once as properties to the top-level comment-section tree. Then they will be re-exported and kept in sync automatically everytime I make a change to that comment-section tree. While writing this email I could already use org-watchdoc. I noticed that I had two different version numbers in the docs, 0.9 and 1.0. Since there were 6 files with this mistake (.el, .org, .md, .tex, .html, .txt) I was really happy to just do M-# M-+ in org-watchdoc.el, fix the error in the *outorg-edit-buffer*, and exit with M-#, letting org-watchdoc take care of updating the other 5 files. __ ORG-WATCHDOC Thorsten Jolitz tjolitz at gmail dot com __ <2014-04-09 Mi> Table of Contents _ 1 org-watchdoc.el --- Watchdog for exported Org-mode trees .. 1.1 MetaData .. 1.2 Commentary .. 1.3 Installation .. 1.4 Usage . 1.4.1 Commands . 1.4.2 Interactive Use . 1.4.3 Use with Outorg . 1.4.4 Keybindings in Outshine . 1.4.5 ChangeLog 1 org-watchdoc.el --- Watchdog for exported Org-mode trees == EXPORT_OPTIONS: prop:nil wdoc_1992rwM: /home/tj/git/org-watchdoc/README.md /home/tj/git/org-watchdoc/export-templates/org-watchdoc-gh.org gfm wdoc_1992G_r: /home/tj/gitclone/worg/org-contrib/org-watchdoc.org /home/tj/git/org-watchdoc/export-templates/org-watchdoc-worg.org org wdoc_1992gas: /home/tj/git/org-watchdoc/targets/org-watchdoc.html /home/tj/git/org-watchdoc/export-templates/org-watchdoc-gh.org html wdoc_1992tky: /home/tj/git/org-watchdoc/targets/org-watchdoc.txt /home/tj/git/org-watchdoc/export-templates/org-watchdoc-gh.org ascii wdoc_1992fuB: /home/tj/git/org-watchdoc/targets/org-watchdoc.tex /home/tj/git/org-watchdoc/export-templates/org-watchdoc-gh.org latex Copyright (C) from 2014 Thorsten Jolitz Author: Thorsten Jolitz Keywords: org-mode, exporter, propagate changes, documentation 1.1 MetaData copyright: Thorsten Jolitz copyright-years: 2014+ version: 1.0 licence: GPL 3 or later (free software) licence-url: http://www.gnu.org/licenses/ part-of-emacs: no git-repo: https://github.com/tj64/org-watchdoc.git git-clone: git://github.com/tj64/org-watchdoc.git author: Thorsten Jolitz author_email: tjolitz AT gmail DOT com 1.2 Commentary ~~ This library implements functionality for keeping exported files associated with Org subtrees up-to-date. Its principal use case is writing the comment-section of Emacs Lisp (or other) source-code files only once (and in full Org-mode using outorg.el), export it as README documentation from the *outorg-edit-buffer* to html, ascii, latex/pdf, markdown-github-flavor or whatever, and keep the exported doc files automatically up-to-date when the original comment-section of the source-buffer is edited explicitly with outorg (via M-x outorg-edit-comments-and-propagate-changes). org-watchdoc is just a little toolbox that can be used independently from outorg too. All its functions are commands, so its functionality is available for interactive use too. 1.3 Installation Put this line in your init file , | (require 'org-watchdoc) ` and make sure Emacs can find the file org-watchdoc.el. To take real advanta
[O] Patch to fix `org-test-with-temp-text'
Hi list, I've just found a bug in `org-test-with-temp-text' and have fixed it. Please find attached my patch for the fix. Here's the description from git commit message: According to the docstring, if the string "" appears in TEXT then the string "" is removed and point is placed there. The problem was that after string "" was removed, the point was *not* placed at the position of the removed text, rather, it was placed one character before that position which is wrong. The reason is that Emacs buffer position is a number started from 1, instead of 0, in other words, the value of `(point-min)' is 1 not 0. The problem is addressed by adding 1 to the calculated position. I'm going to report another bug together with a reproducer written as an "org-test". But my test relies on my fix in `org-test-with-temp-text'. Therefor, I will appreciate it if this patch can be taken care of as soon as possible. Thank you, York From 9bbfc37ab059e923c57eaa99e3a2d81144c80218 Mon Sep 17 00:00:00 2001 From: York Zhao Date: Wed, 9 Apr 2014 13:39:16 -0400 Subject: [PATCH] testing/org-test.el (org-test-with-temp-text): Fix point position According to the docstring, if the string "" appears in TEXT then the string "" is removed and point is placed there. The problem was that after string "" was removed, the point was *not* placed at the position of the removed text, rather, it was placed one character before that position which is wrong. The reason is that Emacs buffer position is a number started from 1, instead of 0, in other words, the value of `(point-min)' is 1 not 0. The problem is addressed by adding 1 to the calculated position. TINYCHANGE --- testing/org-test.el | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/testing/org-test.el b/testing/org-test.el index 879d45e..983c012 100644 --- a/testing/org-test.el +++ b/testing/org-test.el @@ -209,11 +209,12 @@ otherwise place the point at the beginning of the inserted text." (with-temp-buffer (org-mode) (let ((point (string-match (regexp-quote "") inside-text))) - (if point - (progn (insert (replace-match "" nil nil inside-text)) - (goto-char (match-beginning 0))) - (progn (insert inside-text) - (goto-char (point-min) + (if point + (progn + (insert (replace-match "" nil nil inside-text)) + (goto-char (1+ (match-beginning 0 + (progn (insert inside-text) + (goto-char (point-min) ,@body))) (def-edebug-spec org-test-with-temp-text (form body)) -- 1.8.4
Re: [O] Override global export-option prop:t
Nicolas Goaziou writes: > Hello, > > Thorsten Jolitz writes: > >> This minimal Org buffer "tmp<2>" >> >> , >> | #+OPTIONS: prop:t >> | >> | * A >> | :PROPERTIES: >> | :EXPORT_OPTIONS: prop:nil >> | :END: >> | >> | C >> | >> | * B >> | :PROPERTIES: >> | :DESCRIPTION: Headline B >> | :END: >> | >> | D >> ` >> >> exports to >> >> ,--- >> | tmp<2> >> | >> | Table of Contents >> | >> | * 1. A >> | * 2. B >> | >> | 1 A >> | >> | EXPORT_OPTIONS: prop:nil >> | >> | C >> | >> | 2 B >> | >> | DESCRIPTION: Headline B >> | >> | D >> | >> | Author: Thorsten Jolitz >> | >> | Created: 2014-04-09 Mi 22:44 >> | >> | Emacs 24.3.1 (Org mode 8.2.5h) >> | >> | Validate >> `--- >> >> but I would have expected that the options node-property prop:nil >> overrides the global option prop:t. >> >> Bug or wrong usage? > > Wrong usage. EXPORT_* properties only apply when export scope is the > current subtree (C-s in export dispatcher). I see ... but is there any possibility to export a buffer with global option prop:t but inhibit the property-drawer export for one specific subtree (would be subtree A in the example above)? Similar to :noexport: tags for headlines? -- cheers, Thorsten
Re: [O] Override global export-option prop:t
Hello, Thorsten Jolitz writes: > This minimal Org buffer "tmp<2>" > > , > | #+OPTIONS: prop:t > | > | * A > | :PROPERTIES: > | :EXPORT_OPTIONS: prop:nil > | :END: > | > | C > | > | * B > | :PROPERTIES: > | :DESCRIPTION: Headline B > | :END: > | > | D > ` > > exports to > > ,--- > | tmp<2> > | > | Table of Contents > | > | * 1. A > | * 2. B > | > | 1 A > | > | EXPORT_OPTIONS: prop:nil > | > | C > | > | 2 B > | > | DESCRIPTION: Headline B > | > | D > | > | Author: Thorsten Jolitz > | > | Created: 2014-04-09 Mi 22:44 > | > | Emacs 24.3.1 (Org mode 8.2.5h) > | > | Validate > `--- > > but I would have expected that the options node-property prop:nil > overrides the global option prop:t. > > Bug or wrong usage? Wrong usage. EXPORT_* properties only apply when export scope is the current subtree (C-s in export dispatcher). Regards, -- Nicolas Goaziou
Re: [O] [BUG] in ox-org.el?
Hello, Thorsten Jolitz writes: > when I export this org buffer > > ,--- > | * A > | > | ** A1 > | > | text > | > | * B > | > | ** B1 > | > | more text > | > | * C > | > | ** C1 > | > | even more text > `--- > > to another org buffer I get: > > ,- > | # Created 2014-04-09 Mi 23:04 > | #+TITLE: tmp<3> > | #+AUTHOR: Thorsten Jolitz > | * A > | > | ** A1 > | > | text > | * B > | > | ** B1 > | > | more text > | * C > | > | ** C1 > | > | even more text > | > | # Emacs 24.3.1 (Org mode 8.2.5h) > `- > > i.e. leading or trailing empty lines are treated differently. This should be fixed. Thank you for reporting it. Regards, -- Nicolas Goaziou
[O] [BUG] in ox-org.el?
Hi List, when I export this org buffer ,--- | * A | | ** A1 | | text | | * B | | ** B1 | | more text | | * C | | ** C1 | | even more text `--- to another org buffer I get: ,- | # Created 2014-04-09 Mi 23:04 | #+TITLE: tmp<3> | #+AUTHOR: Thorsten Jolitz | * A | | ** A1 | | text | * B | | ** B1 | | more text | * C | | ** C1 | | even more text | | # Emacs 24.3.1 (Org mode 8.2.5h) `- i.e. leading or trailing empty lines are treated differently. This looks strange in real documents, since exactly where one would expect a visible separation (before/after top level entries) empty lines are removed, while they are preserved in other structurally less significant places. -- cheers, Thorsten
[O] Override global export-option prop:t
Hi List, This minimal Org buffer "tmp<2>" , | #+OPTIONS: prop:t | | * A | :PROPERTIES: | :EXPORT_OPTIONS: prop:nil | :END: | | C | | * B | :PROPERTIES: | :DESCRIPTION: Headline B | :END: | | D ` exports to ,--- | tmp<2> | | Table of Contents | | * 1. A | * 2. B | | 1 A | | EXPORT_OPTIONS: prop:nil | | C | | 2 B | | DESCRIPTION: Headline B | | D | | Author: Thorsten Jolitz | | Created: 2014-04-09 Mi 22:44 | | Emacs 24.3.1 (Org mode 8.2.5h) | | Validate `--- but I would have expected that the options node-property prop:nil overrides the global option prop:t. Bug or wrong usage? -- cheers, Thorsten
Re: [O] Fwd: Is `org-preview-latex-fragment` sensitive to alignment specified by document class options?
Rob Stewart writes:
>
> I asked the question below a few days ago, about whether
> `org-preview-latex-fragment` is sensitive document class options that
> might affect alignment. I've so far not received feedback, and
> wondered whether there is more information that I could provide, or if
> my question is not interesting to other people :-)
>
>
>
> Is there a way to make `org-preview-latex-fragment` sensitive to LaTeX
> class options? I have a simple example to demonstrate where it does
> not:
>
> %%% #+LaTeX_CLASS: article #+LaTeX_CLASS_OPTIONS: [fleqn]
> #+LATEX_HEADER: \usepackage{amsmath}
>
> \begin{gather} b := (a \oplus s_1) \oplus s_2 \\ e := 0 \\
> \end{gather} %%%
>
> If LaTeX is generated for this document with
> `org-latex-export-to-latex`, which is compiled to a PDF with pdflatex,
> the "b :=" and the "e :=" are left aligned i.e. the "b" and "e" are
> vertically aligned.
>
> However, if `org-preview-latex-fragment` is called within emacs, the
> left alignment specified with the `[fleqn]` class option is not
> honoured. Thus, the two lines in the `gather` block are centrally
> aligned, which is the default case for `gather` blocks.
>
org-preview-latex-image is its own self-contained universe and has very
little in common with latex exporting. In particular, the preview
preamble is generated by calling org-create-formula--latex-header. Try
evaluating a call to the function in your *scratch* buffer and see what
it gives you - I get:
,
| (org-create-formula--latex-header)
| "\\documentclass{article}
| \\usepackage[usenames]{color}
| % Package minted omitted
| \\usepackage[utf8]{inputenc}
| \\usepackage[T1]{fontenc}
| % Package fixltx2e omitted
| \\usepackage{graphicx}
| % Package longtable omitted
| % Package float omitted
| % Package wrapfig omitted
| % Package rotating omitted
| \\usepackage[normalem]{ulem}
| \\usepackage{amsmath}
| \\usepackage{textcomp}
| \\usepackage{marvosym}
| \\usepackage{wasysym}
| \\usepackage{amssymb}
| % Package hyperref omitted
| \\tolerance=1000
| \\pagestyle{empty} % do not remove
| % The settings below are copied from fullpage.sty
| \\setlength{\\textwidth}{\\paperwidth}
| \\addtolength{\\textwidth}{-3cm}
| \\setlength{\\oddsidemargin}{1.5cm}
| \\addtolength{\\oddsidemargin}{-2.54cm}
| \\setlength{\\evensidemargin}{\\oddsidemargin}
| \\setlength{\\textheight}{\\paperheight}
| \\addtolength{\\textheight}{-\\headheight}
| \\addtolength{\\textheight}{-\\headsep}
| \\addtolength{\\textheight}{-\\footskip}
| \\addtolength{\\textheight}{-3cm}
| \\setlength{\\topmargin}{1.5cm}
| \\addtolength{\\topmargin}{-2.54cm}"
`
As you can see both the document class and the class options (none)
are hardwired.
The function looks like this
,
| (defun org-create-formula--latex-header ()
| "Return LaTeX header appropriate for previewing a LaTeX snippet."
| (let ((info (org-combine-plists (org-export--get-global-options
| (org-export-get-backend 'latex))
| (org-export--get-inbuffer-options
| (org-export-get-backend 'latex)
| (org-latex-guess-babel-language
| (org-latex-guess-inputenc
| (org-splice-latex-header
|org-format-latex-header org-latex-default-packages-alist
|org-latex-packages-alist t (plist-get info :latex-header)))
| info)))
`
so in order to add class options you have to redefine the variable
org-format-latex-header. But whatever you set them to, they will be
hardwired: there is no way to propagate a setting from the org
file.
Nick
[O] Fwd: Is `org-preview-latex-fragment` sensitive to alignment specified by document class options?
Hi,
I asked the question below a few days ago, about whether
`org-preview-latex-fragment` is sensitive document class options that
might affect alignment. I've so far not received feedback, and
wondered whether there is more information that I could provide, or if
my question is not interesting to other people :-)
Git blame tells me that the last commit relating to the definition of
`org-preview-latex-fragment` in lisp/org.el is fe939ec by Carsten on
22-03-2008. Who might I be able to poke directly with my question
below.
Thanks,
--
Rob
-- Forwarded message --
From: Rob Stewart
Date: 6 April 2014 21:54
Subject: Is `org-preview-latex-fragment` sensitive to alignment
specified by document class options?
To: emacs-orgmode@gnu.org
Hi,
Is there a way to make `org-preview-latex-fragment` sensitive to LaTeX
class options? I have a simple example to demonstrate where it does
not:
%%%
#+LaTeX_CLASS: article
#+LaTeX_CLASS_OPTIONS: [fleqn]
#+LATEX_HEADER: \usepackage{amsmath}
\begin{gather}
b := (a \oplus s_1) \oplus s_2 \\
e := 0 \\
\end{gather}
%%%
If LaTeX is generated for this document with
`org-latex-export-to-latex`, which is compiled to a PDF with pdflatex,
the "b :=" and the "e :=" are left aligned i.e. the "b" and "e" are
vertically aligned.
However, if `org-preview-latex-fragment` is called within emacs, the
left alignment specified with the `[fleqn]` class option is not
honoured. Thus, the two lines in the `gather` block are centrally
aligned, which is the default case for `gather` blocks.
This is a screenshot of the PDF: http://imgur.com/YVRAlYP
This is a screenshot of the preview within emacs: http://imgur.com/S6BNm0K
So, is there a way to make `org-preview-latex-fragment` sensitive to
LaTeX class options?
Thanks,
--
Rob
Re: [O] [ANN] Firefox extension for org-protocol and org-capture
Dear list, Following all the nice comments you made after my first announce, I just uploaded an updated version of the org-capture extension. You can find it on the main webpage http://chadok.info/firefox-org-capture/ or on the Mozilla addons repository https://addons.mozilla.org/fr/firefox/addon/org-mode-capture/ (review pending from Mozilla people). New features: - Hotkey (default: C-M-r) - New emacsclient window (using -c) Best, Olivier
[O] bug#16832: 24.3.50; Emacs hangs in Org mode file
Glenn Morris writes: > Glenn Morris wrote: > >> Perhaps this is fixed now, according to comments at: >> >> http://lists.gnu.org/archive/html/emacs-orgmode/2014-03/msg01176.html >> >> (It would be great if someone would keep an eye on these Org bugs that >> get reported to Emacs and update them when appropriate. >> >> Although it seems better to report Org bugs to the Org-mode list rather >> than to Emacs.) > > No comments in two weeks so closed, presumed fixed. I confirm the fix. I will catch up and close other fixed Org bugs when I have some spare time, somewhere next week. -- Bastien
Re: [O] Agenda items refer to the wrong headline
Nick, you say you could not reproduce the bug using version 8.2.5h-667-g971dc4, but you did with version 8.2.5h-888-g798bb8d. Just out of curiosity: does the '888' in '8.2.5h-888-g798bb8d' is a number that is incremented chronologically? If this is correct (I'm not familiar with this at all), FWIW, the bug was not caused only by the patch '8.2.5h-888-g798bb8d', since I observed it also with version 8.2.5h-94-g91175a. FC On Wed, Apr 9, 2014 at 3:52 PM, Nick Dokos wrote: > Nick Dokos writes: > > > > > Starting from release_8.2.5h-888-g798bb8d (this was latest as of this > > morning) and reverting the above commit fixes Fletcher's problem. > > > > Just to be clear: I'm *not* advocating that the commit be reverted. > I used the revert just to confirm that something in that patch caused > the problem that Fletcher observed. > > Nick > > >
Re: [O] Agenda items refer to the wrong headline
Nick Dokos writes: > > Starting from release_8.2.5h-888-g798bb8d (this was latest as of this > morning) and reverting the above commit fixes Fletcher's problem. > Just to be clear: I'm *not* advocating that the commit be reverted. I used the revert just to confirm that something in that patch caused the problem that Fletcher observed. Nick
[O] Assign clocking gaps to tasks in clockcheck view?
I'm using org-mode 8.2. I'm trying to use clocking all the time during my working day to know later, what I used my time for. Unfortunately, I often forget clocking in and therefore have clocking gaps in my files. I can visualize them with the "vc" command in the agenda view, but now I have to assign the time in the gaps to the task(s) I was working on in that time. It would be very handy, if I could navigate to the line with the gap and then use a command to copy that time gap and move it to the logbook of a heading or clock. Is that possible already? I even can not navigate into those clocking gap lines in the agenda, so I can not select them for further action.- Kind regards Martin
Re: [O] Maintainer change on May 1st
On Wednesday, 9 Apr 2014 at 09:04, David Belohrad wrote: > Hi, > > it has been some time I've switched to org for all my life agenda. I > have to say that it is a perfect tool and I cannot imagine my life > without it any more. I just tried to imagine this. I cannot even remember the whole set of tools and procedures that org has replaced for me but, at the very least: org >= eclipse + hnb + tkremind + latex(auctex) + sc + ? The only thing it hasn't replaced is gnus but at least that's also in emacs! Mind you, it's helped even there with org-mime-htmlize for communicating sometimes with those people that love HTML email... ;-) Back to work now! Using org, of course, as I'm writing a funding proposal. -- : Eric S Fraga (0xFFFCF67D), Emacs 24.4.50.2, Org release_8.2.5h-888-g798bb8
Re: [O] Add-on: Github Flavored Markdown exporter
Charles Berry writes:
> Lars Tveito student.matnat.uio.no> writes:
>
>>
>> Hi, thanks for checking it out!
>>
>> Thorsten Jolitz writes:
>>
>> > Thorsten Jolitz gmail.com> writes:
>> >
>> >> Lars Tveito 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] Maintainer change on May 1st
Hi, it has been some time I've switched to org for all my life agenda. I have to say that it is a perfect tool and I cannot imagine my life without it any more. Thanks for all this excellent sw, I guess we all know how much effort one has to invest into the software development to make it ergonomic and usable, especially when we talk about something what is developed for free in someone's spare time. .d. Carsten Dominik writes: > Thanks Eric! > > - Carsten > > > On Fri, Apr 7, 2000 at 8:09 PM, Eric S Fraga wrote: > >> On Monday, 7 Apr 2014 at 16:24, Carsten Dominik wrote: >> > Hi everyone, >> > >> > per May 1st, I would like to swing the official maintainership back to >> > Bastien, who has agreed to this change. This really only means putting >> > facts onto websites, because Bastien has in effect been doing this job >> all >> > the time - I have unfortunately been unable to make time free to >> contribute >> > here in any meaningful way, for which I apologise. I trust that an >> > overwhelming majority of you will have not objections to this step >> >> Just to help ensure that we are not a silent majority, I have no >> objection to this at all! >> >> thanks to both of you for all the effort you have and continue to put >> into this project. >> >> -- >> : Eric S Fraga (0xFFFCF67D), Emacs 24.3.1, Org release_8.2.5h-660-gef207f >>
Re: [O] Example text and source code in agenda - orgmanual.org typo
Hello, Am 08.04.2014 21:31, schrieb Nicolas Goaziou: n...@tsdye.com (Thomas S. Dye) writes: When I was working on the project I hoped the Org mode developers would choose to "eat their own dog food" (as Carsten put it to me) and prepare the texinfo and other documentation with Org mode source. Of course, that hope was based on considerable naivete and an imperfect understanding of how Org mode is connected with the rest of the Emacs world. FWIW, I still think it would be good to have our documentation in our home-made format. Of course, there's the problem of backporting documentation fixes coming from Emacs developers, but we might find volunteers to take care of it. Also, it doesn't happen very frequently. There may be other road blocks that I'm not aware of, but if there is none, I suggest to think about the feasibility of this project again. now I know more about the history and status of this project, thanks to your answers. Although it looks to me as a good starting point, It also seems to take quite a bit of knowledge about many things to go on here, so I am not the one who could help. But maybe the volunteers can be found. Regards, Gerhard
Re: [O] Add-on: Github Flavored Markdown exporter
Lars Tveito 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
