Re: [O] worg-new-exporter successful publish locally
Hi Jay, Jay Kerns writes: > The new Worg branch publishes for me without error under Org-mode > version 8.0.1 (release_8.0.1-24-g92f372). *Wow*! That was super fast! Thanks a lot for leading this project, quite an achievement. I won't have time to test over the week-end but I hope a few people will, so that I can make the switch on monday when I have a good connection (not at home right now.) Thanks again! -- Bastien
[O] worg-new-exporter successful publish locally
Hi there, The new Worg branch publishes for me without error under Org-mode version 8.0.1 (release_8.0.1-24-g92f372). I updated the existing emacs.el (underlying Worg, IIUC) to the Org 8.0 exporting/publishing syntax. You can see the latest draft in worgtest-init.el which lives in the top-level directory. To test the publish yourself you'd need to customize the base/publishing directories for your local machine and then do emacs -Q -l "/path/to/worg/worgtest-init.el" followed by M-x publish-worg There are changes to some files which are necessary for a successful publish and which are detailed at the bottom of this email. Have a look in FIXME. Given the successful publish locally, I went through and updated all remaining in-buffer settings that I could find (HTML_HEAD, etc.). To the best of my knowledge, everything is DONE, notwithstanding the comments below. DISCLAIMERS 1. I didn't work on orgmode.org at all. 2. Successful export/publish doesn't say anything about the content and/or outdated info in the pages. Cheers, -- Jay - sitemap.org - Error: Invalid time-stamp specification - The error here has to do with an undocumented function that I can't figure out. - Status: disabled auto-sitemap in publish-alist - FIXME/how-to-use-Babel-for-R.org - content is out of date, but exports without error - Status: updated in-buffer settings but otherwise unchanged - FIXME/test-for-how-to-use-Babel-for-R.org - content is out of date, but exports without error - Status: updated buffer settings but otherwise unchanged - org-contrib/babel/header-args.org - Error: local variables in header-args.org and header-args.html - eval: org-babel-default-header-args:Python - if I hit "n" then Emacs hangs until C-g - Status: moved to FIXME - org-tutorials/org-R/variable-popcon.org - Error: none, really, it takes a really long time to export but succeeds eventually. - Status: unchanged, but somebody might investigate the reason for this extended export time, maybe it's just because the file is so big. - org-configs/org-customization-survey.org - export of this single file takes 1.5 hrs on my laptop - I don't know why - Status: moved to FIXME - The following appear to set file local variables - code/org-info-js/changes.org - code/org-info-js/org-slides/slides.org - org-contrib/org-drill.org - org-contrib/org-git-link.org - org-contrib/babel/examples/drift.org - Status updated in buffer settings, but otherwise unchanged. Thought you might like to know.
Re: [O] Exporting caption with raw results from inline source blocks
Hi Eric, Eric Schulte wrote: > Nicolas Goaziou writes: >> Eric Schulte writes: >> >>> I'm loath to add /another/ results keyword, but perhaps it would be nice >>> to be able to specify that you want the results processed (e.g, >>> stripping the newline), but you don't want them to be wrapped as an >>> example. An alternate approach which may be preferable would be to >>> expose a defcustom along the lines of org-babel-inline-result-wrapper, >>> which could be used by org-babel-examplize-region instead of "=%s=". >> >> What about always removing trailing newline characters in _inline_ src >> blocks results? > > That is certainly an option. It could be argued that the point of "raw" > is to not change the output at all That was one point I tried to attract attention onto: since short, we already modify the "raw" output (by "cycling" on tables-alike results). We don't have anymore a real "raw" results which would completely stay untouched. > and sometimes people use (abuse) inline results expecting to be able to have > them insert multi-line results (e.g., they support tabular output). > > There are a number of solutions here which I personally would be happy > with. Best regards, Seb -- Sebastien Vauban
Re: [O] are babel python sessions and inlined images incompatible?
Hi Achim, Achim Gratz wrote: > Sebastien Vauban writes: >> Would we want to abstract the above, I guess we should generalize the >> languages families as: >> >> - graphics-only languages (ditaa, dot, gnuplot, etc.) >> >> - general-purpose languages with graphical capacities (R, maxima, octave... >> and, at least, python[1] IIUC) >> >> - general-purpose languages without graphical capacities (sql, sh, etc.) > > This is something of a non-starter as all generalizations are false. > > Babels notion of graphics is simply that after execution of the source > block it expects to be able to find a file that looks like it has a > graphics format in it (and its notion of results is that it gets > something from standard output that conforms to certain rules that are > changeable by header arguments). > > A "graphics-only" language would be one that could only write files, but > Babel can easily transcend that limitation and pretend it had gotten a > result instead. It might even filter the result to convert between > formats. Conversely, a language that cannot write files could have an > implementation where Babel constructs the file to put in the graphics > link in Org from the output of the program. Existing Babel language > implementations already use both mechanisms. My idea was simply to ensure that all similar languages share the same set of header arguments, which is not the case, as of today, with python (no support for ":results graphics"). But I get your point. Best regards, Seb -- Sebastien Vauban
Re: [O] Custom time stamps and HTML export and #+BIND
On 27.4.2013, at 08:24, Carsten Dominik wrote: > Hi Nicolas, > > I have a file that I am exporting to HTML, and the file contains > > #+BIND: org-time-stamp-custom-formats ("<%d-%m-%Y>" . "<%d-%m-%Y %H:%M>") > #+BIND: org-display-custom-times t > > Apparently these lines are not used during HTML export. I debugged the > org-translate-time function. When it is called during HTML export, both > variables do not have the desired values. > > This should still work, right? Never mind, I had not turned this feature on. Sorry for the noise - Carsten
[O] Custom time stamps and HTML export and #+BIND
Hi Nicolas, I have a file that I am exporting to HTML, and the file contains #+BIND: org-time-stamp-custom-formats ("<%d-%m-%Y>" . "<%d-%m-%Y %H:%M>") #+BIND: org-display-custom-times t Apparently these lines are not used during HTML export. I debugged the org-translate-time function. When it is called during HTML export, both variables do not have the desired values. This should still work, right? - Carsten
Re: [O] are babel python sessions and inlined images incompatible?
Sebastien Vauban writes: > Would we want to abstract the above, I guess we should generalize the > languages families as: > > - graphics-only languages (ditaa, dot, gnuplot, etc.) > > - general-purpose languages with graphical capacities (R, maxima, octave... > and, at least, python[1] IIUC) > > - general-purpose languages without graphical capacities (sql, sh, etc.) This is something of a non-starter as all generalizations are false. Babels notion of graphics is simply that after execution of the source block it expects to be able to find a file that looks like it has a graphics format in it (and its notion of results is that it gets something from standard output that conforms to certain rules that are changeable by header arguments). A "graphics-only" language would be one that could only write files, but Babel can easily transcend that limitation and pretend it had gotten a result instead. It might even filter the result to convert between formats. Conversely, a language that cannot write files could have an implementation where Babel constructs the file to put in the graphics link in Org from the output of the program. Existing Babel language implementations already use both mechanisms. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] the "right way" to build OMPL export and import
Nicolas Goaziou writes: > Eric Abrahamsen writes: > >> Would you suggest an export backend that only handles headlines (other >> elements are a no-op)? I suppose you could just write org-opml-headline >> to read properties and return XML chunks, and then you wouldn't have to >> use `org-element-parse-buffer' at all. > > I don't know well OMPL format, but IIRC, it needs an inner-template > (which would handle , , etc.), a headline transcoder, and > a couple of objects transcoders (e.g., for entities) in order to > properly export text attribute. > > Anyway, you don't need to use `org-element-parse-buffer' at all. Great, thanks for the tips. Sorry if I hijacked the thread a bit, anyway should be useful to the OP...
[O] how to best make characters invisible in a org-derived mode
Hi orgers, In a mode derived from org-mode, I would like to hide some characters with a special function to make the display cleaner. There are two cases: - special characters that should be always invisible - strings matched by a regex that should be invisible I would be glad for any pointers or ideas on how to implement this, either by piggy-packing on org-mode code or by using generic Emacs features. All the best, Christian -- Christian Wittern, Kyoto
Re: [O] Tracking flexitime
Thomas Koch writes: > I'm searching for best practices to track flexi time with orgmode. I've a > work > contract of 8 hours per day in average. So I'd like to start a clock when I > arrive at work, pause it for lunch and stop it when I leave. > > I wouldn't like to rely only on the sum of the time spent on tasks since > there > is always work time that can hardly be assigned to a specific task. Hi Thomas, I clock my 7.5 hour work day every day. When I arrive at work I punch in with f9-I which starts the clock on my default * Organization task then I pick something from the agenda, clock it in and work. In my setup clocking out moves the clock up one level in the tree or back to the * Organization task. This keeps time on projects and works great for me. I clock out at lunch (f9-O), clock back in after lunch (f9-I) and clock out at the end of the day when my daily clock report on the agenda hits 7.5 hours. I don't get paid for unauthorised overtime and I don't work for free :) I clock every minute of every day that I work minus lunch. If personal tasks interrupt work I clock those in with a new capture task and remove these from my daily work report (C-u R in the agenda will show a clock report using the current tag filter on the agenda). All the gory details for my setup are here: http://doc.norang.ca/org-mode.html Regards, Bernt
Re: [O] New exporter - publishing org files doesn't include :tangle
Bernt Hansen writes: > Nicolas Goaziou writes: > >> Hello, >> >> Bernt Hansen writes: >> >>> So far my attempts using this workaround have failed and I can't get >>> :tangle in my exported org file. I think I also would prefer to have >>> the :exports value in the .org source as well so it's a true >>> representation of the source. >> >> There was a bug in org back-end: affiliated keywords were >> removed. I fixed it. Does it solve your problem (using the workaround)? > > Thanks! > > I'll try again tonight and let you know. > > -Bernt Yes I think this now works. The :exports details are missing but it's usable for generating a emacs.el file now from the document. Thanks! Bernt
Re: [O] parameterizing keyword values during a #+call
Eric, > You could put the emacs-lisp code into an emacs-lisp code block which > is exported but has a result type of "none" or "silent". ah -- i should have tried that! that works -- thanks *very* much! cheers, Greg
Re: [O] the "right way" to build OMPL export and import
Eric Abrahamsen writes: > Would you suggest an export backend that only handles headlines (other > elements are a no-op)? I suppose you could just write org-opml-headline > to read properties and return XML chunks, and then you wouldn't have to > use `org-element-parse-buffer' at all. I don't know well OMPL format, but IIRC, it needs an inner-template (which would handle , , etc.), a headline transcoder, and a couple of objects transcoders (e.g., for entities) in order to properly export text attribute. Anyway, you don't need to use `org-element-parse-buffer' at all. Regards, -- Nicolas Goaziou
Re: [O] parameterizing keyword values during a #+call
Greg Minshall writes: > Eric, > >> And you could wrap up the extra-long Emacs-lisp in a function or macro >> in your init to avoid the overlength header argument. > > is it possible to embed the function inside the .org file itself? (in > order to promote sharing of .org files, without needing any > more-than-necessary ancillary state to accompany the file.) > > (i can imagine the file extension == file type being a parameter to the > asymptote routines, but i'd *rather* have it pass in the :file > parameter.) > You could put the emacs-lisp code into an emacs-lisp code block which is exported but has a result type of "none" or "silent". Best, > > cheers, Greg -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] parameterizing keyword values during a #+call
Eric, > And you could wrap up the extra-long Emacs-lisp in a function or macro > in your init to avoid the overlength header argument. is it possible to embed the function inside the .org file itself? (in order to promote sharing of .org files, without needing any more-than-necessary ancillary state to accompany the file.) (i can imagine the file extension == file type being a parameter to the asymptote routines, but i'd *rather* have it pass in the :file parameter.) cheers, Greg
Re: [O] the "right way" to build OMPL export and import
Nicolas Goaziou writes: > Hello, > > Eric Abrahamsen writes: > >> I'm not sure the general export engine is going to be of much use, >> since XML is so completely flexible, but you'll definitely want to >> build it on top of the internal parser. > > It would be a bad idea not to use the export framework, unless you want > to reinvent the wheel (e.g., re-implementing skipping of :noexport: > tags). > >> Luckily, the parser turns an org subtree into a parse tree, and the >> function `xml-print' turns a parse tree into XML. They're not quite the >> same parse tree, but I guess you'll want to do something like this: >> >> >> #+BEGIN_SRC org >> ,* My Great Playlist >> ,** The Cold Cold Ground.mp3 >> :PROPERTIES: >> :OPML_TYPE: song >> :OPML_F: Tom Waits - The Cold Cold Ground >> :END: >> ,** Don't Eat the Yellow Snow.mp3 >> :PROPERTIES: >> :OPML_TYPE: song >> :OPML_F: Frank Zappa - Don't Eat the Yellow Snow >> :END: >> #+END_SRC >> >> >> | >> | >> org-element--parse-elements > > Please use `org-element-parse-buffer' instead. As the two consecutive > hyphens suggest, this is an internal function. I was hoping you'd jump in! Would you suggest an export backend that only handles headlines (other elements are a no-op)? I suppose you could just write org-opml-headline to read properties and return XML chunks, and then you wouldn't have to use `org-element-parse-buffer' at all. E
Re: [O] are babel python sessions and inlined images incompatible?
"Sebastien Vauban" writes: > As you say, I guess that one could copy/paste the code from maxima, octave or > R to get the desired results. > > Would we want to abstract the above, I guess we should generalize the > languages families as: > > - Graphics-only languages (ditaa, dot, gnuplot, etc.) > > - General-purpose languages with graphical capacities (R, maxima, octave... > And, at least, python[1] IIUC) Python features very sophisticated graphics through matplotlib (at least on par with R/ggplot2). > - General-purpose languages without graphical capacities (sql, sh, etc.) Sounds like a good idea to me. I don't know whether it would save a lot of effort though or make it easier to get functions spread out? –Rasmus -- When in doubt, do it!
Re: [O] the "right way" to build OMPL export and import
Hello, Eric Abrahamsen writes: > I'm not sure the general export engine is going to be of much use, > since XML is so completely flexible, but you'll definitely want to > build it on top of the internal parser. It would be a bad idea not to use the export framework, unless you want to reinvent the wheel (e.g., re-implementing skipping of :noexport: tags). > Luckily, the parser turns an org subtree into a parse tree, and the > function `xml-print' turns a parse tree into XML. They're not quite the > same parse tree, but I guess you'll want to do something like this: > > > #+BEGIN_SRC org > ,* My Great Playlist > ,** The Cold Cold Ground.mp3 > :PROPERTIES: > :OPML_TYPE: song > :OPML_F: Tom Waits - The Cold Cold Ground > :END: > ,** Don't Eat the Yellow Snow.mp3 > :PROPERTIES: > :OPML_TYPE: song > :OPML_F: Frank Zappa - Don't Eat the Yellow Snow > :END: > #+END_SRC > > > | > | > org-element--parse-elements Please use `org-element-parse-buffer' instead. As the two consecutive hyphens suggest, this is an internal function. Regards, -- Nicolas Goaziou
Re: [O] the "right way" to build OMPL export and import
Alexis Gallagher writes: > Hi, > > I would love to be able to export org documents to opal, so that I can > read them with the various commercial outlining apps on platforms > without emacs -- e.g, iOS. The ideal thing would be if I could import > OPML as well. > > Is anyone working on this already? > > If not, does anyone have any pointers on the "right way" to go about > this, so that the work would go smoothly and be acceptable upstream? > This seems like a good time to ask given the recent consolidation of > export facilities around the internal parser org-element.el. > > I presume any OPML exporter should be based on that, correct? Is any one of > the existing exporters a particularly clean example to work from? > > For OPML import, is org-element-interpret-data the best starting point? > > Alexis Hi Alexis, I guess the first step to making an OPML exporter would be figuring out how to export correctly to XML, which happens to be something I've spent a whole fourteen minutes thinking about. I'm not sure the general export engine is going to be of much use, since XML is so completely flexible, but you'll definitely want to build it on top of the internal parser. Luckily, the parser turns an org subtree into a parse tree, and the function `xml-print' turns a parse tree into XML. They're not quite the same parse tree, but I guess you'll want to do something like this: #+BEGIN_SRC org ,* My Great Playlist ,** The Cold Cold Ground.mp3 :PROPERTIES: :OPML_TYPE: song :OPML_F: Tom Waits - The Cold Cold Ground :END: ,** Don't Eat the Yellow Snow.mp3 :PROPERTIES: :OPML_TYPE: song :OPML_F: Frank Zappa - Don't Eat the Yellow Snow :END: #+END_SRC | | org-element--parse-elements | | #+BEGIN_SRC emacs-lisp (org-data (headline "My Great Playlist" (etc, snipped because printing this makes a huge mess) #+END_SRC | | magic-happens-here | | #+BEGIN_SRC emacs-lisp (outline ((text . "My Great Playlist")) (outline ((text . "The Cold Cold Ground.mp3") (type . "song") (f . "Tom Waits - The Cold Cold Ground"))) (outline ((text . "Don't Eat the Yellow Snow.mp3") (type . "song") (f . "Frank Zappa - Don't Eat the Yellow Snow" #+END_SRC | | xml-print | | #+BEGIN_SRC xml #+END_SRC It's the magic that will take some doing, though! Eric
Re: [O] [BUG] org-fill-paragraph on #+TBLNAME
Michael Brand writes: > On Fri, Apr 26, 2013 at 4:00 PM, Nicolas Goaziou wrote: >> Thanks for your patch. While you're at it, would you mind providing >> a test for it? > > Ok, the attached patch replaces my previous one. Applied. Thank you! Regards, -- Nicolas Goaziou
Re: [O] MobileOrg for iOS approved and soon to be available in the app store
I haven't seen this specifically, could you file bug on the issues page at github[1] with a screenshot? I'll make sure to look at it asap. [1] https://github.com/MobileOrg/mobileorg/issues Thanks! -sean On Fri, Apr 26, 2013 at 9:00 AM, wrote: > Sean Escriva writes: > >> For those interested in MobileOrg on iOS devices, it has been approved >> and will be back in the store soon, it can take up to 24 hours to >> become available. > > I was using the previous version and have just deleted that from my > phone. On trying to install the new one I click the "Install app" > button in App Store and get an error message: > > ,[ ix.ApplicationNotCompatible.WarningTitle ] > | ix.ApplicationNotCompatible.SoftwareUpdateDescription > ` > > Any suggestions? I'm running iOS 6.0.1 (10523) > > > -- > Giles Chamberlin > >
Re: [O] Exporting caption with raw results from inline source blocks
Nicolas Goaziou writes: > Hello, > > Eric Schulte writes: > >> I'm loath to add /another/ results keyword, but perhaps it would be nice >> to be able to specify that you want the results processed (e.g, >> stripping the newline), but you don't want them to be wrapped as an >> example. An alternate approach which may be preferable would be to >> expose a defcustom along the lines of org-babel-inline-result-wrapper, >> which could be used by org-babel-examplize-region instead of "=%s=". > > What about always removing trailing newline characters in _inline_ src > blocks results? > That is certainly an option. It could be argued that the point of "raw" is to not change the output at all, and sometimes people use (abuse) inline results expecting to be able to have them insert multi-line results (e.g., they support tabular output). There are a number of solutions here which I personally would be happy with. -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] Clocking totals in agenda view
Rick Moynihan writes: > Yes I'd seen that, but I hadn't thought that I could narrow the agenda > to a day, and then generate the report... which almost gives me what I > want. > > Ideally I'd like to visualise the clocking times for a whole week at a > time, by day... So I could spot days easily where there had been > clocking errors... rather than having to page through them manually... > is this possible? Hi Rick, I do this on the weekly agenda looking at the entire week with clock check and Clock check enabled (C-c a a w v c R) This gives me a quick clock view for the entire week and a total report for the week. Then I switch to day view and look at each of the days in the week one at a time for daily totals (d, f and b to move forward and back). It's not all in one place but it works great for my needs and it's quick to generate. You can also limit the report to specific tags with C-u R (whatever tags you are currently filtering with) Hope that helps. Regards, Bernt
Re: [O] Exporting caption with raw results from inline source blocks
Hello, Eric Schulte writes: > I'm loath to add /another/ results keyword, but perhaps it would be nice > to be able to specify that you want the results processed (e.g, > stripping the newline), but you don't want them to be wrapped as an > example. An alternate approach which may be preferable would be to > expose a defcustom along the lines of org-babel-inline-result-wrapper, > which could be used by org-babel-examplize-region instead of "=%s=". What about always removing trailing newline characters in _inline_ src blocks results? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] export to various flavors of (X)HTML
On Fri, Apr 26, 2013 at 10:14:17AM -0700, Eric Abrahamsen wrote: > Rick Frankel writes: > > > > Therefore, `org-html-close-tag' should check that the doctype is not a > > flavor of html4 rather than a flavor of xhtml. An alternative would be > > to add ("xhtml5" . "") to the doctype alist, and the > > appropriate testing for being html5 and xhtml. > > > > See the discussions of polyglot markup @ > > http://en.wikipedia.org/wiki/Polyglot_markup > > and > > http://www.w3.org/TR/2011/WD-html-polyglot-20110405/#dfn-polyglot-markup > > for the rationale. > > Ah, those were interesting links, I hadn't considered those issues. > Luckily, your second option was a three-line change to the existing > patch: using "xhtml5" now produces the same output as "html5", except > that self-closing tags are self-closed, and there's a xmlns declaration > in the element. Best of all worlds, I hope. Brilliant! I will apply the patch and try it later this weekend... rick
Re: [O] [PATCH] export to various flavors of (X)HTML
Rick Frankel writes: > On 25.04.2013 17:20, Eric Abrahamsen wrote: >> Who knew this would turn out to be such a fraught issue! All I wanted >> was that little green checkmark from the W3C... >> >> Here's what I think should be an acceptable final patch. I dropped >> the >> CDATA mess, and came up with a slightly different implementation for >> handling self-closing tags. It's maybe a little /bulkier/ than the >> previous implementation, but not so hacky, and may continue to be >> useful >> in the future. There's also a documentation patch. > > Overall, looks good, but again, i would _strongly_ argue that html5 > should generate valid xhtml. > If it doesn't, it will really break my post-processing workflow... > > Therefore, `org-html-close-tag' should check that the doctype is not a > flavor of html4 rather than a flavor of xhtml. An alternative would be > to add ("xhtml5" . "") to the doctype alist, and the > appropriate testing for being html5 and xhtml. > > See the discussions of polyglot markup @ > http://en.wikipedia.org/wiki/Polyglot_markup > and > http://www.w3.org/TR/2011/WD-html-polyglot-20110405/#dfn-polyglot-markup > for the rationale. Ah, those were interesting links, I hadn't considered those issues. Luckily, your second option was a three-line change to the existing patch: using "xhtml5" now produces the same output as "html5", except that self-closing tags are self-closed, and there's a xmlns declaration in the element. Best of all worlds, I hope. E >From 12472f7fe52848a011cc218e36b01416cfa6c146 Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen Date: Fri, 26 Apr 2013 10:04:47 -0700 Subject: [PATCH 11/11] ox-html.el: Export to various flavors of (X)HTML lisp/ox-html.el (org-html-doctype-alist): New variable holding an alist of (X)HTML doctypes (org-html-xhtml-p): New function (org-html-html5-p): New function (org-html-close-tag): New function Significant changes to `org-html-format-inline-image', `org-html--build-meta-info', `org-html--build-head', `org-html--build-pre/postable', `org-html-template', `org-html-horizontal-rule', `org-html-format-list-item', `org-html-line-break', `org-html-table', and `org-html-verse-block'. doc/org.texi: Document the above --- doc/org.texi| 43 - lisp/ox-html.el | 188 +--- 2 files changed, 166 insertions(+), 65 deletions(-) diff --git a/doc/org.texi b/doc/org.texi index 3f2d1b8..0815c49 100644 --- a/doc/org.texi +++ b/doc/org.texi @@ -596,6 +596,7 @@ Exporting HTML export * HTML Export commands::How to invoke HTML export +* HTML doctypes:: Org can export to various (X)HTML flavors * HTML preamble and postamble:: How to insert a preamble and a postamble * Quoting HTML tags:: Using direct HTML in Org mode * Links in HTML export::How links will be interpreted and formatted @@ -10959,6 +10960,7 @@ language, but with additional support for tables. @menu * HTML Export commands::How to invoke HTML export +* HTML doctypes:: Org can export to various (X)HTML flavors * HTML preamble and postamble:: How to insert a preamble and a postamble * Quoting HTML tags:: Using direct HTML in Org mode * Links in HTML export::How links will be interpreted and formatted @@ -10970,7 +10972,7 @@ language, but with additional support for tables. * JavaScript support:: Info and Folding in a web browser @end menu -@node HTML Export commands, HTML preamble and postamble, HTML export, HTML export +@node HTML Export commands, HTML doctypes, HTML export, HTML export @subsection HTML export commands @table @kbd @@ -10998,7 +11000,44 @@ Export to a temporary buffer. Do not create a file. @c @noindent @c creates two levels of headings and does the rest as items. -@node HTML preamble and postamble, Quoting HTML tags, HTML Export commands, HTML export +@node HTML doctypes, HTML preamble and postamble, HTML Export commands, HTML export +@subsection HTML doctypes +@vindex org-html-doctype +@vindex org-html-doctype-alist + +Org can export to various (X)HTML flavors. + +Setting the variable @var{org-html-doctype} allows you to export to different +(X)HTML variants. The exported HTML will be adjusted according to the sytax +requirements of that variant. You can either set this variable to a doctype +string directly, in which case the exporter will try to adjust the syntax +automatically, or you can use a ready-made doctype. The ready-made options +are: + +@itemize +@item +``html4-strict'' +@item +``html4-transitional'' +@item +``html4-frameset'' +@item +``xhtml-strict'' +@item +``xhtml-transitional'' +@item +``xhtml-frameset'' +@item +``xhtml-11'' +@item +``html5'' +@item +``xhtml5'' +@end itemize + +See the variable @var{org-html-doctype-alist} for details. The default is ``xhtml-strict''. + +@node HTML preamble and postamble, Quoting HTML tags, HTML doctypes, HTML export @subsection HTML preamble and
Re: [O] [PATCH] fix appointment warn time
Hi Ivan, Ivan Kanis writes: > It seemed to be a boundary error. (point) was at the end of the > timestamp which doesn't hold the org-appt-warntime property. It does not hold the text property until this property has been set. E.g., `org-agenda-prepare-buffers' sets this property. So I'm still curious: under which circumstances do you expect APPT_WARNTIME to have an effect while it does not? `org-agenda-to-appt' do refresh the 'org-appt-warntime property, so it will not appear here. > foo.org illustrate what I have seen. Evaling the get-property sexp > returns nil. Yep, as expected. > The patch adds a function that goes at the beginning of the header to > get the property. As a bonus it turns the string into a number. > > Please let me know if the patch is accepted or needs improvement. Can you try the attached patch instead? diff --git a/lisp/org.el b/lisp/org.el index 2bb6127..fe64f14 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -9245,7 +9245,7 @@ property to set." (save-excursion (org-back-to-heading t) (put-text-property - (point-at-bol) (point-at-eol) tprop p + (point-at-bol) (org-end-of-subtree t t) tprop p Link Stuff -- Bastien
[O] [PATCH] fix appointment warn time
It seemed to be a boundary error. (point) was at the end of the timestamp which doesn't hold the org-appt-warntime property. foo.org illustrate what I have seen. Evaling the get-property sexp returns nil. The patch adds a function that goes at the beginning of the header to get the property. As a bonus it turns the string into a number. Please let me know if the patch is accepted or needs improvement. diff --git a/emacs/org/org-agenda.el b/emacs/org/org-agenda.el index 631c6d0..a826b26 100644 --- a/emacs/org/org-agenda.el +++ b/emacs/org/org-agenda.el @@ -5425,6 +5425,14 @@ the documentation of `org-diary'." (org-end-of-subtree 'invisible (nreverse ee))) +(defun org-agenda-get-warntime () + "Return warn time number when the property exists." + (save-excursion +(org-back-to-heading t) +(let ((warntime (get-text-property (point) 'org-appt-warntime))) + (when warntime +(string-to-number warntime) + (defun org-agenda-todo-custom-ignore-p (time n) "Check whether timestamp is farther away than n number of days. This function is invoked if `org-agenda-todo-ignore-deadlines', @@ -5570,7 +5578,7 @@ This function is invoked if `org-agenda-todo-ignore-deadlines', clockp (and org-agenda-include-inactive-timestamps (or (string-match org-clock-string tmp) (string-match "]-+\\'" tmp))) - warntime (get-text-property (point) 'org-appt-warntime) + warntime (org-agenda-get-warntime) donep (member todo-state org-done-keywords)) (if (or scheduledp deadlinep closedp clockp (and donep org-agenda-skip-timestamp-if-done)) @@ -5659,7 +5667,7 @@ This function is invoked if `org-agenda-todo-ignore-deadlines', (memq 'agenda org-agenda-use-tag-inheritance tags (org-get-tags-at nil (not inherited-tags)) todo-state (org-get-todo-state) - warntime (get-text-property (point) 'org-appt-warntime) +warntime (org-agenda-get-warntime) extra nil) (dolist (r (if (stringp result) @@ -6059,7 +6067,7 @@ specification like [h]h:mm." (not (= diff 0 (setq txt nil) (setq category (org-get-category) - warntime (get-text-property (point) 'org-appt-warntime) + warntime (org-agenda-get-warntime) category-pos (get-text-property (point) 'org-category-position)) (if (not (re-search-backward "^\\*+[ \t]+" nil t)) (throw :skip nil) ** TPIT with Jean-Philippe at San Francisco <2013-01-18 Fri 15:00 +1w> :PROPERTIES: :APPT_WARNTIME: 5 :END: (get-text-property 71 'org-appt-warntime) (goto-char 71)
Re: [O] Question about org-agenda-goto-today (bug?)
Hi Robert, Robert Goldman writes: > I am finding that when I use this command (bound to "." in the org > agenda), I often do NOT go to today. > > Looking at the code, it seems like org-mode may be guessing today based > on text markup: > > (let ((tdpos (text-property-any (point-min) (point-max) 'org-today t))) > > We jump to this position, instead of checking the clock, if we can find it. > > If it helps, I often leave emacs running for days at a time, which I > suspect could be confusing it about what today is. Indeed. I suggest to simply refresh the agenda before jumping to today's date. > Perhaps it would be an improvement to look at what we find at TDPOS and > check to verify that it corresponds somehow to org-today? We could do that, but it would solve only half of the problem, as you would still need to jump to today's date... and this date is set when the agenda is generated. -- Bastien
Re: [O] MobileOrg for iOS approved and soon to be available in the app store
Sean Escriva writes: > For those interested in MobileOrg on iOS devices, it has been approved > and will be back in the store soon, it can take up to 24 hours to > become available. I was using the previous version and have just deleted that from my phone. On trying to install the new one I click the "Install app" button in App Store and get an error message: ,[ ix.ApplicationNotCompatible.WarningTitle ] | ix.ApplicationNotCompatible.SoftwareUpdateDescription ` Any suggestions? I'm running iOS 6.0.1 (10523) -- Giles Chamberlin
Re: [O] Exporting caption with raw results from inline source blocks
Andreas Leha writes: > John Hendy writes: > >> On Fri, Apr 26, 2013 at 6:49 AM, Andreas Leha >> wrote: >>> Andreas Leha writes: >>> Hi all, I am experiencing problems when exporting a document with inline source blocks in captions, when I want to export raw results. I guess the culprit are the 'raw' results. What should I do instead? Here is a MWE that does not export properly to LaTeX: #+PROPERTY: exports results #+PROPERTY: results raw * Caption with inline source #+name: theplot #+begin_src R :results graphics :file someplot.pdf plot(1:(10+1), 1:(10+1)) #+end_src #+caption: There are src_R{10+1} points in this plot #+results: theplot [[file:someplot.pdf]] >> >> Do you need raw results? It works for me if I just remove the >> =#+PROPERTY: results raw= line. I'm wondering if that property and the >> =:results graphics= in your code block conflict? >> >> My file: >> >> >> #+PROPERTY: exports results >> >> >> * Caption with inline source >> >> >> #+name: theplot >> #+begin_src R :results graphics :file someplot.pdf >> >> plot(1:(10+1), 1:(10+1)) >> #+end_src >> >> >> #+caption: There are src_R{10+1} points in this plot >> #+results: theplot >> >> [[file:someplot.pdf]] >> >> PDF output attached. With the results raw property line, I got goofy >> caption alignment and it just said "points in this plot" instead of >> the full line. >> >> > > Hi John, > > thanks for testing. You see the same behaviour that I see. This is a > bug, IMO. > Well, this may not be desirable behavior, but everything is operating according to the spec. Execute your inline code block manually, and you'll see exactly what is happening during export. The R code returns (as a "raw" result) the following string "11\n". When that string is inserted into the caption, the newline breaks the caption. The following example by contrast does work as expected. #+PROPERTY: exports results #+PROPERTY: results raw * Caption lost at export #+name: theplot #+begin_src R :results graphics :file someplot.pdf plot(1:(10+1), 1:(10+1)) #+end_src Execute the following manually to see what happened at export. #+caption: There are src_sh{echo -n $((10+1))} points in this plot #+results: theplot [[file:someplot.pdf]] I'm loath to add /another/ results keyword, but perhaps it would be nice to be able to specify that you want the results processed (e.g, stripping the newline), but you don't want them to be wrapped as an example. An alternate approach which may be preferable would be to expose a defcustom along the lines of org-babel-inline-result-wrapper, which could be used by org-babel-examplize-region instead of "=%s=". Regards, -- Eric Schulte http://cs.unm.edu/~eschulte
[O] Question about org-agenda-goto-today (bug?)
I am finding that when I use this command (bound to "." in the org agenda), I often do NOT go to today. Looking at the code, it seems like org-mode may be guessing today based on text markup: (let ((tdpos (text-property-any (point-min) (point-max) 'org-today t))) We jump to this position, instead of checking the clock, if we can find it. If it helps, I often leave emacs running for days at a time, which I suspect could be confusing it about what today is. E.g., this just happened to me when I tried to update my org-agenda after having been away from it overnight. Perhaps it would be an improvement to look at what we find at TDPOS and check to verify that it corresponds somehow to org-today?
Re: [O] Exporting caption with raw results from inline source blocks
> An alternate approach which may be preferable would be to expose a > defcustom along the lines of org-babel-inline-result-wrapper, which > could be used by org-babel-examplize-region instead of "=%s=". > I think this is a good idea. I've just pushed up a patch which exposes a new defcustom named `org-babel-inline-result-wrap'. If you set this to say the following. ;; emacs-lisp (setq org-babel-inline-result-wrap "$%s$") Then you original example will work as expected, exporting the following Org-mode, #+PROPERTY: exports results #+PROPERTY: results raw * Caption lost at export #+name: theplot #+begin_src R :results graphics :file someplot.pdf plot(1:(10+1), 1:(10+1)) #+end_src #+caption: There are src_R{10+1} points in this plot #+results: theplot [[file:someplot.pdf]] to the following latex % Created 2013-04-26 Fri 09:43 \documentclass[11pt]{article} \usepackage[utf8]{inputenc} \usepackage[T1]{fontenc} \usepackage{fixltx2e} \usepackage{graphicx} \usepackage{longtable} \usepackage{float} \usepackage{wrapfig} \usepackage{soul} \usepackage{textcomp} \usepackage{marvosym} \usepackage{wasysym} \usepackage{latexsym} \usepackage{amssymb} \usepackage{hyperref} \tolerance=1000 \date{\today} \title{} \hypersetup{ pdfkeywords={}, pdfsubject={}, pdfcreator={Emacs 24.3.1 (Org mode 8.0-pre)}} \begin{document} \tableofcontents \section[Caption lost at export]{Caption lost at export} \label{sec-1} \begin{figure}[htb] \centering \includegraphics[width=.9\linewidth]{someplot.pdf} \caption{There are $11$ points in this plot} \end{figure} % Emacs 24.3.1 (Org mode 8.0-pre) \end{document} -- Eric Schulte http://cs.unm.edu/~eschulte
Re: [O] M-RET slow
Nicolas Goaziou writes: > Looks like there so work to be done in the 8.x series ;) Sigh. All the work we did already looks shallow compared to what we have to do... I guess that's just part of the game! -- Bastien
Re: [O] M-RET slow
Bastien writes: > Hi Nicolas, > > Nicolas Goaziou writes: > >> Hello, >> >> Bastien writes: >> >>> Carsten Dominik writes: >>> is org-in-item-p slow? >>> >>> It depends on the size of the list -- see for example this problem, >>> where moving an item within a logbook drawer with many items is too >>> slow: >>> >>> http://thread.gmane.org/gmane.emacs.orgmode/66574 >> >> This is a different issue. `org-move-item-down' doesn't use >> `org-in-item-p'. The bottleneck here is, without surprise, >> `org-list-struct', as explained in the comments at the beginning of >> "org-list.el". > > I see. `org-at-item-p' is less expensive than `org-in-item-p' but > still very expensive as it calls `org-list-in-valid-context-p'. "very expensive" is a bit harsh, at it doesn't depend on the size of the list. Anyway, ultimately, `org-at-item-p' and `org-in-item-p' should be replaced by `org-element-at-point'. Then, all speed-up efforts should concentrate on that function (e.g., caching). Regards, -- Nicolas Goaziou
Re: [O] M-RET slow
Hi Nicolas, Nicolas Goaziou writes: > Hello, > > Bastien writes: > >> Carsten Dominik writes: >> >>> is org-in-item-p slow? >> >> It depends on the size of the list -- see for example this problem, >> where moving an item within a logbook drawer with many items is too >> slow: >> >> http://thread.gmane.org/gmane.emacs.orgmode/66574 > > This is a different issue. `org-move-item-down' doesn't use > `org-in-item-p'. The bottleneck here is, without surprise, > `org-list-struct', as explained in the comments at the beginning of > "org-list.el". I see. `org-at-item-p' is less expensive than `org-in-item-p' but still very expensive as it calls `org-list-in-valid-context-p'. -- Bastien
Re: [O] [BUG] org-fill-paragraph on #+TBLNAME
Hi Nicolas On Fri, Apr 26, 2013 at 4:00 PM, Nicolas Goaziou wrote: > Thanks for your patch. While you're at it, would you mind providing > a test for it? Ok, the attached patch replaces my previous one. Michael From 44b14cac0276888d46c89336f6b8cf0793c05105 Mon Sep 17 00:00:00 2001 From: Michael Brand Date: Fri, 26 Apr 2013 17:07:55 +0200 Subject: [PATCH] Allow also "#+NAME: table" for remote references * lisp/org-table.el (org-table-get-remote-range): Extend regexp to match "#+NAME: table" additionally to "#+TBLNAME: table". * testing/lisp/test-org-table.el: Add test. * testing/org-test.el (org-test-table-target-expect): Allow several tables to support testing remote references in the last table. --- lisp/org-table.el | 3 ++- testing/lisp/test-org-table.el | 18 ++ testing/org-test.el| 23 --- 3 files changed, 32 insertions(+), 12 deletions(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index 93c33b2..8e461c8 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -4996,7 +4996,8 @@ list of the fields in the rectangle." (save-excursion (goto-char (point-min)) (if (re-search-forward -(concat "^[ \t]*#\\+tblname:[ \t]*" (regexp-quote name-or-id) "[ \t]*$") +(concat "^[ \t]*#\\+\\(tbl\\)?name:[ \t]*" +(regexp-quote name-or-id) "[ \t]*$") nil t) (setq buffer (current-buffer) loc (match-beginning 0)) (setq id-loc (org-id-find name-or-id 'marker)) diff --git a/testing/lisp/test-org-table.el b/testing/lisp/test-org-table.el index 732ddb3..52cdc74 100644 --- a/testing/lisp/test-org-table.el +++ b/testing/lisp/test-org-table.el @@ -770,6 +770,24 @@ reference (with row). Mode string N." ;; "Remote reference." ;; (should ;;(string= "$3 = remote(FOO, @@#$2)" (org-table-convert-refs-to-rc "C& = remote(FOO, @@#B&)" + +(ert-deftest test-org-table/remote-reference-access () + "Access to remote reference." + (org-test-table-target-expect + " +#+NAME: table +| | 42 | + +| replace | | +" + " +#+NAME: table +| | 42 | + +| 42 | | +" + 1 "#+TBLFM: $1 = remote(table, @1$2)")) + (ert-deftest test-org-table/org-at-TBLFM-p () (org-test-with-temp-text-in-file " diff --git a/testing/org-test.el b/testing/org-test.el index 0c9ca58..8c81115 100644 --- a/testing/org-test.el +++ b/testing/org-test.el @@ -239,15 +239,14 @@ get the table stable. Anyhow, if LAPS is 'iterate then iterate, but this will run one recalculation longer. When EXPECT is nil it will be set to TARGET. -If running a test interactively in ERT is not enough and you need -to examine the target table with e. g. the Org formula debugger -or an Emacs Lisp debugger (e. g. with point in a data field and -calling the instrumented `org-table-eval-formula') then copy and -paste the table with formula from the ERT results buffer or -temporarily substitute the `org-test-with-temp-text' of this -function with `org-test-with-temp-text-in-file'. - -Consider setting `pp-escape-newlines' to nil manually." +When running a test interactively in ERT is not enough and you +need to examine the target table with e. g. the Org formula +debugger or an Emacs Lisp debugger (e. g. with point in a data +field and calling the instrumented `org-table-eval-formula') then +copy and paste the table with formula from the ERT results buffer +or temporarily substitute the `org-test-with-temp-text' of this +function with `org-test-with-temp-text-in-file'. Also consider +setting `pp-escape-newlines' to nil manually." (require 'pp) (let ((back pp-escape-newlines) (current-tblfm)) (unless tblfm @@ -256,9 +255,11 @@ Consider setting `pp-escape-newlines' to nil manually." (unless expect (setq expect target)) (while (setq current-tblfm (pop tblfm)) (org-test-with-temp-text (concat target current-tblfm) - ;; Search table, stop ERT at end of buffer if not found. + ;; Search the last of possibly several tables, let the ERT + ;; test fail if not found. + (goto-char (point-max)) (while (not (org-at-table-p)) - (should (eq 0 (forward-line + (should (eq 0 (forward-line -1 (when laps (if (and (symbolp laps) (eq laps 'iterate)) (should (org-table-recalculate 'iterate t)) -- 1.8.1.2
Re: [O] M-RET slow
Carsten Dominik writes: > org-insert-heading is up for a rewrite, what a mess :/ And the rewrite should use `org-element-at-point' (once) and have tests for its specifications, like many others interactive core functions. Looks like there so work to be done in the 8.x series ;) Regards, -- Nicolas Goaziou
Re: [O] M-RET slow
On 26 apr. 2013, at 16:46, Nicolas Goaziou wrote: > Hello, > > Carsten Dominik writes: > >> is org-in-item-p slow? > > It is slow, and `org-insert-heading' was calling it (directly or > indirectly) four times. OK, thanks for fixing it. org-insert-heading is up for a rewrite, what a mess :/ - Carsten
Re: [O] M-RET slow
Hello, Bastien writes: > Carsten Dominik writes: > >> is org-in-item-p slow? > > It depends on the size of the list -- see for example this problem, > where moving an item within a logbook drawer with many items is too > slow: > > http://thread.gmane.org/gmane.emacs.orgmode/66574 This is a different issue. `org-move-item-down' doesn't use `org-in-item-p'. The bottleneck here is, without surprise, `org-list-struct', as explained in the comments at the beginning of "org-list.el". Regards, -- Nicolas Goaziou
Re: [O] M-RET slow
Hello, Carsten Dominik writes: > is org-in-item-p slow? It is slow, and `org-insert-heading' was calling it (directly or indirectly) four times. Regards, -- Nicolas Goaziou
Re: [O] M-RET slow
Carsten Dominik writes: > is org-in-item-p slow? It depends on the size of the list -- see for example this problem, where moving an item within a logbook drawer with many items is too slow: http://thread.gmane.org/gmane.emacs.orgmode/66574 -- Bastien
Re: [O] M-RET slow
On 26 apr. 2013, at 16:18, Nicolas Goaziou wrote: > Hello, > > Bastien writes: > >> Hi Samuel, >> >> Samuel Wales writes: >> >>> In recent git, M-RET takes a few seconds before it does anything. I >>> wonder what sophisticated calculation it is doing? :) >> >> You can debug the function >> >> C-h f org-insert-heading RET >> >> then jump on its definition and M-x edebug-defun RET at the end to >> follow what it does. >> >> A few seconds is not acceptable, unless you managed to install Emacs >> on a PDP-1. :) > > I pushed a speed-up for `org-insert-heading'. Is it speed acceptable > now? Hi Nicolas, is org-in-item-p slow? - Carsten
Re: [O] M-RET slow
Hello, Bastien writes: > Hi Samuel, > > Samuel Wales writes: > >> In recent git, M-RET takes a few seconds before it does anything. I >> wonder what sophisticated calculation it is doing? :) > > You can debug the function > > C-h f org-insert-heading RET > > then jump on its definition and M-x edebug-defun RET at the end to > follow what it does. > > A few seconds is not acceptable, unless you managed to install Emacs > on a PDP-1. :) I pushed a speed-up for `org-insert-heading'. Is it speed acceptable now? Regards, -- Nicolas Goaziou
Re: [O] New exporter - publishing org files doesn't include :tangle
Nicolas Goaziou writes: > Hello, > > Bernt Hansen writes: > >> So far my attempts using this workaround have failed and I can't get >> :tangle in my exported org file. I think I also would prefer to have >> the :exports value in the .org source as well so it's a true >> representation of the source. > > There was a bug in org back-end: affiliated keywords were > removed. I fixed it. Does it solve your problem (using the workaround)? Thanks! I'll try again tonight and let you know. -Bernt
Re: [O] [BUG] org-fill-paragraph on #+TBLNAME
Hello, Michael Brand writes: > It did not yet for remote references, patch attached. Thanks for your patch. While you're at it, would you mind providing a test for it? Regards, -- Nicolas Goaziou
Re: [O] New exporter - publishing org files doesn't include :tangle
Hello, Bernt Hansen writes: > So far my attempts using this workaround have failed and I can't get > :tangle in my exported org file. I think I also would prefer to have > the :exports value in the .org source as well so it's a true > representation of the source. There was a bug in org back-end: affiliated keywords were removed. I fixed it. Does it solve your problem (using the workaround)? Regards, -- Nicolas Goaziou
Re: [O] [PATCH] export to various flavors of (X)HTML
On 25.04.2013 17:20, Eric Abrahamsen wrote: Who knew this would turn out to be such a fraught issue! All I wanted was that little green checkmark from the W3C... Here's what I think should be an acceptable final patch. I dropped the CDATA mess, and came up with a slightly different implementation for handling self-closing tags. It's maybe a little /bulkier/ than the previous implementation, but not so hacky, and may continue to be useful in the future. There's also a documentation patch. Overall, looks good, but again, i would _strongly_ argue that html5 should generate valid xhtml. If it doesn't, it will really break my post-processing workflow... Therefore, `org-html-close-tag' should check that the doctype is not a flavor of html4 rather than a flavor of xhtml. An alternative would be to add ("xhtml5" . "") to the doctype alist, and the appropriate testing for being html5 and xhtml. See the discussions of polyglot markup @ http://en.wikipedia.org/wiki/Polyglot_markup and http://www.w3.org/TR/2011/WD-html-polyglot-20110405/#dfn-polyglot-markup for the rationale. rick
Re: [O] variable names in manual
> > yes, except elisp variables are *not* case sensitive. > > You mean... they *are* case-sensitive, right? indeed! . > Mh.. if fu-bar and FU-BAR are two different variables, I guess we > should rename one of name anyway. Hence my initial proposal :) i agree -- having two variable names that differ only in case is a bad idea. but the language allows it. oh, well. cheers!
Re: [O] "runaway argument" exporting: * _is_?
Hi Nicolas, Nicolas Goaziou wrote: > Greg Minshall writes: >> >> * _is_? >> >> exporting via "C-c C-e lO" (or, "lo"), i get an error from latex. >> >> if i change H:2 to H:1, all (seemingly) works. here is a diff of the >> .tex file generated by each H: >> >>> \section[\underline{is}?]{\underline{is}?} >>> \label{sec-1} >> >> am i doing something wrong? (this is fallout converting from 7.9.3f to >> 8.) > > Isn't it a LaTeX limitation? What would the correct LaTeX code be in that > case? I have exactly similar problems with fboxes used for framing the tags (see function `org-latex-format-headline-default-function'): I use the following code for having nicer boxes around the tags: (format "\\hfill{}\\fbox{\\textsc{%s}}" When such a code (\fbox) is put between the [], everything breaks... LaTeX error... AFAICS, there are 2 ways to solve this: - not using the [] notation when the "short title" is exactly the same as the "long title" - having an heuristic to clean the "long title" for converting it into a "short" one (like remove all LaTeX macros, keep text only -- not sure it's good, because the tags would be "glued" next to the title) I guess the first point would make more sense. What do you think? Best regards, Seb -- Sebastien Vauban
Re: [O] [BUG] org-fill-paragraph on #+TBLNAME
Hi Nicolas On Fri, Apr 26, 2013 at 3:03 PM, Nicolas Goaziou wrote: > NAME should be a drop-in replacement for TBLNAME[fn:1]. Thanks for confirming my understanding. > If it doesn't work for remote references in tables, then "org-table.el" > must be updated. It did not yet for remote references, patch attached. Michael From 68a96411e468a211453ce83c3a139cc2952c6e72 Mon Sep 17 00:00:00 2001 From: Michael Brand Date: Fri, 26 Apr 2013 15:28:51 +0200 Subject: [PATCH] Allow also "#+NAME: table" for remote references * lisp/org-table.el (org-table-get-remote-range): Extend regexp to match "#+NAME: table" additionally to "#+TBLNAME: table". --- lisp/org-table.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-table.el b/lisp/org-table.el index 93c33b2..8e461c8 100644 --- a/lisp/org-table.el +++ b/lisp/org-table.el @@ -4996,7 +4996,8 @@ list of the fields in the rectangle." (save-excursion (goto-char (point-min)) (if (re-search-forward -(concat "^[ \t]*#\\+tblname:[ \t]*" (regexp-quote name-or-id) "[ \t]*$") +(concat "^[ \t]*#\\+\\(tbl\\)?name:[ \t]*" +(regexp-quote name-or-id) "[ \t]*$") nil t) (setq buffer (current-buffer) loc (match-beginning 0)) (setq id-loc (org-id-find name-or-id 'marker)) -- 1.8.1.2
Re: [O] Clocking totals in agenda view
Rick Moynihan, Rick Moynihan wrote: > On 26 April 2013 09:45, Sebastien Vauban wrote: >> Rick Moynihan wrote: >>> I've recently started looking at the time tracking facilities in org-mode, >>> and in particular clocking time, which really is awesome. >>> >>> org-agenda-consistency-checks seems really useful, however I'd really like >>> to add another similar overlay to the agenda that displays how much time >>> was clocked on that day. >>> >>> Is this currently possible? >> >> See the command `org-agenda-clockreport-mode', bound to `R'. > > Yes I'd seen that, but I hadn't thought that I could narrow the agenda to a > day, and then generate the report... which almost gives me what I want. > > Ideally I'd like to visualise the clocking times for a whole week at a time, > by day... So I could spot days easily where there had been clocking > errors... rather than having to page through them manually... is this > possible? Have a look, then, at Dynamic Blocks, in particular the `clocktable' dblock, aimed at writing, in the Org buffer, the *clock table* (use `C-c C-x C-r' to insert one). I guess the `:step' parameter would allow you what you want -- though not directly from the agenda. Best regards, Seb -- Sebastien Vauban
Re: [O] Loop when updating SCHEDULED date from agenda view
Hi Bastien, Bastien wrote: > thanks -- let's hope we can narrow down the issue. Cross our fingers... > The problem seems to be that Org is confused when adding > the overlay for displaying the new date in the agenda. > > This generally happens with headings that have special > text properties or overlays already, like links. Try to > remember the actual content of the heading next time you > stumble upon this bug, it may help finding the problem > (e.g. does the heading ends with a link?) I don't have that impression, but I cannot guarantee it either. Anyway, looking at the contents of the entry is clearly a good hint you give me, for hoping to find how to reproduce it. What you see is that it could be entry-related, ie the next time I'll move some specific tasks in the future, it should happen again. Stay tuned... Thx for the hint. Best regards, Seb -- Sebastien Vauban
Re: [O] are babel python sessions and inlined images incompatible?
Hi Thomas, Thomas S. Dye wrote: > "Sebastien Vauban" writes: >> Well, I *now* know it's not described in the Org manual... >> >> ╠http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01181.html >> │ >> │ - :results graphics makes the list even longer, yes? :-) I'm not >> │ sure that every language supports it and I don't believe it's >> │ currently in the manual. >> ╰ >> >> Though, it's described in many different posts on this ML, and in some >> tutorials on Worg... >> >> ╠http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html >> │ >> │ If a :file filename.ext header argument is provided to an R source >> block, then >> │ the output from the source block will go to the named file. What that >> output >> │ is depends on the value of the :results header argument. >> │ >> │ If the value is :results graphics then "base" graphics output is >> captured on >> │ disk, and a link to the graphics file is inserted into the Org Mode >> buffer (as >> │ is also the case with the graphics-only languages such as gnuplot, >> ditaa, dot, >> │ and asymptote.) >> ╰ >> >> I thought it was a "core" option value for all general-purpose languages >> (e.g. >> emacs-lisp, python, R, ruby, sh), required when your code block outputs a >> graphics. >> >> After checking, I only found it in those files: >> >> ./ob-maxima.el:117: (and (member "graphics" (cdr (assq :result-params >> params))) >> ./ob-octave.el:272: (and (member "graphics" (cdr (assq :result-params >> params))) >> ./ob-R.el:234: (and (member "graphics" (cdr (assq :result-params params))) > > The language documentation on Worg, such as > http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html, is > meant to be documentation, rather than tutorial. It is structured this > way so the manual doesn't need to be updated every time support for a > new language is added, or changes are made to a language-specific file. > > The template for this documentation includes a slot for default header > arguments and also one for language-specific header arguments, because > these are often changed by the language-specific modules. > > I think the hope and expectation is that the user community take over > the tasks of creating and tending the language-specific code. If > :results graphics makes good sense for Python, then users should feel > free to add it to ob-python.el. With the examples you point out, it > shouldn't be too difficult. As you say, I guess that one could copy/paste the code from maxima, octave or R to get the desired results. Would we want to abstract the above, I guess we should generalize the languages families as: - graphics-only languages (ditaa, dot, gnuplot, etc.) - general-purpose languages with graphical capacities (R, maxima, octave... and, at least, python[1] IIUC) - general-purpose languages without graphical capacities (sql, sh, etc.) Maybe that would allow to have sets of header arguments (or default values) mapped onto those families. Best regards, Seb [1] Never used it. -- Sebastien Vauban
Re: [O] [BUG] org-fill-paragraph on #+TBLNAME
Michael Brand writes: > The ERT you added for this makes me wonder again: What is the status > of #+NAME for tables? Initiated by a discussion on the list some time > ago I thought I could and would better migrate all my #+TBLNAME > to #+NAME but since it still does not work for remote references like > this > > #+TBLNAME: table > | 42 | > > | 42 | > #+TBLFM: $1 = remote(table, @1$1) > > I thought I did not understand the development of #+NAME. Are remote > references supposed to work also with #+NAME for tables? NAME should be a drop-in replacement for TBLNAME[fn:1]. If it doesn't work for remote references in tables, then "org-table.el" must be updated. I'll have a look at it later, unless Someone beats me to it. Regards, [fn:1] In fact, it should also be a replacement for DATA, LABEL, RESNAME, SOURCE, and SRCNAME. -- Nicolas Goaziou
Re: [O] are babel python sessions and inlined images incompatible?
Aloha Seb, "Sebastien Vauban" writes: > > Well, I *now* know it's not described in the Org manual... > > ╠http://lists.gnu.org/archive/html/emacs-orgmode/2013-03/msg01181.html > │ > │ - :results graphics makes the list even longer, yes? :-) I'm not > │ sure that every language supports it and I don't believe it's > │ currently in the manual. > ╰ > > Though, it's described in many different posts on this ML, and in some > tutorials on Worg... > > ╠http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html > │ > │ If a :file filename.ext header argument is provided to an R source > block, then > │ the output from the source block will go to the named file. What that > output > │ is depends on the value of the :results header argument. > │ > │ If the value is :results graphics then "base" graphics output is captured > on > │ disk, and a link to the graphics file is inserted into the Org > Mode buffer (as > │ is also the case with the graphics-only languages such as gnuplot, > ditaa, dot, > │ and asymptote.) > ╰ > > I thought it was a "core" option value for all general-purpose languages (e.g. > emacs-lisp, python, R, ruby, sh), required when your code block outputs a > graphics. > > After checking, I only found it in those files: > > ./ob-maxima.el:117: (and (member "graphics" (cdr (assq :result-params > params))) > ./ob-octave.el:272: (and (member "graphics" (cdr (assq :result-params > params))) > ./ob-R.el:234: (and (member "graphics" (cdr (assq :result-params params))) The language documentation on Worg, such as http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-R.html, is meant to be documentation, rather than tutorial. It is structured this way so the manual doesn't need to be updated every time support for a new language is added, or changes are made to a language-specific file. The template for this documentation includes a slot for default header arguments and also one for language-specific header arguments, because these are often changed by the language-specific modules. I think the hope and expectation is that the user community take over the tasks of creating and tending the language-specific code. If :results graphics makes good sense for Python, then users should feel free to add it to ob-python.el. With the examples you point out, it shouldn't be too difficult. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] Loop when updating SCHEDULED date from agenda view
Hi SĂ©bastien, thanks -- let's hope we can narrow down the issue. The problem seems to be that Org is confused when adding the overlay for displaying the new date in the agenda. This generally happens with headings that have special text properties or overlays already, like links. Try to remember the actual content of the heading next time you stumble upon this bug, it may help finding the problem (e.g. does the heading ends with a link?) Thanks! -- Bastien
Re: [O] [BUG] org-fill-paragraph on #+TBLNAME
Hi Nicolas On Fri, Apr 26, 2013 at 2:31 PM, Nicolas Goaziou wrote: > The error should be fixed. Fix confirmed, thank you. The ERT you added for this makes me wonder again: What is the status of #+NAME for tables? Initiated by a discussion on the list some time ago I thought I could and would better migrate all my #+TBLNAME to #+NAME but since it still does not work for remote references like this #+TBLNAME: table | 42 | | 42 | #+TBLFM: $1 = remote(table, @1$1) I thought I did not understand the development of #+NAME. Are remote references supposed to work also with #+NAME for tables? Michael
Re: [O] Exporting caption with raw results from inline source blocks
On Fri, Apr 26, 2013 at 7:41 AM, Andreas Leha wrote: > John Hendy writes: > >> On Fri, Apr 26, 2013 at 6:49 AM, Andreas Leha >> wrote: >>> Andreas Leha writes: >>> Hi all, I am experiencing problems when exporting a document with inline source blocks in captions, when I want to export raw results. I guess the culprit are the 'raw' results. What should I do instead? Here is a MWE that does not export properly to LaTeX: #+PROPERTY: exports results #+PROPERTY: results raw * Caption with inline source #+name: theplot #+begin_src R :results graphics :file someplot.pdf plot(1:(10+1), 1:(10+1)) #+end_src #+caption: There are src_R{10+1} points in this plot #+results: theplot [[file:someplot.pdf]] >> >> Do you need raw results? It works for me if I just remove the >> =#+PROPERTY: results raw= line. I'm wondering if that property and the >> =:results graphics= in your code block conflict? >> >> My file: >> >> >> #+PROPERTY: exports results >> >> >> * Caption with inline source >> >> >> #+name: theplot >> #+begin_src R :results graphics :file someplot.pdf >> >> plot(1:(10+1), 1:(10+1)) >> #+end_src >> >> >> #+caption: There are src_R{10+1} points in this plot >> #+results: theplot >> >> [[file:someplot.pdf]] >> >> PDF output attached. With the results raw property line, I got goofy >> caption alignment and it just said "points in this plot" instead of >> the full line. >> >> > > Hi John, > > thanks for testing. You see the same behaviour that I see. This is a > bug, IMO. > > Do I need the raw results? Well, it only differs in the typeface, so I > can hardly say, I 'need' them. But in longer and more elaborate > captions as for scientific publications, the results should appear as > ordinary text, I think. > I don't get anything with =:results output raw= even from a normal block... #+begin_src R :results output raw :exports results 10+1 #+end_src #+RESULTS: [1] 11 That exports a blank LaTeX document for me: \section*{Caption with inline source} \label{sec-1} % Emacs 24.3.1 (Org mode 8.0.1) \end{document} Perhaps that's the problem? There was some discussion recently about the point of raw results; This makes me wonder if it was removed? If I change to =:results value= and add =:wrap latex= above, I get regular text exported (not inside =\texttt=). It doesn't seem that =:wrap latex= works for inline blocks, though? John > Thanks again for the confirmation. > > Best, > Andreas > >
Re: [O] Filling bug with alphabetical lists
Hello, Bernt Hansen writes: > My problem was I had org-alphabetical-lists defined _after_ the requires > for the exporter back ends in my .emacs so this didn't work for me. > > Putting it before > > ;; Explicitly load required exporters > (require 'ox-html) > (require 'ox-latex) > (require 'ox-ascii) > > and restarting Emacs fixed it for me. I have updated `org-list-allow-alphabetical' docstring so it is less surprising. Thanks for bringing this up. Regards, -- Nicolas Goaziou
Re: [O] [Patch] phone links...
Greg, Here are the reworked patches. 0390: fixes two typos 0391: contains all the changes from my last patch and your corrections 0392: introduces a constant for the default value of separators Best regards Michael Strey On Sat, Apr 20, 2013 at 05:59:39PM +0200, Daimrod wrote: > Michael Strey writes: > > Oh =:-|, another struggle with Git. I'm still learning and will do my best. > > If you're not already using magit[1] I highly recommend it to you. You > can use it to commit only a portion of the changes (you can also do it > with "git commit --interactive" but I find it easier with magit). Thanks for the hint. It helped a lot. -- Michael Strey www.strey.biz From 2b59a2800de7066dde72121bc72ba75ea88f3c5a Mon Sep 17 00:00:00 2001 From: Michael Strey Date: Fri, 26 Apr 2013 12:06:34 +0200 Subject: [PATCH 390/392] org-contacts: Fix two typos in comments * contrib/lisp/org-contacts.el (org-contacts-db): fix typo in the word `matching'. * contrib/lisp/org-contacts.el (org-contacts-complete-group): fix typo in the word `found'. TINYCHANGE --- contrib/lisp/org-contacts.el | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index a3c4aed..626ad7a 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -225,7 +225,7 @@ This overrides `org-email-link-description-format' if set." org-contacts-db)) (defun org-contacts-filter (&optional name-match tags-match) - "Search for a contact maching NAME-MATCH and TAGS-MATCH. + "Search for a contact matching NAME-MATCH and TAGS-MATCH. If both match values are nil, return all contacts." (if (and (null name-match) (null tags-match)) @@ -433,7 +433,7 @@ A group FOO is composed of contacts with the tag FOO." (or (cdr (assoc-string "ALLTAGS" (caddr contact))) "") ":"))) (list start end (if (= (length completion-list) 1) - ;; We've foudn the correct group, returns the address + ;; We've found the correct group, returns the address (lexical-let ((tag (get-text-property 0 'org-contacts-group (car completion-list (lambda (string pred &optional to-ignore) -- 1.8.2 From 68145d055b7a48821d9aec308cd44764a5b889ec Mon Sep 17 00:00:00 2001 From: Michael Strey Date: Fri, 26 Apr 2013 12:29:55 +0200 Subject: [PATCH 391/392] Org-contacts: Allow org links in properties * contrib/lisp/org-contacts.el (org-contacts-split-property): Introduce a custom version of split-string that keeps org links intact. * contrib/lisp/org-contacts.el (org-contacts-strip-link): Introduce a new function that removes brackets, description, link type and colon from an org link string returning the pure link target. * contrib/lisp/org-contacts.el (provide 'org-contacts): Remove a redundant line. * contrib/lisp/org-contacts.el (org-contacts-complete-group, org-contacts-complete-name, org-contacts-view-send-email, org-contacts-get-icon, org-contacts-vcard-format): Apply the new functions to the already existing functions extracting telephone numbers and email addresses from the properties. Allowed separators for email addresses and phone numbers are `,', `;' and whitespace. `:' is not allowed anymore as separator to avoid confusion with implizit links. Examples of properties that are possible after those changes: * Surname, Name :PROPERTIES: :EMAIL:mailto:te...@test.de; [[mailto:n...@test.de]] f...@bar.biz :PHONE:[[tel:+49 351 4129535]], +491766626196 [[+49 (351) 41295-35]] :END: Phone links of the form [[tel:+49 351 412 95-35][My phone number]] or [[tel:+49 351 41295-35]] are expected. `-', `/', `(', `)' and whitespace characters are allowed in telephone numbers. --- contrib/lisp/org-contacts.el | 73 1 file changed, 61 insertions(+), 12 deletions(-) diff --git a/contrib/lisp/org-contacts.el b/contrib/lisp/org-contacts.el index 626ad7a..eb3fc09 100644 --- a/contrib/lisp/org-contacts.el +++ b/contrib/lisp/org-contacts.el @@ -445,11 +445,11 @@ A group FOO is composed of contacts with the tag FOO." ;; returned by `org-contacts-filter'. for contact-name = (car contact) ;; Grab the first email of the contact - for email = (car (split-string + for email = (org-contacts-strip-link (car (org-contacts-split-property (or (cdr (assoc-string org-contacts-email-property (caddr contact))) -
Re: [O] Exporting caption with raw results from inline source blocks
John Hendy writes: > On Fri, Apr 26, 2013 at 6:49 AM, Andreas Leha > wrote: >> Andreas Leha writes: >> >>> Hi all, >>> >>> I am experiencing problems when exporting a document with inline source >>> blocks in captions, when I want to export raw results. >>> >>> I guess the culprit are the 'raw' results. What should I do instead? >>> >>> Here is a MWE that does not export properly to LaTeX: >>> >>> >>> #+PROPERTY: exports results >>> #+PROPERTY: results raw >>> >>> * Caption with inline source >>> >>> #+name: theplot >>> #+begin_src R :results graphics :file someplot.pdf >>> plot(1:(10+1), 1:(10+1)) >>> #+end_src >>> >>> #+caption: There are src_R{10+1} points in this plot >>> #+results: theplot >>> [[file:someplot.pdf]] >>> > > Do you need raw results? It works for me if I just remove the > =#+PROPERTY: results raw= line. I'm wondering if that property and the > =:results graphics= in your code block conflict? > > My file: > > > #+PROPERTY: exports results > > > * Caption with inline source > > > #+name: theplot > #+begin_src R :results graphics :file someplot.pdf > > plot(1:(10+1), 1:(10+1)) > #+end_src > > > #+caption: There are src_R{10+1} points in this plot > #+results: theplot > > [[file:someplot.pdf]] > > PDF output attached. With the results raw property line, I got goofy > caption alignment and it just said "points in this plot" instead of > the full line. > > Hi John, thanks for testing. You see the same behaviour that I see. This is a bug, IMO. Do I need the raw results? Well, it only differs in the typeface, so I can hardly say, I 'need' them. But in longer and more elaborate captions as for scientific publications, the results should appear as ordinary text, I think. Thanks again for the confirmation. Best, Andreas
[O] ignoring subtrees scheduled in the future
Hello, I'm planning some projects for next September, and I don't want to see them in my agenda till then. These projects have a schedule date in the future, but none of their subtasks have one (there are many of them). I've found the very nice (org-agenda-skip-subtree-if 'scheduled) option for agenda views that skips them, but it works even for tasks scheduled in the past. There does not seen to be a 'future option for skipping subtrees, and the (org-agenda-todo-ignore-scheduled 'future) option only seems to work on single entries. Do you know of a way to hide some subtrees until a given date? I'm happy whether it uses a Scheduled flag or something in the property drawer. Thanks, Alan
Re: [O] [BUG] org-fill-paragraph on #+TBLNAME
Hello, Michael Brand writes: > There is a minor bug, relevant in my first and simple trial to apply > org-fill-paragraph on all parts of an Org buffer: M-q > (fill-paragraph/org-fill-paragraph) on the first column of the > line #+TBLNAME here > > #+TBLNAME: table > | field | > > results in an error. The error should be fixed. Thanks for reporting this. Regards, -- Nicolas Goaziou
Re: [O] variable names in manual
Greg Minshall writes: >> IMHO this rather call for making C-h v (and C-h f) case-non-sensitive. > > yes, except elisp variables are *not* case sensitive. You mean... they *are* case-sensitive, right? > so, if fu-bar and FOO-BAR are different variables, would C-h v put > up (some sort of) a dialog to choose between them? it would be > slightly messy. Mh.. if fu-bar and FU-BAR are two different variables, I guess we should rename one of name anyway. Hence my initial proposal :) -- Bastien
Re: [O] Exporting caption with raw results from inline source blocks
Andreas Leha writes: > Hi all, > > I am experiencing problems when exporting a document with inline source > blocks in captions, when I want to export raw results. > > I guess the culprit are the 'raw' results. What should I do instead? > > Here is a MWE that does not export properly to LaTeX: > > > #+PROPERTY: exports results > #+PROPERTY: results raw > > * Caption with inline source > > #+name: theplot > #+begin_src R :results graphics :file someplot.pdf > plot(1:(10+1), 1:(10+1)) > #+end_src > > #+caption: There are src_R{10+1} points in this plot > #+results: theplot > [[file:someplot.pdf]] > > Is it just me, or can someone reproduce this? Regards, Andreas
Re: [O] "runaway argument" exporting: * _is_?
Hello, Greg Minshall writes: > hi. i'm running > > Org-mode version 8.0.1 (release_8.0.1-42-g267cbe @ > /Users/minshall/usr/share/emacs/site-lisp/org/) > > > my test case is > > #+DATE: <2013-04-25 Thu> > #+OPTIONS: H:2 texht:t > #+BEAMER_COLOR_THEME: > #+BEAMER_FONT_THEME: > #+BEAMER_HEADER: > #+BEAMER_INNER_THEME: > #+BEAMER_OUTER_THEME: > #+BEAMER_THEME: default > #+LATEX_CLASS: beamer > #+LATEX_CLASS_OPTIONS: > #+LATEX_HEADER: > #+LATEX_HEADER_EXTRA: > > * _is_? > > > exporting via "C-c C-e lO" (or, "lo"), i get an error from latex. > > if i change H:2 to H:1, all (seemingly) works. here is a diff of the > .tex file generated by each H: > > bash greg-minshalls-mbp: {1039} diff sectbug.texH:1 sectbug.texH:2 > 38,39c38,39 > < \begin{frame}[label=sec-1]{\underline{is}?} > < \end{frame} > --- >> \section[\underline{is}?]{\underline{is}?} >> \label{sec-1} > > > am i doing something wrong? (this is fallout converting from 7.9.3f to > 8.) Isn't it a LaTeX limitation? What would the correct LaTeX code be in that case? Regards, -- Nicolas Goaziou
Re: [O] Clocking totals in agenda view
Yes I'd seen that, but I hadn't thought that I could narrow the agenda to a day, and then generate the report... which almost gives me what I want. Ideally I'd like to visualise the clocking times for a whole week at a time, by day... So I could spot days easily where there had been clocking errors... rather than having to page through them manually... is this possible? Many thanks, R. On 26 April 2013 09:45, Sebastien Vauban wrote: > Hi Rick, > > Rick Moynihan wrote: >> I've recently started looking at the time tracking facilities in >> org-mode, and in particular clocking time, which really is awesome. >> >> org-agenda-consistency-checks seems really useful, however I'd really >> like to add another similar overlay to the agenda that displays how >> much time was clocked on that day. >> >> Is this currently possible? > > See the command `org-agenda-clockreport-mode', bound to `R'. > > Best regards, > Seb > > -- > Sebastien Vauban > >
Re: [O] parameterizing keyword values during a #+call
Eric, thanks! > Something like the following should work. > > #+call: disc[:file (if (and (boundp org-export-current-backend) (equal > org-export-current-backend 'html)) "foo.svg" "foo.tex")]() :results file in fact, with the new exporter, org-export-current-backend has bit the dust, but apparently the non-architected "backend" exists. the following works great!! #+call: discs[:file (if (and (boundp 'backend) (equal backend 'html)) "fox.svg" "fox.pdf")]() :results file (note the tick in the (boundp 'backend)). now to wedge it into some init code. cheers, Greg
Re: [O] variable names in manual
hi, Bastien, > IMHO this rather call for making C-h v (and C-h f) case-non-sensitive. yes, except elisp variables are *not* case sensitive. so, if fu-bar and FOO-BAR are different variables, would C-h v put up (some sort of) a dialog to choose between them? it would be slightly messy. cheers, Greg
Re: [O] variable names in manual
I will. - Carsten On 26 apr. 2013, at 12:27, Suvayu Ali wrote: > Hi Carsten, > > On Fri, Apr 26, 2013 at 12:11:46PM +0200, Carsten Dominik wrote: >> >> On 26 apr. 2013, at 11:59, Suvayu Ali wrote: >> >>> I did a query-replace-regexp: @var{\([^}]+\)} -> @code{\1}. Hopefully I >>> skipped the right ones; patch is attached. >> >> Do you have write access? If so, please install you patch. > > Sorry I do not have write access. Someone else will have to do it. > > Cheers, > > -- > Suvayu > > Open source is the future. It sets us free.
Re: [O] variable names in manual
Hi Carsten, On Fri, Apr 26, 2013 at 12:11:46PM +0200, Carsten Dominik wrote: > > On 26 apr. 2013, at 11:59, Suvayu Ali wrote: > > > I did a query-replace-regexp: @var{\([^}]+\)} -> @code{\1}. Hopefully I > > skipped the right ones; patch is attached. > > Do you have write access? If so, please install you patch. Sorry I do not have write access. Someone else will have to do it. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Bug: org-element-fixed-width-interpreter fails when given an empty string [8.0.1 (release_8.0.1-40-g38051c @ /home/david/git/home-common/emacs/foreign/org-mode/lisp/)]
Sure thing, thanks for that. On 26 April 2013 20:06, Nicolas Goaziou wrote: > Hello, > > David Beswick writes: > >> Hi, I encountered this problem when trying out org-sync with >> Redmine. That package uses org-element to create "fixed-width" type >> elements to contain the bug descriptions. When a bug had no description, >> this problem would occur. In that case, org-element-property returns the >> empty string for the ":value" property of the fixed-width element, and >> the call to "substring" fails. > > This should be fixed. Thanks for the report and the patch (although > I used a different one). > > > Regards, > > -- > Nicolas Goaziou
Re: [O] variable names in manual
On 26 apr. 2013, at 11:59, Suvayu Ali wrote: > Hi Bastien and Carsten, > > On Fri, Apr 26, 2013 at 11:27:04AM +0200, Bastien wrote: >> Carsten Dominik writes: >> >>> Yes, I agree. Let's wait for Bastien to take a last look at this, >>> but it should indeed be reverted. >> >> Oh, I wasn't aware of this "metasyntactical" notion. >> No problem for reverting this change -- please make this >> in the maint branch so that users of 8.0.2 enjoy this. >> Also, maybe the revert of this commit is not enough, >> and we should check against remaining @var{...} to see >> if they are okay. > > I did a query-replace-regexp: @var{\([^}]+\)} -> @code{\1}. Hopefully I > skipped the right ones; patch is attached. Do you have write access? If so, please install you patch. - Carsten > > Cheers, > > -- > Suvayu > > Open source is the future. It sets us free. > <0001-Switch-var-macros-to-code-for-lisp-variables.patch>
Re: [O] Bug: org-element-fixed-width-interpreter fails when given an empty string [8.0.1 (release_8.0.1-40-g38051c @ /home/david/git/home-common/emacs/foreign/org-mode/lisp/)]
Hello, David Beswick writes: > Hi, I encountered this problem when trying out org-sync with > Redmine. That package uses org-element to create "fixed-width" type > elements to contain the bug descriptions. When a bug had no description, > this problem would occur. In that case, org-element-property returns the > empty string for the ":value" property of the fixed-width element, and > the call to "substring" fails. This should be fixed. Thanks for the report and the patch (although I used a different one). Regards, -- Nicolas Goaziou
Re: [O] window splitting and preserving folded states
> I am completely inebriated right now, so apologies for incoherence. Isn't EUI (Emacs Under the Influence) illegal? :D
Re: [O] variable names in manual
Carsten Dominik writes: > Yes, I agree. Let's wait for Bastien to take a last look at this, > but it should indeed be reverted. Oh, I wasn't aware of this "metasyntactical" notion. No problem for reverting this change -- please make this in the maint branch so that users of 8.0.2 enjoy this. Also, maybe the revert of this commit is not enough, and we should check against remaining @var{...} to see if they are okay. -- Bastien
Re: [O] Emacs completion on file:xyz links?
Ok, I can make do with that. Thanks. On Fri, Apr 26, 2013 at 11:52 AM, Suvayu Ali wrote: > On Fri, Apr 26, 2013 at 10:15:42AM +0300, Dov Grobgeld wrote: > > I often find reference files in org-files and then do the following > > sequence: > > > > * Press Ctrl-x Ctrl-f > > * Navigate to the requested file by the emacs and completion > > * Press Ctrl-a Ctrl-k to copy > > * Press Ctrl-g to get out of file-open > > * Paste with ctrl-y > > > > I was wondering if anyone has written code so that pressing [TAB] within > a > > file:/ link would do emacs completion in place? > > It does that already. Use C-c C-l to insert a link, when prompted for > the type, say file: RET. Then you can use the usual emacs completeion > interface to get filename completeion. > > What is missing though is completion when editing an existing link. > IMO, that would be a worthy feature request. > > Cheers, > > -- > Suvayu > > Open source is the future. It sets us free. > >
Re: [O] Emacs completion on file:xyz links?
On Fri, Apr 26, 2013 at 10:15:42AM +0300, Dov Grobgeld wrote: > I often find reference files in org-files and then do the following > sequence: > > * Press Ctrl-x Ctrl-f > * Navigate to the requested file by the emacs and completion > * Press Ctrl-a Ctrl-k to copy > * Press Ctrl-g to get out of file-open > * Paste with ctrl-y > > I was wondering if anyone has written code so that pressing [TAB] within a > file:/ link would do emacs completion in place? It does that already. Use C-c C-l to insert a link, when prompted for the type, say file: RET. Then you can use the usual emacs completeion interface to get filename completeion. What is missing though is completion when editing an existing link. IMO, that would be a worthy feature request. Cheers, -- Suvayu Open source is the future. It sets us free.
Re: [O] Clocking totals in agenda view
Hi Rick, Rick Moynihan wrote: > I've recently started looking at the time tracking facilities in > org-mode, and in particular clocking time, which really is awesome. > > org-agenda-consistency-checks seems really useful, however I'd really > like to add another similar overlay to the agenda that displays how > much time was clocked on that day. > > Is this currently possible? See the command `org-agenda-clockreport-mode', bound to `R'. Best regards, Seb -- Sebastien Vauban
Re: [O] variable names in manual
On 26 apr. 2013, at 10:41, Suvayu Ali wrote: > Hi Carsten, > > On Fri, Apr 26, 2013 at 10:10:32AM +0200, Carsten Dominik wrote: >> >> I suspect that the cases you are talking about here are due >> to incorrect use of the texinfo command @var{}. This should >> only be used for metasyntactical variables, when they stand >> for something else in a description. >> >> Here is an example from the current manual. >> >> You can customize this behavior using the option >> @var{org-table-use-standard-references}.} to use another, more general >> representation that looks like this: >> @example >> @@@var{row}$@var{column} >> @end example >> >> The first use of @var is incorrect, @code should be used here. But >> the use in @var{row} and @var{column} is correct. >> >> I believe that a while ago we did use @var and @code correctly, but >> someone went through and changed the @code{org-...} to @var{org-...} >> at some point. We need to change this back. > > I believe reverting this commit should do it: > > commit 7ed97e767dd4f4fbceac39a9758dbf594a4fd2fd > Author: Bastien Guerry > Date: Mon Apr 15 00:51:20 2013 +0200 > > org.texi: Use @var{...} instead of @code{...} for variables > > * org.texi: Use @var{...} instead of @code{...} for variables. Yes, I agree. Let's wait for Bastien to take a last look at this, but it should indeed be reverted. - Carsten > > Cheers, > > -- > Suvayu > > Open source is the future. It sets us free.
Re: [O] variable names in manual
Hi Carsten, On Fri, Apr 26, 2013 at 10:10:32AM +0200, Carsten Dominik wrote: > > I suspect that the cases you are talking about here are due > to incorrect use of the texinfo command @var{}. This should > only be used for metasyntactical variables, when they stand > for something else in a description. > > Here is an example from the current manual. > > You can customize this behavior using the option > @var{org-table-use-standard-references}.} to use another, more general > representation that looks like this: > @example > @@@var{row}$@var{column} > @end example > > The first use of @var is incorrect, @code should be used here. But > the use in @var{row} and @var{column} is correct. > > I believe that a while ago we did use @var and @code correctly, but > someone went through and changed the @code{org-...} to @var{org-...} > at some point. We need to change this back. I believe reverting this commit should do it: commit 7ed97e767dd4f4fbceac39a9758dbf594a4fd2fd Author: Bastien Guerry Date: Mon Apr 15 00:51:20 2013 +0200 org.texi: Use @var{...} instead of @code{...} for variables * org.texi: Use @var{...} instead of @code{...} for variables. Cheers, -- Suvayu Open source is the future. It sets us free.
[O] Clocking totals in agenda view
Hi all, I've recently started looking at the time tracking facilities in org-mode, and in particular clocking time, which really is awesome. org-agenda-consistency-checks seems really useful, however I'd really like to add another similar overlay to the agenda that displays how much time was clocked on that day. Is this currently possible? R.
Re: [O] variable names in manual
On 26 apr. 2013, at 01:48, Suvayu Ali wrote: > On Thu, Apr 25, 2013 at 07:37:25PM -0400, Greg Minshall wrote: >> sorry about that. i was going to ask about the variable names in the >> current (8.x) documentation being in upper case. (then, wanted to check > > [...chomp...chomp...chomp...] > >> but, it means that placing the cursor over the name and hitting C-h v >> doesn't default to that name. (and, i've always found that a convenient >> way to navigate.) >> >> so, just curious is it might make sense to revert to lower case names. > > I wasn't aware of this change! I would agree with Greg here. I suspect that the cases you are talking about here are due to incorrect use of the texinfo command @var{}. This should only be used for metasyntactical variables, when they stand for something else in a description. Here is an example from the current manual. You can customize this behavior using the option @var{org-table-use-standard-references}.} to use another, more general representation that looks like this: @example @@@var{row}$@var{column} @end example The first use of @var is incorrect, @code should be used here. But the use in @var{row} and @var{column} is correct. I believe that a while ago we did use @var and @code correctly, but someone went through and changed the @code{org-...} to @var{org-...} at some point. We need to change this back. - Carsten > > -- > Suvayu > > Open source is the future. It sets us free. >
Re: [O] Using Eric Schulte's starter kit with org mode from source
Eric Schulte writes: >> As I don't install org from elpa, I removed the after-init-hook part (so >> I load the starter kit immediately), and everything now works. > > With my latest push to the starter kit you can now simply set the > ORG_HOME environment variable instead of modifying that file locally. > But it's largely a matter of taste at that point as both options are > functionally identical. Thanks a lot, but I would still need to load the relevant exporters (by putting them in some configuration file, or evaluated in the exported file itself). I find it simpler to have my whole configuration loaded before the export happens. Alan
Re: [O] hard coded autoload file
April, 26 at 8:36 Bastien wrote: >> It sucks for me as I generate autoload with a different name. I made a >> workaround so it's fine. > > Why do you generate autoloads with a different name? I do my own packaging. I started before ELPA and el-get existed. I was dissatisfied with the Debian way. Now I am still doing it to keep third-party packages in sync with my three computers. >> I think it would be better engineered no to have this stuff >> repeated at the end of each file. > > We follow the Calc exemple here: .el files for which autoloads need to > be in Emacs loaddefs.el don't have this local variable set, and files > for which autoloads are put into org-loaddefs.el do have this > variable. OK, I didn't know that Emacs has two autoload files. It makes sense now. > I can imagine some ad hoc function putting the autoloads were they > belong, but this would be ad hoc. I guess you'll have first to > explain why the current setup is problematic. There is no need to waste anymore time on this. I have a workaround. -- The power of accurate observation is commonly called cynicism by those who have not got it. -- George Bernard Shaw
[O] org-src-notify-natively and variable-pitch-mode interaction
I am typically using variable-pitch-mode=t when editing org-files. But embedded source code I would like to have in a fixed-pitch font. This works well when org-src-notify-natively is nil, but when turned on, part of the source code syntax highlightening (in my case python) is also turned into using variable pitch font. I realize this is because neither org-mode nor the syntax highlightening engine have a full cover of the various semantic parts, but both rely on the default font for part of their markup. Is there any way to work around this? Thanks! Dov
Re: [O] variable names in manual
Hi Suvayu, Suvayu Ali writes: > I believe that would be incorrect behaviour. > If I'm not mistaken, > emacs-lisp variable names are case sensitive. > > (setq test "lower case" > TEST "UPPER CASE") > > (message "%s, %s" test TEST) Sure, variable names are case sensitive, but it would be a problem for C-h v and C-h f to be case-insensitive only for variable names that have the same names but different cases -- not sure it's a real problem then... -- Bastien
Re: [O] variable names in manual
On 26 apr. 2013, at 01:48, Suvayu Ali wrote: > On Thu, Apr 25, 2013 at 07:37:25PM -0400, Greg Minshall wrote: >> sorry about that. i was going to ask about the variable names in the >> current (8.x) documentation being in upper case. (then, wanted to check > > [...chomp...chomp...chomp...] > >> but, it means that placing the cursor over the name and hitting C-h v >> doesn't default to that name. (and, i've always found that a convenient >> way to navigate.) >> >> so, just curious is it might make sense to revert to lower case names. > > I wasn't aware of this change! I would agree with Greg here. Can you point me to a place in the manual where this is the case? Are you talking about the infor documentation or HTML documentation? - Carsten > > -- > Suvayu > > Open source is the future. It sets us free. >
[O] Bug in org-capture-templates
Hi, i'm experiencing since some weeks a very strange bug (maybe). I have this simple template: (setq org-capture-templates '(("e" "email (persönlich)" entry (file+headline "~/Documents/org/privat.org" "Emails") "* TODO %^{Wem} schreiben SCHEDULED: %t :PROPERTIES: :Effort: 0:02 :END: %?"))) I get asked for the pesron I want write to, but the problem is that I can not write a name with a blank space (say: `Barack Obama') because I get an error `no match'. This was working without problems for years. I have org 8.0.1 (but this happened also with the last 7.9 version). Emacs: 24.3.1. Thanks in advance -- :: Igor Sosa Mayor :: joseleopoldo1...@gmail.com :: :: GnuPG: 0x1C1E2890 :: http://www.gnupg.org/ :: :: jabberid: rogorido ::::
[O] org-kill-line
I don't like the use of kill-visual-line in org-kill-mode as it creates non-predictable behavior when recording keyboard macros, as the display width will influence the result of running the macro. Does anyone have a suggestion of how to get around this? Right now I redefined kill-visual-line to kill-line, as I didn't want to touch the org-mode sources, but it seems to be an overkill (pun intended :-). Regards, Dov
Re: [O] variable names in manual
Hi Bastien, On Fri, Apr 26, 2013 at 08:56:19AM +0200, Bastien wrote: > Hi Greg, > > Greg Minshall writes: > > > but, it means that placing the cursor over the name and hitting C-h v > > doesn't default to that name. (and, i've always found that a convenient > > way to navigate.) > > > > so, just curious is it might make sense to revert to lower case > > names. > > IMHO this rather call for making C-h v (and C-h f) case-non-sensitive. > > Maybe you can fill an Emacs bug for this? M-x report-emacs-bug RET I believe that would be incorrect behaviour. If I'm not mistaken, emacs-lisp variable names are case sensitive. (setq test "lower case" TEST "UPPER CASE") (message "%s, %s" test TEST) The above prints "lower case, UPPER CASE". Cheers, -- Suvayu Open source is the future. It sets us free.
[O] Emacs completion on file:xyz links?
I often find reference files in org-files and then do the following sequence: * Press Ctrl-x Ctrl-f * Navigate to the requested file by the emacs and completion * Press Ctrl-a Ctrl-k to copy * Press Ctrl-g to get out of file-open * Paste with ctrl-y I was wondering if anyone has written code so that pressing [TAB] within a file:/ link would do emacs completion in place? Thanks! Dov
Re: [O] XML src block syntax highlighting
Hi Suvayu, Suvayu Ali schrieb: >On Thu, Apr 25, 2013 at 05:03:37PM +0200, Tom wrote: >> Suvayu Ali schrieb: >> >> >On Thu, Apr 25, 2013 at 11:57:49AM +0200, Tom wrote: >> >> >> >> #+BEGIN_SRC xml :exports code >> >> >> >> >> >> ... >> >> >> >> #+END_SRC >> >> >> >> I have org-src-fontify-natively = and it works for other code, but >> >xml >> >> is fontified as a fundamental buffer, not like nxml-mode shows the >> >> block contents. nxml-mode /is/ used when I use C-c ' to edit the >> >> contents. >> > >> >Can you try the following: >> > >> > #+BEGIN_SRC nxml :exports code >> >.. >> > #+END_SRC >> > >> >As far as I know, the language is supposed to be the leading part of >> >-mode. My information is a bit outdated, so I could be wrong. >> >> I should have written that in my OP: I tried that to no avail. >> >> I also tried >> >> (add-to-list 'org-src-lang-modes '("xml" . nxml)) > >Sorry, I cannot reproduce this. I tried (setq org-src-fontify-natively >t) and both of the following work for me. > > #+BEGIN_SRC xml :exports code >.. > #+END_SRC > > #+BEGIN_SRC nxml :exports code >.. > #+END_SRC > >Maybe it is your configuration? Did you try a binary search on it? >Comment out half of it at a time and you should be able to find the >problem lines in no time! Many thanks for checking - I found thw culprit. An old nxml version I installed agea ago via ELPA w > >GL, -- Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.