Re: [O] Setup Org-mode to write diary.
stardiviner numbch...@gmail.com writes: I want to know how to configure Org-mode to write diary with a easy way. I hope someone can provide his way. Here is what I think what Org-mode write diary should have. - [ ] *open/create* a buffer to write current day's diary quickly. - [ ] *navigate* diary entry like viewing day entries in Calendar. - [ ] *manage* diary files with some kind of style like (date, folder, etc). - [ ] *search* diary content. If you have some hints, welcome to tell me, thanks in advance. I've kept a diary in org-mode for a year and a half now, like this - --8---cut here---start-8--- * July ** 26 Sat blah de blah, etc! ** 27 Sun not yet, it isn't here yet! --8---cut here---end---8--- Using that way it is auto-menued [is there such a word? I can't think of a better way of putting it, sorry!] with Imenu so it is easy to go back to a specific day. But I have found that I can't have more that 3 months worth of postings in a buffer, without things slowing down and seeming to get slightly corrupted. So at the end of every quarter, I transfer postings over from 2014a.org to 2014.org, which isn't very often used or accessed, but its available if its needed. Hope it helps Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.3.92.1 signature.asc Description: PGP signature
Re: [O] Exporting html: any way to customize format h1 class=title?
Hello, Matt Lundin m...@imapmail.org writes: AFAICT, there is no filter that would enable one to bypass the h1 tag her or to give it different text than the title tag. [...] In the old export backends there were hooks that allowed some small modifications on the html after exporting it However, the two hooks of the new export backend hooks (org-export-before-processing-hook, org-export-before-parsing-hook) are called on copies of the org source. See `org-export-filter-final-output-functions'. Regards, -- Nicolas Goaziou
Re: [O] Setup Org-mode to write diary.
Sharon Kimble boudiccas at skimble.plus.com writes: But I have found that I can't have more that 3 months worth of postings in a buffer, without things slowing down and seeming to get slightly corrupted. That would be three main headings and about 30 sub-headings under each, giving a total of 120 sub-headings. Do you have line-numbering on?
Re: [O] File name with space
Yes it does. Thanks! On Sat, Jul 26, 2014 at 7:38 AM, Nick Dokos ndo...@gmail.com wrote: Chris Henderson henders...@gmail.com writes: How do I link a local file or folder that has space? Looks like the link goes broken. e.g. file+sys:///Users/chris/projects/marketing plan for 2014 -- doesn't work. I tried: file+sys:///Users/chris/projects/marketing\ plan\ for\ 2014 -- which also doesn't work. file+sys:///Users/chris/projects/marketing%20plan%20for%202014 should work at least in the buffer and HTML export. Nick
Re: [O] Possible to use src block to generate org headlines for export?
But in that case let me return to and refine my proposal: Why not have drawer as the default unless raw is given? Probably because raw never breaks your document, and is less verbose in the simplest cases (e.g., a single list, value, table...), which may be common enough. Anyway, it should be simple enough to switch to drawer as a default in your setup. One could argue, that the extent of the results is implicitly given when the results are not raw, but being explicit here would allow for some additional features (such as different background for results -- is anyone doing this? I'd be interested). raw doesn't prevent to add a different background, if needed. This is the state in org This is what I'd prefer... --8--start8--- --8--start8--- #+PROPERTY: results drawer #+PROPERTY: results drawer * Test * Test #+name: dtrn #+name: dtrn #+begin_src R :exports both#+begin_src R :exports both hellohello #+end_src #+end_src #+results: dtrn :RESULTS: #+begin_results dtrn hello hello :END: #+end_results --8---end-8--- --8---end-8--- What you prefer is a special block, which is not neutral during export process. Of course, a result block type could be added to Org syntax, but that would be redundant with drawers. Regards, -- Nicolas Goaziou
Re: [O] How to setup this custom function with Org-mode functions? (org-habit)
This is what I want, thanks very much. Marcin Borkowski mb...@wmi.amu.edu.pl writes: Dnia 2014-03-28, o godz. 16:09:01 stardiviner numbch...@gmail.com napisał(a): I want to create a custom keybinding to custom function which will execute all necessary steps for creating an org habit. The bellowing is my code, but seems it doesn't work at all. I don't know how to write this custom function actually. (I just put some keybindings corresponding functions in the custom function body.) And some org-mode functions are interactively. #+BEGIN_SRC emacs-lisp ;; TODO: create an key binding for all necessary steps for create a habit. (reference in Org-mode.org file) (defun org-habit-apply () Apply org-habit on this task. (interactive) (lambda () (org-todo HABIT) (org-insert-property-drawer); TODO: :STYLE: habit (value) (org-schedule))) (define-key org-mode-map (kbd C-c C-x h) 'org-habit-apply) #+END_SRC Does anybody can help me this? and thanks in advance. Is this of any help? http://mbork.pl/2013-09-23_Automatic_insertion_of_habit_templates_%28en%29 Hth,
Re: [O] Bug: wrong interpretation of LaTeX [8.2.6 (8.2.6-47-ge3d2c1-elpa @ c:/Users/beffa/.emacs.d/elpa/org-20140526/)]
Federico Beffa be...@ieee.org writes:
Of course \[ 1+1 \] is valid LaTeX syntax, just as inline
\begin{displaymath} 1+1 \end{displaymath} is valid.
But \begin{displaymath} 1+1 \end{displaymath} isn't valid in an Org
paragraph.
In my opinion a construct which will be displayed on a line by itself
and with some space separating it from the preceding and the following
text lines such as \[ ... \] would be better represented as a
latex-environment and not an inline latex-fragment. In this way the
org-mode text representation with proper fill-paragraph handling would
be much more readable and consistent with the meaning of the syntax
that it borrowed.
That would prevent \[...\] to be recognized within a paragraph, as in
the example above. I don't think it's worth removing it as long as there
is a latex-environment alternative for it.
Regards,
--
Nicolas Goaziou
Re: [O] Bug: wrong interpretation of LaTeX [8.2.6 (8.2.6-47-ge3d2c1-elpa @ c:/Users/beffa/.emacs.d/elpa/org-20140526/)]
I understand that. However, using \[...\] inline within a paragraph is
not the intended use of \[...\]. The use of \[...\] is for
mathematical expressions which you want to stand out, on their own
lines.
For inline mathematical expressions there are the constructs \(...\) and $...$.
Regards,
Fede
On Sat, Jul 26, 2014 at 10:26 AM, Nicolas Goaziou
m...@nicolasgoaziou.fr wrote:
Federico Beffa be...@ieee.org writes:
Of course \[ 1+1 \] is valid LaTeX syntax, just as inline
\begin{displaymath} 1+1 \end{displaymath} is valid.
But \begin{displaymath} 1+1 \end{displaymath} isn't valid in an Org
paragraph.
In my opinion a construct which will be displayed on a line by itself
and with some space separating it from the preceding and the following
text lines such as \[ ... \] would be better represented as a
latex-environment and not an inline latex-fragment. In this way the
org-mode text representation with proper fill-paragraph handling would
be much more readable and consistent with the meaning of the syntax
that it borrowed.
That would prevent \[...\] to be recognized within a paragraph, as in
the example above. I don't think it's worth removing it as long as there
is a latex-environment alternative for it.
Regards,
--
Nicolas Goaziou
Re: [O] Setup Org-mode to write diary.
SabreWolfy sabrewo...@gmail.com writes: Sharon Kimble boudiccas at skimble.plus.com writes: But I have found that I can't have more that 3 months worth of postings in a buffer, without things slowing down and seeming to get slightly corrupted. That would be three main headings and about 30 sub-headings under each, giving a total of 120 sub-headings. Do you have line-numbering on? Yes, but I don't take much notice of it. Sharon. -- A taste of linux = http://www.sharons.org.uk my git repo = https://bitbucket.org/boudiccas/dots TGmeds = http://www.tgmeds.org.uk Debian testing, fluxbox 1.3.5, emacs 24.3.92.1 signature.asc Description: PGP signature
Re: [O] c-c ' strips final newline or adds blank line, but never neither
Samuel Wales samolog...@gmail.com writes: hi Samuel, did you try it? no, that was just a hint. But I know what you are talking about, since I had these problems with Outorg too - whitespace changes in the conversion process between programming language mode and org-mode although no editing at all took place. The following chain of actions should not change the original (say emacs-lisp) buffer: 1. M-# # (outorg-edit-as-org) in emacs-lisp buffer 2. 2x C-c ' on emacs-lisp src-block 3. M-# in *outorg-edit-buffer* since only 4 conversions but no editing at all took place. But depending on your config (or the org defaults) and maybe org/outorg bugs indentation and newlines might have been added removed. In outorg I have e.g. , | outorg-remove-trailing-blank-lines | outorg-unindent-active-source-blocks ` to deal with this issue. IIRC I always first remove all trailing-blank-lines, and then add one. Isn't that even an 'upstream' issue? It seems Emacs itself inserts trailing blank lines in buffers if they are missing, at least I had to deal with this in the outorg conversion process. I vaguley remember having read something about 'by default every buffer should end with a trailing blank line, and this is enforced by Emacs', but could not find any info about this nor related config vars. On 7/25/14, Thorsten Jolitz tjol...@gmail.com wrote: Samuel Wales samolog...@gmail.com writes: i find that when i do c-c ' on a source block, it either strips the final newline in the editing buffer or adds an unwanted blank line in the source block. i like to have final newlines in all of my buffers, including editing buffers. what setting allows this without introducing a blank line at the end of a source block? ,[ C-h v org-src-strip-leading-and-trailing-blank-lines RET ] | org-src-strip-leading-and-trailing-blank-lines is a variable defined | in `org-src.el'. Its value is nil | | Documentation: | If non-nil, blank lines are removed when exiting the code edit buffer. ` -- cheers, Thorsten -- cheers, Thorsten
Re: [O] Exporting html: any way to customize format h1 class=title?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, Matt Lundin m...@imapmail.org writes: AFAICT, there is no filter that would enable one to bypass the h1 tag her or to give it different text than the title tag. [...] In the old export backends there were hooks that allowed some small modifications on the html after exporting it However, the two hooks of the new export backend hooks (org-export-before-processing-hook, org-export-before-parsing-hook) are called on copies of the org source. See `org-export-filter-final-output-functions'. Thanks, Nicolas! I suspected I was missing something. Sorry I overlooked that in the documentation. Again, many, many thanks again for the org-element and the new export backends. They have made publishing with org-mode a delight. Best, Matt
Re: [O] Multi-line links
Hello, Tobias Getzner tobias.getz...@gmx.de writes: I’m afraid given my nigh complete inexperience with elisp it is unlikely I’ll be able to provide a good, generic solution for this. My original hope was that for someone familiar with the code, there wouldn’t be many changes needed, In the long run, I'm pretty sure the project will benefit more if you bring in your own, temporary, inexperience and start hacking from there. since multi-line descriptions seemed to be working (though only for 3 lines) and since the raw-path seemed to contain the needed line-breaks already. But if I understand you correctly, the complication is that the path parsing is the same across different link types, and so one cannot simply fix it up so that :path is equivalent to :raw-path, just with the link prefix stripped of? I fixed it in maint. org-element.el used an inadequate regexp to analyze the path. Could you confirm it? Regards, -- Nicolas Goaziou
[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug
Le 16 juil. 2014 à 18:38, Eli Zaretskii e...@gnu.org a écrit : From: Lionel Henry lionel@gmail.com Date: Wed, 16 Jul 2014 15:39:04 +0200 Activating both linum-mode and org-indent-mode will cause several graphical glitches in the current line. See http://lists.gnu.org/archive/html/emacs-orgmode/2011-01/msg01204.html That discussion provides no reproducible recipe. OK I finally found a ROA First create a .org file and put the rainbow-delimiters package in your load path. Then execute this : (progn (require 'rainbow-delimiters) (rainbow-delimiters-mode) (linum-mode) (org-indent-mode)) Then enter this in the org file : * head 1 ** head 2 line 1 line 2 Line 2 is important, without it the bug does not happens. Now modify head 2. The linum number will disappear and the whole active line will shift to the left. So it's an interaction between linum, org-indent-mode, and rainbow-delimiters-mode. Lionel
[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug
So it's an interaction between linum, org-indent-mode, and rainbow-delimiters-mode. Of course rainbow-delimiters is not very useful in org files, so this is not a very important bug. I'll just disable it for org-mode.
[O] [Mac OS X] - Capture items not clocking-out upon refile
Hello, I am running Mac OS X 10.8 (Mountain Lion) and emacs 24.3. I am essentially re-creating Brent Hansen's excellent org-mode setup, detailed here: http://doc.norang.ca/org-mode.html#ClockSetup (I am using pretty much all of his customisations listed on that page, but have linked to the ClockSetup part in case it is relevant) However I have run in to an issue which seems to be specific to the vanilla builds of emacs on the Mac OS platform. When adding a task via org-capture (C-c c), as per Brent's system the capture item is clocked-in. Once the capture item is amended, if I do a 'C-c C-c' to save the task to the inbox, it clocks-out of the task as intended. However, if I choose instead to immediately refile the capture item (C-c C-w), the task is not clocked-out automatically upon choosing a refile destination, and instead remains clocked in until I manually clock-out (not intended behaviour). I have tried emacs builds from various places: emacsforosx.com emacs via homebrew (with both the X11 and Cocoa versions) emacs via macports Yamamoto Mitsuharu's version via homebrew The ONLY version which does not replicate this bug is: aquamacs Unfortunately I find aquamacs' customisation of emacs quite invasive (for example, my .emacs colour theme does not work out of the box) so it is not an option for me. The bug does NOT exist on Windows builds of emacs. I have already tried removing the customisations from my .emacs file, this has not helped. Also I have used the same .emacs file with my customisations with Windows builds and aquamacs and have not run in to the issue so I think I can safely rule out my .emacs file. Any help would be appreciated!
[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug
From: Lionel Henry lionel@gmail.com Date: Sat, 26 Jul 2014 17:03:49 +0200 Cc: 18...@debbugs.gnu.org, michael_heerde...@web.de First create a .org file and put the rainbow-delimiters package in your load path. Then execute this : (progn (require 'rainbow-delimiters) (rainbow-delimiters-mode) (linum-mode) (org-indent-mode)) Then enter this in the org file : * head 1 ** head 2 line 1 line 2 Line 2 is important, without it the bug does not happens. Now modify head 2. The linum number will disappear and the whole active line will shift to the left. So it's an interaction between linum, org-indent-mode, and rainbow-delimiters-mode. Thanks. AFAICS, rainbow-delimiters-mode uses the JIT Font Lock machinery to do its job, which might conflict with org-indent's usage of an idle timer and/or fail to trigger linum-mode's update on that line. When I modify the head 2 line, the line number is still visible, but then about a second later the line gets re-indented and the line number disappears. I suggest that you report this to the developers of org-indent and rainbow-delimiters-mode, and ask them to debug this. If their conclusion is that this is a core Emacs problem, please get back here and report the details.
[O] bug#18035: Linum-mode + org-indent-mode results in graphical bug
Le 26 juil. 2014 à 17:36, Eli Zaretskii e...@gnu.org a écrit : Thanks. AFAICS, rainbow-delimiters-mode uses the JIT Font Lock machinery to do its job, which might conflict with org-indent's usage of an idle timer and/or fail to trigger linum-mode's update on that line. When I modify the head 2 line, the line number is still visible, but then about a second later the line gets re-indented and the line number disappears. I suggest that you report this to the developers of org-indent and rainbow-delimiters-mode, and ask them to debug this. If their conclusion is that this is a core Emacs problem, please get back here and report the details. Ok I will. But now that I've disabled rainbows and enabled linum in org-mode again, I found another bug that might be related. With emacs -Q: - Open a .org file large enough that you can scroll it. - Enable linum and org-indent-mode - Scroll The linum and the indentation will disappear in the very first line.
[O] working with tables freezes emacs
Hi all i was wondering if anyone else have had these problems (using latest emacs and org-mode from git): whenever i start working with tables and start editing a cell emacs starts freezing, all emacscleint instances are frozen and i have to kill emacs to get things back to work anyone else encountered this? is there a way i can try to debug this (im not technically savvy at all) thx alot z
Re: [O] working with tables freezes emacs
Xebar Saram zelt...@gmail.com writes: Hi all i was wondering if anyone else have had these problems (using latest emacs and org-mode from git): whenever i start working with tables and start editing a cell emacs starts freezing, all emacscleint instances are frozen and i have to kill emacs to get things back to work anyone else encountered this? is there a way i can try to debug this (im not technically savvy at all) Yes, I experience it as well. I have not found a clear receipt to reproduce yet (in particular not in with emacs -q), though, but in my case key components are: emacsclient, tables and TAB to realign. Sorry, this is not too helpful. —Rasmus -- Lasciate ogni speranza o voi che entrate: siete nella mani di'machellaio
Re: [O] [RFC] Deprecate `org-list-empty-line-terminates-plain-lists'
Nicolas Goaziou m...@nicolasgoaziou.fr writes: Hello, `org-list-empty-line-terminates-plain-lists' is an old variable (formely known as `org-empty-line-terminates-plain-lists) which doesn't make much sense nowadays. Indeed, since org-list.el revamp (around Org 7.0.1 IIRC), inserting two blank lines in a row terminates a list anyway. This is consistent with footnote definitions. Now it just makes Org files less portable without any benefit. Therefore, I suggest to mark it as deprecated in Org 8.3 release notes, and remove it altogether in Org 8.4. WDYT? Fine with me. It streamlines the syntax so it's good with me. https://xkcd.com/1172/ —Rasmus -- When in doubt, do it!
Re: [O] Possible to use src block to generate org headlines for export?
Nicolas Goaziou m...@nicolasgoaziou.fr writes: But in that case let me return to and refine my proposal: Why not have drawer as the default unless raw is given? Probably because raw never breaks your document, and is less verbose in the simplest cases (e.g., a single list, value, table...), which may be common enough. Anyway, it should be simple enough to switch to drawer as a default in your setup. True. One could argue, that the extent of the results is implicitly given when the results are not raw, but being explicit here would allow for some additional features (such as different background for results -- is anyone doing this? I'd be interested). raw doesn't prevent to add a different background, if needed. I'd be very interested in that. This is the state in org This is what I'd prefer... --8--start8--- --8--start8--- #+PROPERTY: results drawer #+PROPERTY: results drawer * Test * Test #+name: dtrn #+name: dtrn #+begin_src R :exports both#+begin_src R :exports both hellohello #+end_src #+end_src #+results: dtrn :RESULTS: #+begin_results dtrn hello hello :END: #+end_results --8---end-8--- --8---end-8--- What you prefer is a special block, which is not neutral during export process. Of course, a result block type could be added to Org syntax, but that would be redundant with drawers. Thanks for your comment on this. Yes, a special block is indeed what I'd prefer visually. And a result block type could be non-redundant with drawers if it was allowed to contain headlines and drawers ;-) But let's leave it there. As I said: I am quite fine with the drawers. Regards, Andreas
Re: [O] working with tables freezes emacs
Xebar Saram zelt...@gmail.com writes: Hi all i was wondering if anyone else have had these problems (using latest emacs and org-mode from git): whenever i start working with tables and start editing a cell emacs starts freezing, all emacscleint instances are frozen and i have to kill emacs to get things back to work anyone else encountered this? is there a way i can try to debug this (im not technically savvy at all) I recently encountered an (infloop) bug in org-element, and the tip to get a useful backtrace from the apparently frozen emacs is: [0. when on GNU/Linux, call 'top' to see if emacs uses 100pc CPU] 1. emacs -Q 2. M-x load-library org-element.el 3. do what you do to make emacs freeze 4. call on the cmd-line , | kill -s usr2 4352 ` (get the PID with 'ps -e | grep emacs') or, equivalently (?) , | pkill --signal usr2 emacs ` 5. study/copy/paste/send *Backtrace* buffer from (not frozen anymore) Emacs -- cheers, Thorsten
[O] #+header: :post - Symbol's value as variable is void: *this*
Hi List,
whats wrong with this :post header arg:
#+header: :post (format #+attr_latex :float :placement {c}{scale=.6}\n%s
*this*)
#+begin_src emacs-lisp
(+ 2 2)
#+end_src
When I understand
,
| http://orgmode.org/manual/post.html
`
correctly, *this* should hold the block results, but I get
,
| Symbol's value as variable is void: *this*
`
--
cheers,
Thorsten
[O] Stop export on bad link?
Is it possible to configure the exporter to stop and throw an error for a bad link? I found this old thread http://comments.gmane.org/gmane.emacs.orgmode/55912 with a patch to make the format configurable, but I'd rather receive an explicit warning. Thanks, Jake
[O] Advanced video tutorial
Is there any Advanced video tutorial (beyond the basics) for org-mode published in the last 1 year or so? By Advanced, I mean things archiving/ note taking/ drawers and various other new efficiency gains features that have come out with recent orgs. Most tutorials I found on the net only state the basics. Thanks.
Re: [O] c-c ' in babel source blocks strips final newline or adds blank line upon returning, but never neither
hi thorsten, i think there are several misunderstanding here. first, i am not talking about outorg at all. i am talking about babel source code blocks. i have changed the subject header to make that more obvious. outorg is not relevant to this thread, as far as i can tell. second, emacs behavior is not built in. it depends on require-final-newline. if babel would respect require-final-newline, i would be happy. however, it does not. so it is not an emacs issue in this respect. third, before posting the original post, i fully tested both the variable that you suggested and require-final-newline. the value of the former determines which bug occurs. i hope that's enough to get us all on the same page. i have very severe rsi so i limit typing to less than 4 minutes at a time. i won't be able to reply for some time.
Re: [O] c-c ' strips final newline or adds blank line, but never neither
On 7/26/14, Thorsten Jolitz tjol...@gmail.com wrote: did you try it? no, that was just a hint. if you try it you will understand that it is broken.
Re: [O] c-c ' in babel source blocks strips final newline or adds blank line upon returning, but never neither
Samuel Wales samolog...@gmail.com writes: hi samuel, i think there are several misunderstanding here. maybe not? first, i am not talking about outorg at all. i am talking about babel source code blocks. i have changed the subject header to make that more obvious. outorg is not relevant to this thread, as far as i can tell. Me too, but I had to deal with this because doing C-c ' in babel src-blocks in an *outorg-edit-buffer* might introduce newlines/indentation even if no editing takes place, and these unwanted changes cause problems because they are propagated to the original source file in the outorg conversion process. So I would say we talk about the same thing, just in a different context. second, emacs behavior is not built in. it depends on require-final-newline. if babel would respect require-final-newline, i would be happy. however, it does not. so it is not an emacs issue in this respect. Ah, `require-final-newline' was the var I was looking for when dealing with this. Thx for the tip. third, before posting the original post, i fully tested both the variable that you suggested and require-final-newline. the value of the former determines which bug occurs. Just gave a hint at the risk that you might be aware of it already. i hope that's enough to get us all on the same page. i have very severe rsi so i limit typing to less than 4 minutes at a time. i won't be able to reply for some time. Anyway, the issue deserves some attention. -- cheers, Thorsten
[O] basic checklist getting more complex
I put together a basic checklist for a familymember and was asked to categorize all items in the list and then to priortize all items in each category. I've never done either of these things to a basic checklist so figured to ask what's the best way to do this so each item in the list once categorized and prioritized doesn't loose its category or priority if the checklist items somehow get out of order for some reason. I could use single level headlines for categories but if the document looses any one of those headlines, the category structure is degraded. If a cannonical emacs-orgmode procedure exists for doing these things and it's already documented I could use an url pointing to the material if anyone knows of one. jude jdash...@shellworld.net
Re: [O] basic checklist getting more complex
Jude DaShiell jdash...@shellworld.net writes: I put together a basic checklist for a familymember and was asked to categorize all items in the list and then to priortize all items in each category. I've never done either of these things to a basic checklist so figured to ask what's the best way to do this so each item in the list once categorized and prioritized doesn't loose its category or priority if the checklist items somehow get out of order for some reason. I could use single level headlines for categories but if the document looses any one of those headlines, the category structure is degraded. If a cannonical emacs-orgmode procedure exists for doing these things and it's already documented I could use an url pointing to the material if anyone knows of one. Mmhh, since you cannot apply tags and proprities to checklist items AFAIK, it seems you already gave the canonical procedure yourself: put the checklists in subtrees with tags (=categories) and further subsubtrees with different priorities (or vice versa). Why would you eliminate the subtrees later, when they are still needed? -- cheers, Thorsten
[O] [WORG] Link in 'org-latex-export.html' does not work.
Hi List, in , | http://orgmode.org/worg/org-tutorials/org-latex-export.html ` line 542 the link to 'org-exp-blocks' does not work: , | Location: http://orgmode.org/worg/contrib/org-exp-blocks | Cannot retrieve URL: http://orgmode.org/worg/contrib/org-exp-blocks | | 404 Not Found ` trailing .html is missing, this works: , | http://orgmode.org/worg/org-contrib/org-exp-blocks.html ` -- cheers, Thorsten
