Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Carsten, Carsten Dominik carsten.domi...@gmail.com writes: Keeping this variable a customize variable invites changes also by people who do not really know what they are doing. Turning it into a defvar or defconst and somewhere document how to hack around the restriction if you really need to sounds like a good solution for me. Agreed. `org-emphasis-regexp-components' is now a defvar. Also, I added `org-emphasis-alist' to the manual. -- Bastien
Re: [O] [Out-of-Thread] Re: [RFC] Org syntax (draft)
Hi Nicolas, Nicolas Goaziou n.goaz...@gmail.com writes: We can also use a very simple and tolerant regexp (e.g. =[^\000]+=), and introduce a syntax to escape markers for fine-grained control. FWIW this looks like the correct approach to me. -- Bastien
Re: [O] Enriched/Org is a colorful Org
From: Carsten Dominik carsten.domi...@gmail.com Date: Fri, 12 Apr 2013 00:49:32 +0200 Cc: emacs-orgmode@gnu.org List emacs-orgmode@gnu.org Overlays should be OK as long as they aren't too many, and as long as you don't move them around too much, particularly in post-command-hook or some such. This explanation sounds to me as if the display engine is building some kind of tree of overlays to find properties changes quickly. Too bad I don't have time to understand this stuff in more detail, it sounds interesting. Just search xdisp.c for overlay, you will see the story quite clearly, I think. There are actually 2 aspects that make display engine's job harder with overlays. One is indeed that finding overlays that cover a given buffer position is not a very efficient operation. The display engine tries to overcome this to some extent by centering the overlay data base around the place in the buffer it is rendering. This is done for every screen line that is being examined by the display code. The other problem is that there's no easy way of finding out which parts of the buffer are being affected by changes in overlays. The consequence of this is that redisplay cannot easily determine whether a given portion of what's on the glass needs to be redrawn when overlays change. The analysis of which part(s) of a window need to be redrawn is at the heart of redisplay optimizations, whereby Emacs tries very hard to reuse the portions of display that are already up to date. Changes in overlays defeat that. Therefore, changing _any_ overlays in a buffer disables most, if not all, redisplay optimizations, meaning that the entire portion of the buffer that is displayed will be completely redrawn each time overlays _anywhere_ in the buffer are changed.
Re: [O] Bug: error enlighting file: [8.0-pre (release_8.0-pre-335-g4c426b-git @ org-loaddefs.el can not be found!)]
Hello, davi...@es.gnu.org (David Arroyo Menéndez) writes: Sometimes file link is enlighted without brackets, for example, file:~/public_html/docu/drupal/pantallazo8.png appears enlighted, This is called a plain link. but exporting the file to html the transformation is not good. I get: div class=figure pimg src=/home/user/public_html/docu/drupal/pantallazo8.png alt=pantallazo8.png//p /div What did you expect instead? Regards, -- Nicolas Goaziou
Re: [O] Enriched/Org is a colorful Org
On 12 apr. 2013, at 08:41, Eli Zaretskii e...@gnu.org wrote: From: Carsten Dominik carsten.domi...@gmail.com Date: Fri, 12 Apr 2013 00:49:32 +0200 Cc: emacs-orgmode@gnu.org List emacs-orgmode@gnu.org Overlays should be OK as long as they aren't too many, and as long as you don't move them around too much, particularly in post-command-hook or some such. This explanation sounds to me as if the display engine is building some kind of tree of overlays to find properties changes quickly. Too bad I don't have time to understand this stuff in more detail, it sounds interesting. Just search xdisp.c for overlay, you will see the story quite clearly, I think. My Sunday pleasure reading project. There are actually 2 aspects that make display engine's job harder with overlays. One is indeed that finding overlays that cover a given buffer position is not a very efficient operation. The display engine tries to overcome this to some extent by centering the overlay data base around the place in the buffer it is rendering. This is done for every screen line that is being examined by the display code. The other problem is that there's no easy way of finding out which parts of the buffer are being affected by changes in overlays. The consequence of this is that redisplay cannot easily determine whether a given portion of what's on the glass needs to be redrawn when overlays change. The analysis of which part(s) of a window need to be redrawn is at the heart of redisplay optimizations, whereby Emacs tries very hard to reuse the portions of display that are already up to date. Changes in overlays defeat that. Therefore, changing _any_ overlays in a buffer disables most, if not all, redisplay optimizations, meaning that the entire portion of the buffer that is displayed will be completely redrawn each time overlays _anywhere_ in the buffer are changed. Wow. OK. I need to think to that, and I will try to take a fresh look at overlay use in Org. So the reason that the combination with hi-line is slow is because hl-line is using post-command-hook to move its overlay, and redisplay of a full window with org-mode is slow because so much stuff is hidden and Emacs makes a full re-evaluation of what needs to be displayed? This makes sense. Thanks for taking the time to get me this far. - Carsten
[O] Latex export of tables
I am using org-mode version 8.0-pre (release_8.0-pre-247-gbc3ccd @
/home/vikas/lisp/org-mode/lisp/).
I have a table generated by a source block in a document that I would
like to export to latex. In the exported tex file, I would like org to
insert a line like the following between \end(tabular} and \end{table}
\begin{minipage}{\textwidth} \tiny Note: Some descriptive text here.
\end{minipage}
Can somebody suggest what I could do to insert this?
I have been playing with something like the following but am not able
to get it right.
#+LATEX: {
#+NAME: table-name-out
#+CAPTION: Average gross value of output and net income from cultivation of
wheat intercropped with rapeseed, by class, Mahatwar (Rupees per acre, 2005-06
prices)
#+attr_latex: :environment tabulary :width 15cm :align l|RRR
#+RESULTS: source_code_name
| A | B | C |
|---+---+---|
| 1 | 1 | 1 |
| 1 | 2 | 3 |
| 2 | 2 | 4 |
#+LATEX: \begin{minipage}{} \tiny Note: Some descriptive text
here.#\end{minipage} }
Vikas
Re: [O] Problems PlantUML
Hi Bastien, problem solved. I used an org-file for testing without any sectioning. Inserting a heading before PlantUML-block everything's fine :-) Thx! Bastien b...@gnu.org writes: Hi Volker, v...@tagebergen.de writes: running Org-mode version 7.8.11 under GNU Emacs 23.4.1 (x86_64-pc-linux-gnu, GTK+ Version 2.24.10) I am stumbling over a problem with babel/plantuml: Exporting a file with simple demo data leads to a png file with error msg @startuml empty description. Evaluating the code block results in a correct diagramm. Where am I wrong? Unless there are other Org 7.8.11 users out there that can help, I suggest upgrading to the current stable version 7.9.4: http://orgmode.org/ http://orgmode.org/org.html#Installation Sorry I cannot help more, best, -- Volker Hess ** v...@tagebergen.de ** +49(0)173/672 4283 www.tagebergen.de * Gießener Str. 69 ** 35460 Staufenberg ** 06406/90277 Universität Siegen ** ZIMT ** 0271/740 2282 volker.h...@uni-siegen.de *
[O] [BUG?] New group tag feature matches too much
Hi,
I was delighted to discover the new group tags feature in 8.0, but I'm
getting strange results trying it out with a sparse tree.
It looks like matching a group tag matches not only the subtags, but
also spuriously matches any tag that *contains* the string of a subtag.
So when I match for the tag 'pop' in the below example, I get not only
Entry 5 which is tagged 'abba', but also Entry 7, tagged
'yabbadabbadoo'. A tag match for 'abba' correctly returns only Entry 5.
Example buffer:
#+TAGS: { a : aa ab } { rock : ac dc } { pop : abba }
* Entry 1 (grouptag) :a:
* Entry 2 (with subtag) :aa:bb:
* Entry 3 (no subtag) :ac:dc:
* Entry 4 (with subtag):bb:ab:dd:
* Entry 5 (no subtag):bb:cc:abba:
* Entry 6 (no subtag, no 'a' character in tags) :bb:dc:bbdb:
* Entry 7 (no subtag, 'abba' sequence in tag) :yabbadabbadoo:
* Some sparse tree results
Doing `C-c / m' with the following tags produces the following results:
- rock :: matches Entry 3 and 6, CORRECT
- a :: spurious match of every Entry except 6, the only one without any tag with
an `a' character, WRONG
- Expected: match Entry 1, 2, 4
- ab :: matches Entry 4, CORRECT
- abba :: matches Entry 5, CORRECT (no spurious match of Entry 7)
- pop :: matches Entry 5 and 7, WRONG (spurious match of Entry 7)
Yours,
Christian
Re: [O] Enriched/Org is a colorful Org
From: Carsten Dominik carsten.domi...@gmail.com Date: Fri, 12 Apr 2013 09:13:47 +0200 Cc: emacs-orgmode@gnu.org Just search xdisp.c for overlay, you will see the story quite clearly, I think. My Sunday pleasure reading project. Good luck, and let me know if you need something explained. The commentary at the beginning of the file might serve as an introduction, although it doesn't really touch the issue at hand. So the reason that the combination with hi-line is slow is because hl-line is using post-command-hook to move its overlay, and redisplay of a full window with org-mode is slow because so much stuff is hidden and Emacs makes a full re-evaluation of what needs to be displayed? Right. If hi-line (or any similar mode) is off, then at least horizontal cursor motion should be fast, because then Emacs knows that nothing changed, and finding the place where to put the cursor on the same line it was before is relatively easy. But even C-n and C-p is quite another story in an Org buffer: Emacs needs to determine where that puts point, and doing so generally means traversing all of the hidden parts of the buffer between the line which was current and the new current line. In a complex Org buffer, that could easily be many thousands of buffer positions. Also, recall that, under line-move-visual, which is nowadays on by default, Emacs moves by _screen_ lines, not by physical lines. So a simple C-n must internally emulate display to find the next line visible on the screen by traversing the buffer one character at a time and taking note of each and every text property and overlay in between, until it finds the buffer position whose screen coordinates are [X,Y+N], where [X,Y] are the coordinates of the previous cursor position and N is the line height in pixels. And this is just to find where point will be; then the screen must actually be redisplayed, which might mean more work, if the new position of point requires scrolling, e.g. if cursor went off the scroll margins or whatever. We only get reasonably fast performance with all this complexity because our machines are incredibly fast. But we are many times on the edge, as the bug I cited and similar ones show.
Re: [O] Enriched/Org is a colorful Org
Carsten Dominik carsten.domi...@gmail.com writes: Thanks for taking the time to get me this far. +1! Thanks Eli, great to learn about the internals of Emacs display engine. The Emacs Lisp manual already contains some directions and warnings, but not so detailed. -- Bastien
Re: [O] [BUG?] New group tag feature matches too much
Hi Christian, Christian Moe m...@christianmoe.com writes: It looks like matching a group tag matches not only the subtags, but also spuriously matches any tag that *contains* the string of a subtag. Thanks for testing this and for this detailed bug report. This is now fixed in master. Glad you like the feature! -- Bastien
Re: [O] Attributes on HTML tables?
Eric Abrahamsen e...@ericabrahamsen.net writes: The first step is probably to research the differences between xhtml and html 5. Well, I would even skip this step and just hack something usable. -- Bastien
Re: [O] [BUG?] New group tag feature matches too much
Bastien writes:
This is now fixed in master.
Tested and confirmed!
Glad you like the feature!
I've been looking forward to it for a while.
As a Drupal taxonomy fan, I think it would be even cooler to get a
multi-level tag tree by nesting groups, e.g.
#+TAGS: { music : { rock : acdc cure } { pop : abba madonna } }
which currently does nothing;
or by chaining them, e.g.
#+TAGS: { rock : acdc cure} {pop: abba madonna} {music : pop rock}
which currently results in this error message:
Invalid regexp: Unmatched ( or \\(
Yours,
Christian
Re: [O] Org-mode outside Org-mode
Samuel Wales samolog...@gmail.com writes: On 4/5/13, Thorsten Jolitz tjol...@gmail.com wrote: that sounds like a different idea. I have heard about programming environments that keep comments and source-code in two different (but sync'd) files to minimize distraction from the source code - maybe a possible use case for your idea? Yes. The purpose for keeping them separate is to have one of them be a complete Org file. If you structure your Emacs Lisp files the 'outshine way', you can convert them into complete Org files fast and easily using 'outorg.el'. Use ,-- | C-u C-c ' `-- from inside the elisp buffer, or ,-- | C-u e `-- in the associated *Navi:my-elisp-file* buffer. Both bindings call '(outorg-edit-as-org optional ARG)' with ARG and thus act on the complete buffer, not only the subtree at point. Therefore, whenever you want to edit text, your Emacs Lisp source code buffer becomes a (complete or partial) Org-mode buffer in a second, while you are in emacs-lisp-mode most of the time when its about editing code - only enhanced with Org-mode's lookfeel by the activation of 'outline-minor-mode' with 'outshine.el' extensions. When its not about whole Org-mode buffers or whole subtrees (with headlines and code-blocks), but just about atomic comment-strings to be edited in Org-mode buffers, then 'poporg.el' is the tool of choice. -- cheers, Thorsten
Re: [O] Enriched/Org is a colorful Org
On 12 apr. 2013, at 10:31, Eli Zaretskii e...@gnu.org wrote: From: Carsten Dominik carsten.domi...@gmail.com Date: Fri, 12 Apr 2013 09:13:47 +0200 Cc: emacs-orgmode@gnu.org Just search xdisp.c for overlay, you will see the story quite clearly, I think. My Sunday pleasure reading project. Good luck, and let me know if you need something explained. The commentary at the beginning of the file might serve as an introduction, although it doesn't really touch the issue at hand. So the reason that the combination with hi-line is slow is because hl-line is using post-command-hook to move its overlay, and redisplay of a full window with org-mode is slow because so much stuff is hidden and Emacs makes a full re-evaluation of what needs to be displayed? Right. If hi-line (or any similar mode) is off, then at least horizontal cursor motion should be fast, because then Emacs knows that nothing changed, and finding the place where to put the cursor on the same line it was before is relatively easy. But even C-n and C-p is quite another story in an Org buffer: Emacs needs to determine where that puts point, and doing so generally means traversing all of the hidden parts of the buffer between the line which was current and the new current line. In a complex Org buffer, that could easily be many thousands of buffer positions. I guess outline mode does have the exact same problem in this case, in fact any mode with large amount of hidden text. Also, recall that, under line-move-visual, which is nowadays on by default, Not in my setup, but since it the default, yes, this causes more issues. Another important point to be aware of. Emacs moves by _screen_ lines, not by physical lines. So a simple C-n must internally emulate display to find the next line visible on the screen by traversing the buffer one character at a time and taking note of each and every text property and overlay in between, until it finds the buffer position whose screen coordinates are [X,Y+N], where [X,Y] are the coordinates of the previous cursor position and N is the line height in pixels. And this is just to find where point will be; then the screen must actually be redisplayed, which might mean more work, if the new position of point requires scrolling, e.g. if cursor went off the scroll margins or whatever. We only get reasonably fast performance with all this complexity because our machines are incredibly fast. But we are many times on the edge, as the bug I cited and similar ones show. Thanks again. - Carsten
Re: [O] [BUG?] New group tag feature matches too much
Hi Christian,
Christian Moe m...@christianmoe.com writes:
As a Drupal taxonomy fan, I think it would be even cooler to get a
multi-level tag tree by nesting groups, e.g.
#+TAGS: { music : { rock : acdc cure } { pop : abba madonna } }
which currently does nothing;
Well, let's first see how useful is the current feature.
or by chaining them, e.g.
#+TAGS: { rock : acdc cure} {pop: abba madonna} {music : pop rock}
which currently results in this error message:
Invalid regexp: Unmatched ( or \\(
Your #+TAGS line does not match the correct syntax.
#+TAGS: {rock : acdc cure} {pop : abba madonna} {music : pop rock}
^^^
HTH,
--
Bastien
Re: [O] Enriched/Org is a colorful Org
Hi, just want to add some observation. I guess it has nothing to do with the display engine but it might be somehow related. I used to use line-mode to display line-numbers as a left column on all my buffers. I noticed a very painful slowdown up to a totally unusable state during working on very large org-files. It consisted of coursework for a programming class and contained single headers with the student-id numbers and a babel-code block in the headers body (hence, easily goes into 1000th of lines). I was happy with it since I could execute and proof each submitted coursework within a single org-file and folding helped me to move quickly from one to the other coursework. However, as longer as the list get as more it slowed down. After some fiddling and searching, I noticed that the line-mode was kind of struggling with the org-mode text-collapse feature. Whenever, I closed a header, it took large amount of times to recalculate the line-numbers. Not sure where exactly line-mode did consume the time. But it might as well be related to the redisplaying of the numbers. Switching off the line-mode made the time delay disappear completely. Just an observation which might or might not related to the later discussion. Torsten On 12 April 2013 12:56, Carsten Dominik carsten.domi...@gmail.com wrote: On 12 apr. 2013, at 10:31, Eli Zaretskii e...@gnu.org wrote: From: Carsten Dominik carsten.domi...@gmail.com Date: Fri, 12 Apr 2013 09:13:47 +0200 Cc: emacs-orgmode@gnu.org Just search xdisp.c for overlay, you will see the story quite clearly, I think. My Sunday pleasure reading project. Good luck, and let me know if you need something explained. The commentary at the beginning of the file might serve as an introduction, although it doesn't really touch the issue at hand. So the reason that the combination with hi-line is slow is because hl-line is using post-command-hook to move its overlay, and redisplay of a full window with org-mode is slow because so much stuff is hidden and Emacs makes a full re-evaluation of what needs to be displayed? Right. If hi-line (or any similar mode) is off, then at least horizontal cursor motion should be fast, because then Emacs knows that nothing changed, and finding the place where to put the cursor on the same line it was before is relatively easy. But even C-n and C-p is quite another story in an Org buffer: Emacs needs to determine where that puts point, and doing so generally means traversing all of the hidden parts of the buffer between the line which was current and the new current line. In a complex Org buffer, that could easily be many thousands of buffer positions. I guess outline mode does have the exact same problem in this case, in fact any mode with large amount of hidden text. Also, recall that, under line-move-visual, which is nowadays on by default, Not in my setup, but since it the default, yes, this causes more issues. Another important point to be aware of. Emacs moves by _screen_ lines, not by physical lines. So a simple C-n must internally emulate display to find the next line visible on the screen by traversing the buffer one character at a time and taking note of each and every text property and overlay in between, until it finds the buffer position whose screen coordinates are [X,Y+N], where [X,Y] are the coordinates of the previous cursor position and N is the line height in pixels. And this is just to find where point will be; then the screen must actually be redisplayed, which might mean more work, if the new position of point requires scrolling, e.g. if cursor went off the scroll margins or whatever. We only get reasonably fast performance with all this complexity because our machines are incredibly fast. But we are many times on the edge, as the bug I cited and similar ones show. Thanks again. - Carsten
Re: [O] Enriched/Org is a colorful Org
From: Carsten Dominik carsten.domi...@gmail.com Date: Fri, 12 Apr 2013 12:56:11 +0200 Cc: emacs-orgmode@gnu.org I guess outline mode does have the exact same problem in this case, in fact any mode with large amount of hidden text. Of course. The only difference is that outline is not as popular as Org, and usually is used with relatively short chunks of text. But the problems are exactly the same.
[O] #attr_latex :width \textwidth
This does not work for me with the new exporter: #attr_latex :width \textwidth Is there another way to do it? Vikas
Re: [O] #attr_latex :width \textwidth
On Apr 12, 2013 7:52 AM, Vikas Rawal vikasli...@agrarianresearch.org wrote: This does not work for me with the new exporter: #attr_latex :width \textwidth If this was copied and pasted you're missing a colon. I do that all the time :) #+attr_latex: :width John Is there another way to do it? Vikas
Re: [O] Enriched/Org is a colorful Org
Date: Fri, 12 Apr 2013 13:49:47 +0200 From: Torsten Wagner torsten.wag...@gmail.com Cc: Eli Zaretskii e...@gnu.org, Org Mode Mailing List emacs-orgmode@gnu.org just want to add some observation. I guess it has nothing to do with the display engine but it might be somehow related. I used to use line-mode to display line-numbers as a left column on all my buffers. I noticed a very painful slowdown up to a totally unusable state during working on very large org-files. It consisted of coursework for a programming class and contained single headers with the student-id numbers and a babel-code block in the headers body (hence, easily goes into 1000th of lines). I was happy with it since I could execute and proof each submitted coursework within a single org-file and folding helped me to move quickly from one to the other coursework. However, as longer as the list get as more it slowed down. After some fiddling and searching, I noticed that the line-mode was kind of struggling with the org-mode text-collapse feature. Whenever, I closed a header, it took large amount of times to recalculate the line-numbers. Not sure where exactly line-mode did consume the time. But it might as well be related to the redisplaying of the numbers. Switching off the line-mode made the time delay disappear completely. So this was an Org file with only 1 level of headers, but with large blocks of text between the headers, is that right? Can you show an example of such babel-code block? I'd like to look into the slowdown and find its reasons. In general, linum does exactly what defeats redisplay optimizations: it modifies overlays in a post-command-hook. But that doesn't mean this was the reason for the slow operation you saw, it could be something else. If you can easily produce a recipe for recreating the problem, it might be worthwhile to file an Emacs bug report. Thanks.
Re: [O] [BUG?] New group tag feature matches too much
Hi,
Bastien writes:
As a Drupal taxonomy fan, I think it would be even cooler to get a
multi-level tag tree by nesting groups
Well, let's first see how useful is the current feature.
Fair enough.
Your #+TAGS line does not match the correct syntax.
#+TAGS: {rock : acdc cure} {pop : abba madonna} {music : pop rock}
^^^
Right, thanks. I take it that there have to be spaces around the curly
braces too, since the above doesn't work either, but
#+TAGS: { rock : acdc cure } { pop : abba madonna }
^^^^^^
works fine.
Out of curiosity, I tried the chaining experiment again with
#+TAGS: { rock : acdc cure } { pop : abba madonna } { music : pop rock }
and matching for tag music gives the same error message:
Invalid regexp: Unmatched ( or \\(
But that's OK, really, since nested tag groups weren't supposed to work
anyway.
Yours,
Christian
Re: [O] More generic taskjuggler export proposal
Hi Buddy Buddy Butterfly buddy.butter...@web.de writes: I would like propose the following for taskjuggler export as base for a discussion to change export functionality. Thanks for your detailed proposal. It's been a few years since I wrote the taskjuggler exporter and I don't remember all the design decisions. Your idea with the prefix to the attributes is an interesting one. However, the fundamental problem here is that IMHO there is no one-to-one mapping between all the concepts in taskjuggler and org-mode. Fundamentally taskjuggler is a system to plan and track a multi-resource project. I see org-mode more geared towards planing and tracking a single user. Taskjuggler has the concept of scenarios where you can compare a plan against another plan or an actual execution (based on reported effort). This might be doable in org-mode but is not really a natural thing to do. So in essence what I'm trying to say is that the goal behind the taskjuggler exporter was never to give you a complete taskjuggler development environment. For that you are probably better of just editing the tjp files directly. Instead the goal was to let the user take their normal org-mode files and have them export to taskjuggler with minimal changes (i.e. mark the tasks, efforts and the resources). The same holds for the dependency system. As far as I remember it was an explicit decision not to support the taskjuggler dependency system and use the one provided by org-mod instead. I think taskjuggler's dependency system is very low level. The one provided by org-mode fit my use cases (for the occasional dependency) much better (and have support for higher level concepts such as the ORDERED or previous-sibling attribute). The dependency between tasks is one thing that should be supported by org. I do not know what would be the best solution here. Maybe we could get a completion list for the values when adding :tj_depends: properties. I don't quite understand this part of your message. As I said above I think the support for dependencies in the taskjuggler is IMHO quite nice :-). Here I would suggest that one can place this data inbetween #+BEGIN_TASKJUGGLER #+END_TASKJUGGLER This is something I'd like to add support for. I just never got around to look at how this could be implemented. It has some implications as you could destroy your otherwise valid tjp file. But it might cover some of your use cases above. Do you know how this could be done in the new exporter? I still would like to discuss the organisation with multiple projects. What do you think about it? Are you referring to the problem of handling multiple projects and similar resources? I have never done this. How do you do it in plain taskjuggler? Thanks Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
Re: [O] Best way to generate textile from orgmode ?
Bastien b...@gnu.org writes: Hi Marc-Oliver, Marc-Oliver Ihm m...@ihm.name writes: i would like to convert orgmode to textile (which is used within confluence wiki). What is the best way to do this ? The best way would be to write a textile exporter. I agree that this would be for the benefit of everyone. But you could also just export to md and use pandoc to convert to textile. Christian -- Christian Egli Swiss Library for the Blind, Visually Impaired and Print Disabled Grubenstrasse 12, CH-8045 Zürich, Switzerland
[O] Bug: Infinite loop during navigation in master [8.0-pre (release_8.0-pre-386-g90dfd3 @ /home/bernt/git/org-mode/lisp/)]
With the following org file , | | | ** TODO Project | *** TODO One | *** DONE Two | *** DONE Three | *** TODO Four | | ` C-c / t folds the buffer to , | ** TODO Project | *** TODO One | *** DONE Two... | *** TODO Four... ` If you put point on the DONE Two task and C-c C-f to move forward emacs hangs (you can break out with C-g) Let me know if you need anymore details. This occurs both on windows and linux. I'm running org uncompiled. Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.1) of 2013-01-08 on murphy, modified by Debian Package: Org-mode version 8.0-pre (release_8.0-pre-386-g90dfd3 @ /home/bernt/git/org-mode/lisp/) Regards, Bernt
Re: [O] Attributes on HTML tables?
Bastien b...@gnu.org writes: Eric Abrahamsen e...@ericabrahamsen.net writes: The first step is probably to research the differences between xhtml and html 5. Well, I would even skip this step and just hack something usable. There are validators out there, that could help us staying on track, whatever the track :-). François
Re: [O] Enriched/Org is a colorful Org
Bastien b...@gnu.org writes: Thanks Eli, great to learn about the internals of Emacs display engine. Eli is, and always has been, quite a resourceful man. And along the years, I got the pleasure of discovering him as a good friend too! :-) François
Re: [O] Bug: Infinite loop during navigation in master [8.0-pre (release_8.0-pre-386-g90dfd3 @ /home/bernt/git/org-mode/lisp/)]
Bernt Hansen be...@norang.ca writes: If you put point on the DONE Two task and C-c C-f to move forward emacs hangs (you can break out with C-g) Fixed, thanks! -- Bastien
Re: [O] blank todo kw does not delete closed ts
Hi Samuel, I'm convinved now, and switching to state without any TODO keyword will now remove the CLOSED planning information. Thanks, -- Bastien
Re: [O] [BUG] org-clock-in menu scrolls off the top of the window
Bernt Hansen be...@norang.ca writes: I don't like the additional timestamp information. It is now removed. -- Bastien
Re: [O] adding images in org
Nick Dokos n...@dokosmarshall.org writes: I don't think you can inline remote images. The post you link to refers only to locally available images. Nick Hmm, then is there any method in Org to auto-download the image, and then inline it? Or in other words, do attachments have to be locally available, or will a URL work to attach something? Dave
Re: [O] adding images in org
Hi David, da...@adboyd.com (J. David Boyd) writes: Hmm, then is there any method in Org to auto-download the image, and then inline it? No. Or in other words, do attachments have to be locally available, or will a URL work to attach something? The former. HTH, -- Bastien
Re: [O] [BUG?] New group tag feature matches too much
Christian Moe m...@christianmoe.com writes:
Right, thanks. I take it that there have to be spaces around the curly
braces too, since the above doesn't work either, but
#+TAGS: { rock : acdc cure } { pop : abba madonna }
^^^^^^
works fine.
Out of curiosity, I tried the chaining experiment again with
#+TAGS: { rock : acdc cure } { pop : abba madonna } { music : pop rock }
and matching for tag music gives the same error message:
Invalid regexp: Unmatched ( or \\(
But that's OK, really, since nested tag groups weren't supposed to work
anyway.
Well, the error was not really informative. There is no error now.
I mention group tags limitations in the manual: no nested groups, and
no group tag within another group tag definition.
Thanks again for testing this,
--
Bastien
Re: [O] publishing css using babel + sass and (new) exporter
On Tue, Apr 09, 2013 at 07:20:56PM -0400, Jean Schurger wrote:
Hi,
I'm a new and innocent org-mode user, and I would like to use
org-mode exporter (the new one) to publish static web pages.
The 'html' part is OK, but as I hate writing CSS, I'm using babel + sass
to build CSS code.
For example:
#+BEGIN_SRC sass exports: results
body
background: black
#+END_SRC
#+RESULTS:
: body {
: background: black; }
That's perfect !
My question now:
How should i configure my project-alist entry to publish resultant CSS
code.
I would do something like the following:
#+BEGIN_SRC sass :exports none :results file :file sass.css
body
background: black
#+END_SRC
and then add a static rule for css files to your publishing
function. That way you can embed the css into the same file as the
org file to be converted to html
rick
Re: [O] Enriched/Org is a colorful Org
Hi Eli, I hope you don't mind me taking this opportunity to ask a tangential question. On Fri, Apr 12, 2013 at 04:03:10PM +0300, Eli Zaretskii wrote: In general, linum does exactly what defeats redisplay optimizations: it modifies overlays in a post-command-hook. But that doesn't mean If some package wants to keep something updated (line number displays in this case), is using the post-command-hook the only option? -- Suvayu Open source is the future. It sets us free.
Re: [O] Enriched/Org is a colorful Org
Date: Fri, 12 Apr 2013 20:00:56 +0200 From: Suvayu Ali fatkasuvayu+li...@gmail.com Cc: Torsten Wagner torsten.wag...@gmail.com, emacs-orgmode@gnu.org, carsten.domi...@gmail.com If some package wants to keep something updated (line number displays in this case), is using the post-command-hook the only option? No. The other one is piggy-back jit-lock. See nlinum in ELPA for an example, which actually is a drop-in replacement for linum, but without many of its problems.
Re: [O] Best way to generate textile from orgmode ?
Hm; good reply. I will try ... best regards, Marc Am 12.04.2013 15:09, schrieb Christian Egli: Bastien b...@gnu.org writes: Hi Marc-Oliver, Marc-Oliver Ihm m...@ihm.name writes: i would like to convert orgmode to textile (which is used within confluence wiki). What is the best way to do this ? The best way would be to write a textile exporter. I agree that this would be for the benefit of everyone. But you could also just export to md and use pandoc to convert to textile. Christian
Re: [O] [BUG] org-clock-in menu scrolls off the top of the window
Sebastien Vauban wxhgmqzgwmuf-genee64ty+gs+fvcfc7...@public.gmane.org writes: If there is a default, and current task (all the same) then [d], [c], and [1] will all be identical. The default task is only displayed when a default clocking task is identified (which is always for me). [c] may not be that useful to display since we can just quit and leave the clock alone. Personally I like the duplication in the history list (it's a true view of what was clocked in recently) Personally, I would find it clearer to see every task at most once, be it as default, interrupted or in the list. So, the interrupted task wouldn't be duplicated in the list. But I can understand that this is a question of taste. Something which is not a question of taste, IMHO, is that items are sometimes duplicated within the 1..N list: I have, for example, Recent Tasks [1] Read emails [2] Organize work [3] Organize work [4] Prepare meeting Items 2 and 3 are the same one -- I don't have Organize work duplicated within my agenda files. I don't understand why it's duped in there. Ever observed this as well? The main thing I'm reporting is all the whitespace now at the bottom of the screen since the list is artificially scrolled up. I used to be able to determine exactly what fit in the list so I set my history length appropriately. I know that item duplication is a side-question, but it does consume real screen estate... Hi Seb, I'm fine with removing duplicates in the 1-N list. Regards, Bernt
Re: [O] minor bug in babel with silent output and remote R session
Bastien b...@gnu.org writes: Hi Thomas, thanks for the follow-up. Thomas Alexander Gerds t...@biostat.ku.dk writes: I think that I can describe the problem a bit better now. It is not related to the silent option but occurs whenever :results value. Emacs freezes due to the following line in org-babel-comint-eval-invisibly-and-wait-for-file (while (not (file-exists-p file)) (sit-for (or period 0.25))) it seems that R cannot transfer the file and hence this is an endless loop. I'm not knowledgeable enough in this area to provide a fix, maybe someone else will. Could this be a problem with whatever tool (I'm assuming ESS) you are using to maintain the R session and generate the R file? Perhaps babel needs to modify the R code used to create the file (held in the `org-babel-R-write-object-command' variable). Could you take a shot at providing another version of this variable? I don't really use R myself. Thanks, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Specified colnames
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric, Eric Schulte wrote: Extra question: tested with a sh block, both of the above do work, that is with strings or symbols. Which one is supposed to be better (that is, will be more portable with time), if there is one? Both will be maintained. The contribution of a test exercising both options could provide an extra guarantee of perseverance. This is also a good first step towards editing the code. :) Here's my trial to do so. --8---cut here---start-8--- (ert-deftest test-ob/specific-column-names-symbols () Test passing specific column names as a list of symbols. (should (equal #+name: input-table | id | var1 | |+--| | 1 | bar | | 2 | baz | #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) echo \$data\ #+end_src #+results: | Rev | Author | |-+| | 1 | bar| | 2 | baz| (org-test-with-temp-text #+name: input-table | id | var1 | |+--| | 1 | bar | | 2 | baz | #+begin_src sh :var data=input-table :exports results :colnames '(Rev Author) echo \$data\ #+end_src (org-babel-execute-src-block) (buffer-string) --8---cut here---end---8--- Does this correspond to what you're asking for? Close, could you prepare this as a patch against the current code base? That way I can simply apply it locally and more easily test it. However, running it did not succeed. I must do something wrong, or NOT do something good... ╭ │ Selector: t │ Passed: 0 │ Failed: 0 │ Total: 0/1 │ │ Started at: 2013-04-08 22:45:19+0200 │ Aborted. │ Aborted at: 2013-04-08 22:45:19+0200 │ │ A │ │ A test-ob/specific-column-names-symbols │ Test passing specific column names as a list of symbols. │ aborted ╰ The worse is that I don't get a backtrace, even after: - setting debug-on-error to t, or - M-x'ing toggle-debug-on-error. Weird, but not the first time -- seems related to Emacs 24.2 or so (+ my config?). Integration these tests with the existing tests should help to illuminate whatever is causing these failures. Assuming that the existing tests are passing on your system that is. Cheers, Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Much clearer, but not yet crystal-clear for me... Let me explain. AFAICT, there were 5 possibles values of the :colnames header argument: - no header argument :: (default for all languages but Emacs Lisp) - :colnames no :: (default for Emacs Lisp code blocks) - :colnames yes :: Tells Org Babel that your first row contains column names. - :colnames LIST :: Specifies to use LIST as column names. - :colnames nil :: Same as :colnames yes. Right? Almost, values 1 (none) and 5 (nil) are the same. I don't share your view about this last statement. ** Input table #+name: unset-colnames-example-input | a | b | |---+---| | 1 | 2 | | 3 | 4 | ** Having no =:colnames= header argument (case 1) Same results for R and sh code blocks (first good news ;-)) -- I'm avoiding, on purpose, testing with Emacs Lisp... #+begin_src R :var data=unset-colnames-example-input data #+end_src #+results: | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=unset-colnames-example-input echo $data #+end_src #+results: | 1 | 2 | | 3 | 4 | Looks good. ** Using =:colnames nil= header argument (case 5) Once again, R and sh blocks do produce the same results... #+begin_src R :var data=unset-colnames-example-input :colnames nil data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=unset-colnames-example-input :colnames nil echo $data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | ... but they are _not_ equivalent to the no header argument (case 1). As I believe I mentioned nil on a header argument is not interpreted as the lisp literal `nil'. To pass an empty argument to a code block you should do :colnames '(), an obscure syntax for an obscure thing. ** Using =:colnames yes= header argument (case 3) On the contrary, case 5 is equivalent to the case 3: same results as :colnames yes. #+begin_src R :var data=unset-colnames-example-input :colnames yes data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | #+begin_src sh :var data=unset-colnames-example-input :colnames yes echo $data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Because the nil you specified above is just treated as a string. You get the same thing with. #+begin_src sh :var data=unset-colnames-example-input :colnames sure echo $data #+end_src #+RESULTS: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Bugs for Emacs Lisp code blocks
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Emacs Lisp is an exception in terms of colname processing, it has default header arguments set to pass column names through to the code block, where the processing may be done trivially in Emacs Lisp. OK, but I don't understand the precedence of header arguments. I thought that a header argument given on the code block preempted all the other values (system-wide default for all languages, language defaults, file-wide arguments, and subtree arguments). Why isn't this true here as well? That is what is happening here, although combinations of :hlines and :colnames can be tricky. Especially weird, is that if you want to *unset* a header argument which is set at a higher level, you need to set it to '(), as in :colnames '(). #+name: unset-colnames-example-input | a | b | |---+---| | 1 | 2 | | 3 | 4 | I thought you said you weren't going to try this with Emacs Lisp. :) ** Having no =:colnames= header argument (case 1) I understand that the following example does have =:colnames= set to =yes=: it is neither unset nor changed on the code block specification. #+begin_src emacs-lisp :var data=unset-colnames-example-input data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Hence, this result is what is expected. ** Using =:colnames no= header argument (case 2) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, I still don't understand why I do see the table header line: I did change the default =:colnames yes= specification to =:colnames no= on the code block. I did override the default value. Why is the =no= argument not respected? Because 'hlines is set to yes by default in `org-babel-default-header-args:emacs-lisp'. ** Using =:colnames yes= header argument (case 3) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames yes data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, the =:colnames yes= specification is simply redundant to what's specified for the emacs-lisp language. In all cases, the results is what is should be. agreed ** Using =:colnames nil= header argument (case 5) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames nil data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | As written in my previous post, =:colnames nil= is equivalent to =:colnames yes= in Emacs Lisp, R and sh code blocks -- at least. answered in my previous reply. (Still) not clear to me -- sorry to be stubborn. ** Using =:colnames ()= header argument (case 6) As you told me, to unset the =:colnames yes= header argument, we must use: #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames () data #+end_src #+results: | 1 | 2 | | 3 | 4 | That does work. Yes, this answers your question immediately above. ** Using =:colnames ()= header argument (case 7) So does the quoted empty list version... #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames '() data #+end_src #+results: | 1 | 2 | | 3 | 4 | What is still unclear to me as well, is why =()= and =nil= aren't the same from Babel's point of view? Look in the manual at the description of what causes header arguments to be interpreted as Emacs Lisp. Cheers, Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] org-babel: two confirmations for org/HTML macro?
Bastien b...@gnu.org writes: Hi Achim, Achim Gratz strom...@nexgo.de writes: Bastien writes: (Sorry, I pushed a fix for the compiler warning that your patch also solves.) Not in master, though? Yes -- pushed this morning. Achim Gratz strom...@nexgo.de writes: Since the test suite doesn't really test confirmation at all, it would be nice if someone with a good variety of Babel calls could check if the number of confirmations stay the same with and without the patch. I don't think I have test cases that cover all possible combinations. Please let's go and apply this, that's the best way to have more people testing it. Thanks! Please wait for Eric to chime in. All right. Copying Eric for the heads-up. After walking through this patch, it looks like it provides exactly the correct behavior. Please go ahead and apply these changes. Thanks Achim for the patch! -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Bugs for Emacs Lisp code blocks
** Using =:colnames no= header argument (case 2) #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames no data #+end_src #+results: | a | b | |---+---| | 1 | 2 | | 3 | 4 | Here, I still don't understand why I do see the table header line: I did change the default =:colnames yes= specification to =:colnames no= on the code block. I did override the default value. Why is the =no= argument not respected? This still escapes me. Answered in my previous reply. ** Using =:colnames ()= header argument (case 6) As you told me, to unset the =:colnames yes= header argument, we must use: #+begin_src emacs-lisp :var data=unset-colnames-example-input :colnames () data #+end_src #+results: | 1 | 2 | | 3 | 4 | That does work. What is still unclear to me as well, is why =()= and =nil= aren't the same from Babel's point of view? However, I think I understood this one: it is because nil is interpreted as a string, not as the empty list; right? That's because strings aren't quoted, right? Yes. Cheers, Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] converting people to Emacs and org-mode
Last fall I wrote a very simple elnode based web server which allows for Org-mode files to be viewed and edited through a web browser. http://thread.gmane.org/gmane.emacs.orgmode/58773/focus=61752 It seems relevant to this discussion. I haven't touched the code in some time, so it may need to be updated to work with a current Org-mode (although it did use the new exporter). I've had a version running on my home server continuously since the fall, and find it is the only way I can get non-Emacs people to edit Org-mode files. Cheers, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Christopher, Christopher Allan Webber wrote: Eric Abrahamsen writes: Russell Adams rlad...@adamsinfoserv.com writes: My experience has been that after watching me manage a project in Org for a few weeks, I have customers beg me to help them install it on their PC. I've had quite a few converts through working together and by example. Perhaps the web incarnations of org could help here too. Say the manager of a small group project were able to create a web-version of an agenda, and project members could filter that by clicking on javascript-enabled versions of tags corresponding to their TODOs, and even click the TODOs to change state, that could be a nice introduction to project management in Org. It might require too much org functionality to be re-written in javascript though? Dunno. I think a web application that allowed for orgmode-as-a-group-todo-management-system thing would be huge. It would require a lot of thinking of how to approach it in a way that would be nice and make sense. I'm not really sure what it would look like. But hook that up to git and you'd have a really interesting bug tracking system. I guess it should be in the spirit of configurable organizers like the TiddlyWiki based GTD systems (see http://www.tiddlywiki.com/): - MPTW (MonkeyPirateTiddlyWiki) :: http://mptw.tiddlyspot.com/ - mGSD :: http://mgsd.tiddlyspot.com/demo3.html and http://thinkcreatesolve.biz/mGSDEnhancements.html - D-cubed - tbGTD :: http://tbgtd.tiddlyspot.com/ That is the killer brother application for Org, for sure. There was that relevant GSoC project, but I'd be interested in this happening in python or similar. Now that we have the standard for orgmode as a file format... Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] Drop `:results code'?
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hello, Shouldn't we, for the sake of simplifying the multiple options, drop the support for `:results code'? It is completely redundant (though, less powerful) with `:wrap'. I have no problem with that. Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Web site generator, but not so static
Fabrice Popineau fabrice.popin...@supelec.fr writes: I'm considering waht most benefit could be drawn from coupling org-mode to write web pages (skeletons) and hunchentoot (common lisp web server). There used to be some starter for a CL Org-mode parser, but it seems to be dead by now. There are several ways in which the pair could make sense. For example by using slime to feed directly data to the server. Also by the fact that org-mode in emacs could easily spit out sexp rather than html. Did anybody look into this ? If an Emacs-Lisp web server would work, maybe this could be of use. https://github.com/eschulte/org-ehtml -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] [babel] sbe not working properly
Christian Moe m...@christianmoe.com writes:
Hi,
I cannot replicate Karl's problem. I copied the code examples, and got
the right results on Org 8.0-pre (pulled this morning).
I did have to make one change -- Babel wouldn't recognize the variables
until I passed them with :var rather than in parens after the codeblock
name. (I saw there was some discussion on dropping the latter syntax;
whoa -- has it already happened?)
Yes, this syntax has been removed.
But that much was clear from the error messages I got, so Karl's
problem must be something different.
Yours,
Christian
Darlan Cavalcante Moreira writes:
I have my own difficulties using sbe and decided to try your example.
I even created the shell babel block below which does the same think as the
python code
#+NAME: epoch2dayshell(epoch=1)
#+begin_src sh
echo `date --d @$epoch -u +[%F %a %T]`
#+end_src
but I got the same result. Actually, I realize a small detail.
In your example, when you evaluated the table formula you got as result the
1970 date. However, this does not mean that your python code was
executed. You got that answer because you have evaluated the python code
previously with the default argument (equal to 1) and thus you had
#+RESULTS: epoch2day
: [1970-01-01 Thu 00:00:01]
in your file. If you erase the #+RESULTS and reevaluate the table you will
get an ERROR. That indicates that sbe is not calling the babel block as I
(and probably you too) was expecting.
However, looking at sbe's documentation I can't see anything wrong with the
formula you wrote. I'm still confused on how to correctly use sbe.
--
Darlan
At Thu, 11 Apr 2013 16:26:12 +0200,
Karl Voit wrote:
Hi!
I want to define a babel function named epoch2day which I am able to use in
a
table to convert UNIX epoch times to Org-mode time stamps:
#+NAME: epoch2day(epoch=1)
#+BEGIN_SRC python :results output
time = epoch
import datetime
strtime = str(time)
datetimestamp =
datetime.datetime.utcfromtimestamp(int(strtime[:10]))
print datetimestamp.strftime('[%Y-%m-%d %a %H:%M:%S]')
#+END_SRC
#+RESULTS: epoch2day
: [1970-01-01 Thu 00:00:01]
... this works so far. However, in a table I can't overwrite the default
value with a column value:
| epoch | day |
|---+---|
| 1262675465119 | [1970-01-01 Thu 00:00:01] |
#+TBLFM: $2='(sbe epoch2day (epoch $1))
... but $2 should be: [2010-01-05 Tue 07:11:05]
On [1] I found another example:
#+name: add1(x=1) :results silent
#+begin_src python
return x + 1
#+end_src
#+RESULTS: add1
: 2
| foo | bar | 3 | 2 |
#+TBLFM: @1$4='(sbe add1 (x $3))
#+CALL: add1(x=2)
#+RESULTS: add1(x=2)
: 2
So this simple example does not work either at my side[2].
What is my error? Or did I found a bug?
Thanks!
1. http://stackoverflow.com/questions/9595310/org-babel-sbe-syntax
2. Org-mode 1af215bb4668bf3e778175e68fcaf from git
--
mail|git|SVN|photos|postings|SMS|phonecalls|RSS|CSV|XML to Org-mode:
get Memacs from https://github.com/novoid/Memacs
https://github.com/novoid/extract_pdf_annotations_to_orgmode + more on
github
--
Eric Schulte
http://cs.unm.edu/~eschulte
Re: [O] Error with :wrap org in babel and 8.0-pre
John Hendy jw.he...@gmail.com writes:
I thought this was the proper syntax for printing stuff directly to a
LaTeX document:
#+begin_src R :session :exports results :results output :wrap org
I think you want either :results latex or :wrap latex.
Cheers,
I've got a statement interspersing some prose with variable values like so:
cat(This and such value was, var1, , and this one was, var2, .\n)
The results block looks fine, but LaTeX is spitting out \begin{org}
and \end{org} around it, which results in a compilation error:
! LaTeX Error: Environment org undefined.
See the LaTeX manual or LaTeX Companion for explanation.
Type H return for immediate help.
...
l.51 \begin{org}
! LaTeX Error: \begin{document} ended by \end{org}.
Suggestions?
Thanks,
John
--
Eric Schulte
http://cs.unm.edu/~eschulte
[O] [PATCH] Change relative weekday specifications (ex: fri or -tue) to exclude today
I use the weekday specifiers for org-read-date a lot when scheduling tasks. For example, I frequently use things like +sat - the + isn't needed for this, but I still do it out of habit (sat works just as well). Sometimes I want to postpone tasks to the same day next week. I think of fri as the next upcoming Friday, so I tend to use that to postpone things. Then I get thoroughly confused, because it ends up on the same day, and then I grumble and reschedule it to either 2fri or +w. You see, if today is Friday, fri gets you today, even if org-read-date-prefer-future is true. It's the correct behaviour according to the documentation, but it was driving me a little crazy, so I propose the attached change. It makes fri and -fri exclude today, so if today is Friday, fri means next Friday (procrastinate away!) and -fri means last Friday. What do people think? 0001-Change-relative-weekday-specifications-ex-fri-or-tue.patch Description: Binary data
Re: [O] [PATCH] Change relative weekday specifications (ex: fri or -tue) to exclude today
Hi Sacha, Sacha Chua sa...@sachachua.com writes: What do people think? I love it. It's neat and efficient. You even managed to get the patch short enough so that it's a TINYCHANGE. Applied, thanks! -- Bastien
[O] org.texi:8719 Error
org-version: 8.0-pre (release_8.0-pre-416-gbf338e) makeinfo --no-split org.texi -o org org.texi:8719: No closing brace for footnote `'. org.texi:8719: Unmatched }. makeinfo: Removing output file `org' due to errors; use --force to preserve. make[1]: *** [org] Error 1 make[1]: Leaving directory `/home/feng/project/org-mode/doc' make: *** [info] Error 2 --
[O] [Help] How to apply a function to all head of buffer
I need a function apply all the head of a org buffer,I know it will use loop ,but I don't know the details --
Re: [O] #attr_latex :width \textwidth
Sorry, I meant: #+attr_latex :width \textwidth Vikas
Re: [O] [Help] How to apply a function to all head of buffer
Feng Shu tuma...@gmail.com writes: I need a function apply all the head of a org buffer,I know it will use loop ,but I don't know the details Hi Feng Shu, You probably want `org-map-entries', check the docstring, it's pretty helpful. Yours, Eric
Re: [O] [Help] How to apply a function to all head of buffer
Thanks Eric ! --
Re: [O] Attributes on HTML tables?
François Pinard pin...@iro.umontreal.ca writes: Bastien b...@gnu.org writes: Eric Abrahamsen e...@ericabrahamsen.net writes: The first step is probably to research the differences between xhtml and html 5. Well, I would even skip this step and just hack something usable. Okay, I've got a nearly-working patch for this, but I'm falling down hard on the defcustom. Here's what I thought to do: #+BEGIN_SRC emacs-lisp (defconst org-html-doctype-alist '((html4 . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\) (html4-strict . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\ \http://www.w3.org/TR/html4/strict.dtd\;) (xhtml . !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;) (html5 . !DOCTYPE HTML)) An alist mapping (x)html flavors to specific doctypes.) (defcustom org-html-doctype 'xhtml Document type definition to use for exported HTML files. Can be set with the in-buffer HTML_DOCTYPE property or for publishing, with :html-doctype. :group 'org-export-html :version 24.4 :package-version '(Org . 8.0) :type 'i-dont-know-how-to-work-this) #+END_SRC The end result I'm after is: the user can either set org-html-doctype to a symbol from among the cars org-html-doctype-alist, or he/she can set it directly to the doctype string. I don't know how to represent that in a defcustom. And of course, if anyone has any better approaches, then speak now or... speak later. Eric
Re: [O] Attributes on HTML tables?
Eric Abrahamsen e...@ericabrahamsen.net writes:
François Pinard pin...@iro.umontreal.ca writes:
Bastien b...@gnu.org writes:
Eric Abrahamsen e...@ericabrahamsen.net writes:
The first step is probably to research the differences between xhtml and
html 5.
Well, I would even skip this step and just hack something usable.
I sort of fudged on the below. The upside is that it should be pretty
forgiving now: you can set all kinds of strings as your :html-doctype,
and it will do a reasonably good job of guessing how to handle it.
Barring actual bugs or poor design decisions, what's left to do is:
1. Make sure that inlined script and style chunks are escaped correctly,
I seem to remember reading that the commenting/escaping syntax for these
chunks varies according to html flavor.
2. I'd like to add the possibility to put an arbitrary :html-container
attribute on HTML elements, so that things that would have been wrapped
in divs can be wrapped in article, section, nav, and so on and
so forth.
Rick Frankel kindly provided a test file for this, which I've modified
below:
#+BEGIN_SRC emacs-lisp
#+TITLE: HTML 5 Test
#+DATE: {{{modification-time(%Y-%m-%d)}}}
#+HTML_DOCTYPE: html5
#+BIND: org-html-divs ((preamble header preamble) (content section
content) (postamble footer postamble))
* Org HTML5 Test
ok? This should be a paragraph with a \\
line break in it. I think
* How about a table
| col1 | col2 |
|--+--|
| a|1 |
| b|2 |
Tables can't have attributes in HTML5.
* And a list
- a
- b
- c
* And an image
[[file:1356810947473.jpg]]
* A definiton list
#+ATTR_HTML: :options html-container article
- a :: foo
- b :: bar
#+END_SRC
Please break! I'll provide a properly-written patch when we've sorted it out.
E
From 296bbf0f74d0c3d49259e146597a174e7c14fda9 Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen e...@ericabrahamsen.net
Date: Sat, 13 Apr 2013 13:22:14 +0800
Subject: [PATCH] First stab at exporting to various flavors of HTML.
---
lisp/ox-html.el | 151 +++-
1 file changed, 96 insertions(+), 55 deletions(-)
diff --git a/lisp/ox-html.el b/lisp/ox-html.el
index 0ad3dc3..af80707 100644
--- a/lisp/ox-html.el
+++ b/lisp/ox-html.el
@@ -142,6 +142,15 @@
(defvar org-html--pre/postamble-class status
CSS class used for pre/postamble)
+(defconst org-html-doctype-alist
+ '((html4 . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\)
+(html4-strict . !DOCTYPE HTML PUBLIC \-//W3C//DTD HTML 4.01//EN\
+\http://www.w3.org/TR/html4/strict.dtd\;)
+(xhtml . !DOCTYPE HTML PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\
+\http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;)
+(html5 . !DOCTYPE HTML))
+ An alist mapping (x)html flavors to specific doctypes.)
+
(defconst org-html-special-string-regexps
'((- . #x00ad;) ; shy
(---\\([^-]\\) . #x2014;\\1) ; mdash
@@ -747,7 +756,9 @@ in all modes you want. Then, use the command
'(:border 2 :cellspacing 0 :cellpadding 6 :rules groups :frame hsides)
Default attributes and values which will be used in table tags.
This is a plist where attributes are symbols, starting with
-colons, and values are strings.
+colons, and values are strings.
+
+When exporting to HTML5, these values will be disregarded.
:group 'org-export-html
:version 24.4
:package-version '(Org . 8.0)
@@ -855,7 +866,9 @@ CSS classes, then this prefix can be very useful.
The extension for exported HTML files.
%s will be replaced with the charset of the exported file.
This may be a string, or an alist with export extensions
-and corresponding declarations.
+and corresponding declarations.
+
+This declaration only applies when exporting to XHTML.
:group 'org-export-html
:type '(choice
(string :tag Single declaration)
@@ -871,15 +884,14 @@ Use utf-8 as the default value.
:package-version '(Org . 8.0)
:type 'coding-system)
-(defcustom org-html-doctype
- !DOCTYPE html PUBLIC \-//W3C//DTD XHTML 1.0 Strict//EN\ \http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\;
+(defcustom org-html-doctype xhtml
Document type definition to use for exported HTML files.
Can be set with the in-buffer HTML_DOCTYPE property or for
publishing, with :html-doctype.
:group 'org-export-html
:version 24.4
:package-version '(Org . 8.0)
- :type 'string)
+ :type 'string)
(defcustom org-html-container-element div
HTML element to use for wrapping top level sections.
@@ -1034,7 +1046,7 @@ precedence over this variable.
'((en p class=\author\Author: %a (%e)/p
p class=\date\Date: %d/p
p class=\creator\%c/p
-p class=\xhtml-validation\%v/p))
+p class=\validation\%v/p))
Alist of languages and format strings for the HTML postamble.
The first element of each list is the language code, as used for
@@ -1059,7 +1071,7 @@ like that: \%%\.
:value-type (string :tag Format string)))
(defcustom org-html-validation-link
- a href=\http://validator.w3.org/check?uri=referer\;Validate XHTML
Re: [O] [PATCH] Change relative weekday specifications (ex: fri or -tue) to exclude today
On 13.4.2013, at 02:11, Bastien b...@gnu.org wrote: Hi Sacha, Sacha Chua sa...@sachachua.com writes: What do people think? I love it. Yes, it behaves more sanely like this. And since this was stolen from planner anyway... :) - Carsten It's neat and efficient. You even managed to get the patch short enough so that it's a TINYCHANGE. Applied, thanks! -- Bastien
