Re: [O] Enriched/Org is a colorful Org
On 12 apr. 2013, at 08:41, Eli Zaretskii wrote: >> From: Carsten Dominik >> Date: Fri, 12 Apr 2013 00:49:32 +0200 >> Cc: "emacs-orgmode@gnu.org List" >> >>> 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 writes: > Hi Volker, > > 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 > 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 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 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 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 writes: > On 4/5/13, Thorsten Jolitz 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 look&feel 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 wrote: >> From: Carsten Dominik >> 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 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 wrote: > > On 12 apr. 2013, at 10:31, Eli Zaretskii wrote: > > >> From: Carsten Dominik > >> 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 > 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" 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 > Cc: Eli Zaretskii , Org Mode Mailing List > > 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 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 writes: > Hi Marc-Oliver, > > Marc-Oliver Ihm 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 writes: > Eric Abrahamsen 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 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 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 writes: > I don't like the additional timestamp information. It is now removed. -- Bastien
Re: [O] adding images in org
Nick Dokos 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 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 > Cc: Torsten Wagner , 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 writes: Hi Marc-Oliver, Marc-Oliver Ihm 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" 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 writes: > Hi Thomas, > > thanks for the follow-up. > > Thomas Alexander Gerds 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" 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 " :: Specifies to use 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" writes: > Hi Eric, > > Eric Schulte wrote: >> "Sebastien Vauban" 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 writes: > Hi Achim, > > Achim Gratz 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 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" writes: > Hi Christopher, > > Christopher Allan Webber wrote: >> Eric Abrahamsen writes: >>> Russell Adams 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" 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 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 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 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 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 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 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 writes: > Bastien writes: > >> Eric Abrahamsen 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 . "") (html4-strict . " \"http://www.w3.org/TR/html4/strict.dtd\"";) (xhtml . "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\";>") (html5 . "")) "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 writes:
> François Pinard writes:
>
>> Bastien writes:
>>
>>> Eric Abrahamsen 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 "div"s 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
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" . "")
+("html4-strict" . "
+\"http://www.w3.org/TR/html4/strict.dtd\"";)
+("xhtml" . "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\";>")
+("html5" . ""))
+ "An alist mapping (x)html flavors to specific doctypes.")
+
(defconst org-html-special-string-regexps
'(("-" . "") ; shy
("---\\([^-]\\)" . "—\\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
- "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" "Author: %a (%e)
Date: %d
%c
-%v"))
+%v"))
"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
- "http://validator.w3.org/check?uri=referer\";>Validate XHTML 1.0"
+ "http://validator.w3.org/check?uri=referer\";>Validate"
"Link to HTML validation service."
:group 'org-export-html
:type 'string)
@@ -1239,6 +1251,19 @@ CSS classes, then this prefix can be very useful."
;;; Internal Functions
+(defun org-html-xhtml-p (info)
+ (let ((dt (downcase (plist-get inf
Re: [O] [PATCH] Change relative weekday specifications (ex: fri or -tue) to exclude today
On 13.4.2013, at 02:11, Bastien wrote: > Hi Sacha, > > Sacha Chua 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 >
Re: [O] org-babel: two confirmations for org/HTML "macro"?
Eric Schulte writes: > After walking through this patch, it looks like it provides exactly > the correct behavior. Please go ahead and apply these changes. Thanks for checking, pushed to master. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Terratec KOMPLEXER: http://Synth.Stromeko.net/Downloads.html#KomplexerWaves
Re: [O] org.texi:8719 Error
Feng Shu writes: > 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 Fixed in master. Arguments to macros can not span several lines in TeXinfo. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
Re: [O] adding images in org
so - has anyone tried something like this before? i thought this would be legion. how would you go about implementing this? On 4/12/13, Bastien wrote: > 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 > >
