Re: [O] #+call split into multiple lines?
t...@tsdye.com (Thomas S. Dye) writes: > Aloha Eric, > > Eric Abrahamsen writes: > >> PS the (card=card-table[0,]) syntax is new to me, is that a >> Babel-specific construct? > > Do you mean the indexing into the table? That's described here: > > http://orgmode.org/manual/var.html#var > > in the section `Indexable variable values' near the bottom. Yes! Thank you. I'm in the process of wrapping my head around this stuff, and it's hard to keep all the pieces in place...
Re: [O] #+call split into multiple lines?
Aloha Eric, Eric Abrahamsen writes: > PS the (card=card-table[0,]) syntax is new to me, is that a > Babel-specific construct? Do you mean the indexing into the table? That's described here: http://orgmode.org/manual/var.html#var in the section `Indexable variable values' near the bottom. hth, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] #+call split into multiple lines?
"Sebastien Vauban" writes: > Hi Thomas, > > Thomas S. Dye wrote: >> In this situation I often put the arguments in a named Org table and >> then write the Babel source code block to take a single argument--the >> table name--and parse the information passed in that way. >> >> #+name: card-table >> | cname | gname | photo | etc.| >> | Dr. Stefan Vollmar | Stefan | stefan-vollmar.jpg| ... | >> | Dr. Stefan Vollmar, Jr. | Stefan Jr. | stefan-vollmar-jr.jpg | ... | >> >> >> #+call: mhead-hcard(card=card-table[0,]) for Stefan >> >> #+call: mhead-hcard(card=card-table[1,]) for Stefan Jr. >> >> If you don't mind writing some extra code for the Babel function, then >> >> #+call: mhead-hcard(card=card-table,gname="Stefan") >> >> etc. > > And do you eventually have a way to write a "for-loop" for all the lines of > the tables, not being forced to write as many calls as the number of lines you > do have? > > I don't see (immediately) how to do such, but that would really allow to > promote such a use case! I think Thomas means you store *all* your cards in a single table, and pass that entire table to the mhead-hcard function every time you call it. The function gets the whole table, and it is responsible for choosing which card(s) to pick from the table, and what to do with them. In Thomas' example, you could pass it an extra parameter and use that to pick a card. The loop you're talking about happens not outside of the #+call, but inside the function being #+call'd. Hope that's clear, E PS the (card=card-table[0,]) syntax is new to me, is that a Babel-specific construct?
[O] [PATCH] Process hlines in imported tables
Currently, there is no way to include an hline in an imported or
converted table. The `org-babel-import-elisp-from-file converts lines
starting with '-' (or '|-') to an integer 0, because, even though
`org-table-to-lisp' will correctly convert lines starting with "|-",
because `org-table-convert-region' always puts "| " at the begining of
each line.
This patch solves that by not putting a space after the pipe symbol if
the first character of the line is a dash ("-").
rick
>From 86ee5bfcaa7513769cc3e2939c5e0b1a1f3c7706 Mon Sep 17 00:00:00 2001
From: Rick Frankel
Date: Thu, 28 Mar 2013 21:34:06 -0400
Subject: [PATCH] When importing or converting table, convert rows starting
with "-" to horizontal (hlines).
* lisp/ob-core.el (org-babel-import-elisp-from-file): Check if row in
an array or 'hline.
* lisp/org-table.el (org-table-convert-region): Don't put space after
pipe symbol if line starts with '-', so `org-table-to-lisp' will
match the row against `org-table-hline-regexp'.
---
lisp/ob-core.el | 3 ++-
lisp/org-table.el | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/lisp/ob-core.el b/lisp/ob-core.el
index a63f77e..93b12b2 100644
--- a/lisp/ob-core.el
+++ b/lisp/ob-core.el
@@ -2537,7 +2537,8 @@ If the table is trivial, then return it as a scalar."
(org-table-import file-name separator)
(delete-file file-name)
(setq result (mapcar (lambda (row)
-(mapcar #'org-babel-string-read row))
+(if (eq row 'hline) 'hline
+ (mapcar #'org-babel-string-read row)))
(org-table-to-lisp
(error (message "Error reading results: %s" err) nil)))
(if (null (cdr result)) ;; if result is trivial vector, then scalarize it
diff --git a/lisp/org-table.el b/lisp/org-table.el
index f087cf7..da923cc 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -605,7 +605,8 @@ nil When nil, the command tries to be smart and figure
out the
(format "^ *\\| *\t *\\| \\{%d,\\}" separator)))
(t (error "This should not happen"
(while (re-search-forward re end t)
- (replace-match "| " t t)))
+ (replace-match
+(if (= (char-after) ?-) "|" "| ") t t)))
(goto-char beg)
(org-table-align)))
--
1.8.2
Re: [O] #+call split into multiple lines?
Aloha Seb, "Sebastien Vauban" writes: > Hi Thomas, > > Thomas S. Dye wrote: >> In this situation I often put the arguments in a named Org table and >> then write the Babel source code block to take a single argument--the >> table name--and parse the information passed in that way. >> >> #+name: card-table >> | cname | gname | photo | etc.| >> | Dr. Stefan Vollmar | Stefan | stefan-vollmar.jpg| ... | >> | Dr. Stefan Vollmar, Jr. | Stefan Jr. | stefan-vollmar-jr.jpg | ... | >> >> >> #+call: mhead-hcard(card=card-table[0,]) for Stefan >> >> #+call: mhead-hcard(card=card-table[1,]) for Stefan Jr. >> >> If you don't mind writing some extra code for the Babel function, then >> >> #+call: mhead-hcard(card=card-table,gname="Stefan") >> >> etc. > > And do you eventually have a way to write a "for-loop" for all the lines of > the tables, not being forced to write as many calls as the number of lines you > do have? > > I don't see (immediately) how to do such, but that would really allow to > promote such a use case! Not sure I understand your question. Perhaps I misunderstood Stefan's use case? There are several languages supported by Babel that have loop constructs. I was assuming that Stefan would use one of these when I suggested the possibility of writing some extra code. All the best, Tom -- Thomas S. Dye http://www.tsdye.com
Re: [O] BUG: ELPA package
Hi Will, wgreenhouse-sgozh3hwpm2stnjn9+b...@public.gmane.org (W. Greenhouse) writes: > When upgrading from one GNU ELPA package to the next (in my case, from > ELPA version org-20130318 to org-20130325), `load-path' is not refreshed > by installing the new package, which means that `org-reload' does not > work without manually fixing `load-path' and evaluating (load > "org"). Yes -- this is known limitation of the package installation mechanism. Here are the ELPA installation instructions in the manual: Recent Emacs distributions include a packaging system which lets you install Elisp libraries. You can install Org with M-x package-install RET org. You need to do this in a session where no .org file has been visited. The last sentence is the one important here. HTH, -- Bastien
Re: [O] Bugs x2: fast tag selection broken, column view broken?
On Thu, Mar 28, 2013 at 10:29:06PM +0100, Bastien wrote: > Hi Toby, > > Toby Cubitt writes: > > > I'm experiencing two unrelated new bugs in the latest git: > > > > 1. In agenda view, the list of fast-tag-selection keys in the > >`org-agenda-filter-by-tag' prompt is always empty, and fast tag > >selection no longer works. (I have fast-tag-selection keys configured > >in `org-tag-alist', and my `org-use-fast-tag-selection' is set to > >`auto'.) > > I fixed this. Thanks! > > 2. Column view mode is completely broken for me. In old org files where > >column view used to work fine, I now just get grey boxes obscuring the > >headings, and nothing in the columns. I've attached a minimal example > >file, and a screenshot. > > I can't reproduce this one. Can you reproduce it with emacs -Q? Hmmm... I can't reproduce it from emacs -Q. Sorry, I should of course have checked this first before posting. Must be something in my config. I'll investigate and try to narrow down what exactly is causing it. Best, Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Centre for Quantum Information and Foundations DAMTP, University of Cambridge email: ts...@cantab.net web: www.dr-qubit.org
Re: [O] [BUG] [ODT] Annotations break paragraphs
Ouch, I messed those illustrations up, and I suppose my message wasn't easy to understand to begin with. Sorry. > One thing to consider is whether this markup should support author and > timestamp info in a way that the parser should understand and pass on to > relevant backends. The annotation blocks do[note:1], because ODT does. For "[note:1]" in the above line, read "[note:2]"... Christian
Re: [O] org-mode 7.9.4 now returns org-strip-protective-commas
On Fri, Mar 22, 2013 at 1:54 PM, Nick Dokos wrote: > > > My guess is that you have a seriously mixed-up installation. It was a load-path problem. I use an init.el file to load my ~/.emacs.d/ emacs.org initialization file, and I totally forgot to update the path to the org directory in init.el.
Re: [O] Proposal for new/updated exporter tutorials on Worg
Started restructuring a bit. Here's what I have: |-- beamer | |-- index.org | |-- ox-beamer.org | |-- presentation.org | `-- tutorial.org |-- filter-markup.org |-- freemind.org |-- index.org |-- ox-overview.org |-- ox-template.org |-- taskjuggler.org `-- xoxo.org Prior to seeing index.org, I created ox-overview.org... seems like some index.org is similar to the exporter summary table I created. If there's no syntactical reason to have an index.org file, would the summary table replace this? I transformed the ob-doc-template file into ox-template.org and inserted some suggestions/hints on how to fill it in. It includes a "Reference" section suggesting that the creator add links to other tutorials and reference information as well as to the ox-*.el file itself. Most of the above is "as-is" (how I found it). If others want, each exporter could have it's own dir containing: - ox-*.org: documentation for language - ox-*-example.org: reproducible example for users to download and export - ox-*-compiled.*: end result file so users can compare their export to the "right" output, or simply see what they might achieve with the export backend. I'd like to do away with a dedicated tutorial and simply have this as part of ox-*.org. If the list wants, I could see leaving the names as =backend.org= or going with my original thought, which was =ox-backend.org=. I also plan to implement the following: - worg/org-8.0 will become an overview of general changes in Org-mode version 8.0 - General stuff - Some files moved from A to B - Lots of syntax changed - The exporter pertinent change information will be moved to worg.git/exporters/ox-overview.org (or ox-summary if that's preferred) - General information (I added a section to be filled in by Nicolas or someone else about reasons for the change and advantages) - File locations, naming conventions, etc. - .emacs setup syntax - Instruction for users to refer to the backend-specific documentation for proper syntax - The table like ob-languages that can be updated with links to Worg documentation as it is created - I also added links to the manual sections for each exporter where it exists - For everything else that's just about universal .org file options and setup, I propose ox-setup.org - #+TOC syntax - #+options syntax - Etc. - For anything else, it should live in it's backend-specific page My thinking on this is that Org-8.0 is a significant step, however it would be nice to write documentation as it pertains to Org 8.0 and not constantly in reference to how it's different from Org-7.x. Thus, current syntax can simply be written without having to worry about constantly referencing the older syntax. Make users well aware on the upgrade guide that there were significant changes, and then point them to the actual documentation, not documentation that is constantly written in the shadow of what it no longer is (if that makes sense). Let me know if there are any concerns with this approach! I haven't pushed the changes yet. Not sure on the ballpark release date for Org-8.0, but I'd like to at least clean up and finalize org-8.0.org, ox-overview.org, and ox-setup.org. I also plan to migrate stuff in org-tutorials over to worg.git/exporters. Thanks for any feedback! John
[O] run python from org, draft
Hi, as running python from org-source has been reported broken, herewith a patch, which allows basic usage. Requires python-mode.el-6.1 https://launchpad.net/python-mode/trunk/6.1.1/+download/python-mode.el-6.1.1.tar.gz Just a draft, not thought as implementation, Andreas diff --git a/lisp/ob-python.el b/lisp/ob-python.el index 7bc9a1f..2734bff 100644 --- a/lisp/ob-python.el +++ b/lisp/ob-python.el @@ -86,8 +86,11 @@ This function is called by `org-babel-execute-src-block'." (org-babel-expand-body:generic (concat body (if return-val (format "\nreturn %s" return-val) "")) params (org-babel-variable-assignments:python params))) - (result (org-babel-python-evaluate - session full-body result-type result-params preamble))) + (result + (py-send-string-return-output full-body) + ;; (org-babel-python-evaluate + ;; session full-body result-type result-params preamble) + )) (org-babel-reassemble-table result (org-babel-pick-name (cdr (assoc :colname-names params))
[O] BUG: ELPA package
Hi, When upgrading from one GNU ELPA package to the next (in my case, from ELPA version org-20130318 to org-20130325), `load-path' is not refreshed by installing the new package, which means that `org-reload' does not work without manually fixing `load-path' and evaluating (load "org"). I would expect the ELPA package to fix the load path automatically and maybe even run `org-reload' immediately after compilation. I was scared I might have to kill all my nice emacs-uptime because of this :) Org-mode version 7.9.4 (7.9.4-elpa @ /home/grml/.emacs.d/elpa/org-20130325/) GNU Emacs 24.2.1 (i486-pc-linux-gnu, GTK+ Version 3.4.2) of 2013-01-22 on biber, modified by Debian Best, Will -- BOFH excuse #2: solar flares
Re: [O] Bugs x2: fast tag selection broken, column view broken?
Hi Toby, Toby Cubitt writes: > I'm experiencing two unrelated new bugs in the latest git: > > 1. In agenda view, the list of fast-tag-selection keys in the >`org-agenda-filter-by-tag' prompt is always empty, and fast tag >selection no longer works. (I have fast-tag-selection keys configured >in `org-tag-alist', and my `org-use-fast-tag-selection' is set to >`auto'.) I fixed this. > 2. Column view mode is completely broken for me. In old org files where >column view used to work fine, I now just get grey boxes obscuring the >headings, and nothing in the columns. I've attached a minimal example >file, and a screenshot. I can't reproduce this one. Can you reproduce it with emacs -Q? Thanks! -- Bastien
Re: [O] #+call split into multiple lines?
Hi Thomas, Thomas S. Dye wrote: > In this situation I often put the arguments in a named Org table and > then write the Babel source code block to take a single argument--the > table name--and parse the information passed in that way. > > #+name: card-table > | cname | gname | photo | etc.| > | Dr. Stefan Vollmar | Stefan | stefan-vollmar.jpg| ... | > | Dr. Stefan Vollmar, Jr. | Stefan Jr. | stefan-vollmar-jr.jpg | ... | > > > #+call: mhead-hcard(card=card-table[0,]) for Stefan > > #+call: mhead-hcard(card=card-table[1,]) for Stefan Jr. > > If you don't mind writing some extra code for the Babel function, then > > #+call: mhead-hcard(card=card-table,gname="Stefan") > > etc. And do you eventually have a way to write a "for-loop" for all the lines of the tables, not being forced to write as many calls as the number of lines you do have? I don't see (immediately) how to do such, but that would really allow to promote such a use case! Best regards, Seb -- Sebastien Vauban
Re: [O] #+call split into multiple lines?
Aloha Stefan, In this situation I often put the arguments in a named Org table and then write the Babel source code block to take a single argument--the table name--and parse the information passed in that way. #+name: card-table | cname | gname | photo | etc.| | Dr. Stefan Vollmar | Stefan | stefan-vollmar.jpg| ... | | Dr. Stefan Vollmar, Jr. | Stefan Jr. | stefan-vollmar-jr.jpg | ... | #+call: mhead-hcard(card=card-table[0,]) for Stefan #+call: mhead-hcard(card=card-table[1,]) for Stefan Jr. If you don't mind writing some extra code for the Babel function, then #+call: mhead-hcard(card=card-table,gname="Stefan") etc. hth, Tom Stefan Vollmar writes: > Hallo, > > I am a new Org-Babel convert (thanks, Nicolas!) and our first project > replaces a MACRO (raw HTML template) with 12+ arguments and is a major > improvement as we can now use named arguments. > > This short example works: > > #+call: mhead-hcard(cname="Dr. Stefan > Vollmar",gname="Stefan",prefix="Dr.",web="stefan-vollmar.html",photo="stefan-vollmar.jpg") > :results html > > However, this only uses only four of 12+ arguments and - from my point > of view - already suffers from being written in one line. > > We have listed some of our attempts to increase readability (none of > them works with release_8.0-pre-193-gaa7b1e). > > (1) "natural" multi-line > > #+call: mhead-hcard( > cname="Dr. Stefan Vollmar", # full name for title > gname="Stefan", # given name > photo="stefan-vollmar.jpg", # can be jpg or png > ...) > > (2) Attempt in keeping with a multi-line #+header construct > > #+call: mhead-hcard( > #+call: cname="Dr. Stefan Vollmar", # full name for headline > #+call: gname="Stefan", # given name > #+call: photo="stefan-vollmar.jpg", # can be jpg or png > ... > > (3) Using a "line continuation marker" > > #+call: mhead-hcard( > cname="Dr. Stefan Vollmar",\ > gname="Stefan",\ > photo="stefan-vollmar.jpg",\ > ...) > > Maybe even with optional comments: > > #+call: mhead-hcard( > cname="Dr. Stefan Vollmar",\ # full name for headline > gname="Stefan",\ # given name > photo="stefan-vollmar.jpg",\ # can be jpg or png > ...) > > Maybe there already is a good solution to increase readability? Maybe > the "line continuation marker" (3) would be a general solution for all > cases in org where now no line breaks are possible? > > Many thanks for any help with this. > Warm regards, > Stefan -- Thomas S. Dye http://www.tsdye.com
Re: [O] [BUG] [ODT] Annotations break paragraphs
> Speaking of inlined elements, I repeat that [note:label] within the > paragraph should offer a good markup for annotations. I agree, and favor a move from annotation blocks to a solution like that.[note:1] [note:1] That is, like this? One thing to consider is whether this markup should support author and timestamp info in a way that the parser should understand and pass on to relevant backends. The annotation blocks do[note:1], because ODT does. [note:2] C.Moe <2013-03-28 Thu 21:34>: Except that they don't properly support it at the moment, as I brought up in another message. One could even use the author/timestamp information to form unique labels,[note:C.Moe_2013-03-28_21:37:26] but the labels would get long and messy. [note:C.Moe_2013-03-28_21:37:26] Like this. Yours, Christian
[O] #+call split into multiple lines?
Hallo, I am a new Org-Babel convert (thanks, Nicolas!) and our first project replaces a MACRO (raw HTML template) with 12+ arguments and is a major improvement as we can now use named arguments. This short example works: #+call: mhead-hcard(cname="Dr. Stefan Vollmar",gname="Stefan",prefix="Dr.",web="stefan-vollmar.html",photo="stefan-vollmar.jpg") :results html However, this only uses only four of 12+ arguments and - from my point of view - already suffers from being written in one line. We have listed some of our attempts to increase readability (none of them works with release_8.0-pre-193-gaa7b1e). (1) "natural" multi-line #+call: mhead-hcard( cname="Dr. Stefan Vollmar", # full name for title gname="Stefan", # given name photo="stefan-vollmar.jpg", # can be jpg or png ...) (2) Attempt in keeping with a multi-line #+header construct #+call: mhead-hcard( #+call: cname="Dr. Stefan Vollmar", # full name for headline #+call: gname="Stefan", # given name #+call: photo="stefan-vollmar.jpg", # can be jpg or png ... (3) Using a "line continuation marker" #+call: mhead-hcard( cname="Dr. Stefan Vollmar",\ gname="Stefan",\ photo="stefan-vollmar.jpg",\ ...) Maybe even with optional comments: #+call: mhead-hcard( cname="Dr. Stefan Vollmar",\ # full name for headline gname="Stefan",\ # given name photo="stefan-vollmar.jpg",\ # can be jpg or png ...) Maybe there already is a good solution to increase readability? Maybe the "line continuation marker" (3) would be a general solution for all cases in org where now no line breaks are possible? Many thanks for any help with this. Warm regards, Stefan -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleueler Str. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 E-Mail: voll...@nf.mpg.de http://www.nf.mpg.de smime.p7s Description: S/MIME cryptographic signature
Re: [O] :session question - a simple PATCH
John Hendy writes: [...] > > Haven't really been following along, but this works for me (after execution): > > #+begin_src emacs-lisp > (setq org-babel-default-header-args:R > '((:session . "org-R"))) > #+end_src > > > These aren't: > > -*- org-babel-default-header-args:R: ((:session . "foo")) -*- > > #-*- org-babel-default-header-args:R: ((:session . "foo")) -*- > > There were a lot of suggestions made above and I've never used the > -*-setting-*- syntax and am not searching the right things to find out > more about how this is supposed to work. > > ETA: Ah, I had to re-open the file after adding this to the buffer to > get it to recognize it: > > # Local Variables: > # org-babel-default-header-args:R: ((:session . "foo")) > # End: > > This produces the same issue as you, Andreas: > > Wrong type argument: sequencep, R: > > > Not sure. I'm on 8.0-pre (release_8.0-pre-193-gaa7b1e). > > > John > Hi all, so it seems, currently, I (and John...) can not have both, /file local/ and /language local/ variables. - The emacs-lisp-block #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . "org-R"))) #+end_src works, of course, but sets the R-session globally. - The file-local variables (both way to set them) choke on the colon in the varible name. I do not know where to search for the reason, these variables work for Eric but not for me (and John...). So attached is a simple patch (search-and-replace) that renames all org-babel-default-header-args:* variables to org-babel-default-header-args-* I do not see any problems with this renaming, but as I have only limited elisp, that might not mean too much. This fixes the issue for me at the cost of breaking other people's setup if they use org-babel-default-header-args:* variants. What do you think? Regards, Andreas >From 91965d0fc8820f9c0b68728368d3d8062d8c49ef Mon Sep 17 00:00:00 2001 From: Andreas Leha Date: Thu, 28 Mar 2013 16:45:33 +0100 Subject: [PATCH] Renamed vars org-babel-default-header-args:* to org-babel-default-header-args-* This makes them usable in file local variables. --- contrib/lisp/ob-eukleides.el |2 +- contrib/lisp/ob-fomus.el |2 +- contrib/lisp/ob-julia.el |2 +- contrib/lisp/ob-mathomatic.el|2 +- contrib/lisp/ob-tcl.el |2 +- lisp/ob-C.el |2 +- lisp/ob-R.el |2 +- lisp/ob-asymptote.el |2 +- lisp/ob-calc.el |2 +- lisp/ob-clojure.el |2 +- lisp/ob-core.el |4 ++-- lisp/ob-css.el |2 +- lisp/ob-ditaa.el |2 +- lisp/ob-dot.el |2 +- lisp/ob-emacs-lisp.el|2 +- lisp/ob-exp.el |2 +- lisp/ob-fortran.el |2 +- lisp/ob-gnuplot.el |2 +- lisp/ob-haskell.el |2 +- lisp/ob-io.el|2 +- lisp/ob-js.el|2 +- lisp/ob-latex.el |2 +- lisp/ob-ledger.el|2 +- lisp/ob-lilypond.el |6 +++--- lisp/ob-lisp.el |2 +- lisp/ob-makefile.el |2 +- lisp/ob-maxima.el|2 +- lisp/ob-mscgen.el|2 +- lisp/ob-ocaml.el |2 +- lisp/ob-octave.el|4 ++-- lisp/ob-org.el |2 +- lisp/ob-perl.el |2 +- lisp/ob-picolisp.el |2 +- lisp/ob-plantuml.el |2 +- lisp/ob-python.el|2 +- lisp/ob-ruby.el |2 +- lisp/ob-sass.el |2 +- lisp/ob-scala.el |2 +- lisp/ob-scheme.el|2 +- lisp/ob-screen.el|4 ++-- lisp/ob-sh.el|2 +- lisp/ob-shen.el |2 +- lisp/ob-sql.el |2 +- lisp/ob-sqlite.el|2 +- testing/lisp/test-ob-lilypond.el |8 45 files changed, 53 insertions(+), 53 deletions(-) diff --git a/contrib/lisp/ob-eukleides.el b/contrib/lisp/ob-eukleides.el index e25ed1c..3747b4e 100644 --- a/contrib/lisp/ob-eukleides.el +++ b/contrib/lisp/ob-eukleides.el @@ -37,7 +37,7 @@ (require 'ob) (require 'ob-eval) -(defvar org-babel-default-header-args:eukleides +(defvar org-babel-default-header-args-eukleides '((:results . "file") (:exports . "results")) "Default arguments for evaluating a eukleides source block.") diff --git a/contrib/lisp/ob-fomus.el b/contrib/lisp/ob-fomus.el index 58183fb..8914843 100644 --- a/contrib/lisp/ob-fomus.el +++ b/contrib/lisp/ob-fomus.el @@ -42,7 +42,7 @@ (require 'ob) (require 'ob-eval) -(defvar org-babel-default-header-args:fomus +(defvar org-babel-default-header-args-fomus '((:results . "file") (:exports . "results")) "Default a
Re: [O] [BUG] [ODT] Annotations break paragraphs
Am 28.03.2013 15:41, schrieb Nicolas Goaziou: Then you're contradicting yourself, since you also said: I suggest to follow the lead of (La)TeX and determine begin and end of such blocks by blank lines. In your example, the end of the "P-block" isn't at the blank line. My comment was on that precise part of your message. A P-block cannot end inside a special block, just as you don't end a paragraph inside an inline footnote. The syntax wouldn't change all that much, except that blank lines would need to be made tokens during parsing. This is not only about blank lines. Remember your example: There is an annotation by the original author here #+BEGIN_ANNOTATION I never meant to break this paragraph. #+END_ANNOTATION in the middle of the paragraph. There is no blank line, and, yet, it should be parsed differently than it is actually. Therefore, it's not just about blank lines. It's about allowing indirectly paragraphs within paragraphs. Well, obviously this example erred on the side of brevity: the begin and the end of the document impllicitly begin and end the single P-block, which was the point. 8< * Heading ** Sub-Heading *** Sub-Sub-Heading Let's start a single paragraph. There is an annotation by the original author here #+BEGIN_ANNOTATION I never meant to break this paragraph. But here's a second one in the annotation, still not braking the outer paragraph. #+END_ANNOTATION in the middle of the paragraph. Here's another paragraph. >8 This would be parsed as: 8< begin_p-block end_p-block begin_p-block end_p-block begin_p-block end_p-block >8 Do not misunderstand me: I agree that the current paragraph model is restricted. But remember we're working with plain text which should be readable as plain text, not with a full-fledged XML-like markup. The strength of this paragraph definition lies in its simplicity. And I am impressed about how much is done with such a simple syntax. Again and maybe I'm expressing myself too poorly, I don't suggest to change that model. It is working well for Org as far as I can tell. What I'm suggesting is an extension of that model, ostensibly to help supporting more complex models for exporting. To this end blank lines must either be handed explicitly to the exporter and not gobbled up by org-element or org-element could extract P-blocks as shown above. IMO, this kind of syntax, i.e. mixing blocks and paragraphs, is just ugly. It makes it impossible to read property the paragraph and emphasizes the annotation, which is counter-productive. What about tables, images, listings, equations? You already have that very problem (each of those break the paragraph around them) in many forms. You can fix them one by one and tweak heuristics in the exporter for the next two years or you can provide a general mechanism to deal with that situation. A good rule of thumb is that blocks should be used as containers, never as inlined elements. That's why the exported paragraph must be a separate entity from what Org calls a paragraph: there are many block elements in Org that can and should possibly be expüorted as inlined elements in the what gets exported as a paragraph. Speaking of inlined elements, I repeat that [note:label] within the paragraph should offer a good markup for annotations. While I agree that this is a good solution for annotations and mimics the way inline footnotes work, it introduces a new syntactical element only for escaping that limitation. Now, when you think about LaTeX blocks you can't treat them the same easily, but there really is no good reason why an equation array should introduce an unwanted paragraph boundary in LaTeX (again, I'm not talking about the paragraph boundaries in Org). Regards, -- Achim. (on the road :-) -- Achim. (on the road :-)
Re: [O] Bug: Export of table.el to LaTeX fails [7.9.4 (7.9.4-dist @ c:/Users/kwilliams/share/emacs/site-lisp/org/)]
> -Original Message- > From: Nicolas Goaziou [mailto:n.goaz...@gmail.com] > Sent: Thursday, March 28, 2013 10:49 AM > To: Ken Williams > > Ken Williams writes: > > > Something apparently even ate part of the attachment - there are some > > Null bytes in there I guess. Here's a paste of the rest of the > > attachment, as viewed in `less` to zap the non-ASCIIs. > > FWIW, I cannot reproduce the problem on Org-mode version 8.0-pre > (release_8.0-pre-199-g2746c7) I can't upgrade to 8.0 here, is there anyone that could try on a 7.x platform to confirm? Are all those Null bytes & line noise in the stack trace normal, or do they look like some kind of buffer overflow or something? -Ken CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution of any kind is strictly prohibited. If you are not the intended recipient, please contact the sender via reply e-mail and destroy all copies of the original message. Thank you.
Re: [O] A t-shirt idea;)
Dnia 2013-03-28, o godz. 10:54:07 Karl Voit napisał(a): > * Marcin Borkowski wrote: > > Dnia 2013-03-27, o godz. 19:34:45 > > Jude DaShiell napisał(a): > > > >> Maybe something like: > >> Feng Shui for your computer, > >> ORG-MODE! > >> would work. > > > > Well, I have strong negative associations with feng shui, so I guess > > not. > > ... and you have positive associations with the Borg? > > *SCNR* ;-) > +1 xD -- Marcin Borkowski http://octd.wmi.amu.edu.pl/en/Marcin_Borkowski Adam Mickiewicz University
[O] Bugs x2: fast tag selection broken, column view broken?
I'm experiencing two unrelated new bugs in the latest git: 1. In agenda view, the list of fast-tag-selection keys in the `org-agenda-filter-by-tag' prompt is always empty, and fast tag selection no longer works. (I have fast-tag-selection keys configured in `org-tag-alist', and my `org-use-fast-tag-selection' is set to `auto'.) 2. Column view mode is completely broken for me. In old org files where column view used to work fine, I now just get grey boxes obscuring the headings, and nothing in the columns. I've attached a minimal example file, and a screenshot. Toby -- Dr T. S. Cubitt Royal Society University Research Fellow Centre for Quantum Information and Foundations DAMTP, University of Cambridge email: ts...@cantab.net web: www.dr-qubit.org column-view.org Description: Lotus Organizer <>
Re: [O] [ox-publish] handling of white space in arguments of macros, named arguments?
Am 28.03.2013 17:22, schrieb Nicolas Goaziou: My point is that macro templates have to fit in a single line, no newline character allowed. As a consequence, macro arguments are implicitly expected to fit in a single line. So a newline character in an argument is probably wrong. My point is that the form of the template really doesn't tell you much about the (possibly recursive) expansion and since the feature is relatively new there is absolutely no data to determine if such an assumption would restrict macros too much. I can certainly see good uses of linebreaks in macro expansions. The current trend for macros is to be really simple so that advanced (and not-so advanced) tasks are done with Babel instead. IOW, macros are only useful if they are simpler than the simplest form of Babel usage. In this case, you probly can't or how do you get linebreaks into arguments of a Babel call (not using escape sequences)? In every other case, Babel is a superior choice. I think that there is some middle ground to cover here. There is no reason to ask for confirmation in the example you gave for the vcard insertion, for example. All it does is a simple template expansion, in other words it acts like a multi-line macro definition with named parameters. Your suggestion is interesting, but I think it would go backwards wrt this. Babel is very nice, but I don't think we should foist it onto everyone, there are good reasons to stick to plain Org in some situations. The evaluation confirmation should get a bit smarter, too, but I don't see how to do that easily (I've already looked). The way things work at the moment you have to globally switch off confirmation for all but the most simple uses of Babel. Regards, -- Achim. (on the road :-)
Re: [O] Org-mode as a replacement for Google Reader
Jude DaShiell writes: > Now, how to get from what's in info newsticker to actually adding a > real feed and have newsticker work is another matter entirely. I gave it a quick try, and found frustrating that it looks attractive in its display and specs, that it seems to be nicely done at first glance, but that it invariably throws Emacs in what seems to be an infinite CPU loop, leaving me no choice than to kill Emacs each time. Sigh! François
Re: [O] Capture/store link bug
Bastien writes: > Hi Matt, > > I pushed a fix for this yesterday. Storing links from every line in > the active region is now achieved when the user hits three C-u before > the command. > > Let me know if it works for you! And thanks for reporting bugs in > this important area. It works great! Thanks for fixing this. Best, Matt
Re: [O] [ox-publish] handling of white space in arguments of macros, named arguments?
Hello, Achim Gratz writes: > Am 27.03.2013 17:26, schrieb Nicolas Goaziou: >> I think all newline characters should be replaced with a whitespace >> character in macro arguments. Indeed, macro templates are only one line >> long but unwanted "\n" could be inserted by paragraph filling in >> arguments. > > I'm not sure about that, it would mean that there'd need to be > additional syntax to insert linebreaks. My point is that macro templates have to fit in a single line, no newline character allowed. As a consequence, macro arguments are implicitly expected to fit in a single line. So a newline character in an argument is probably wrong. >> I also don't mind trimming arguments again, provided this is added as an >> explicit behaviour and there is no opposition to it. > > How about making trimming explicit during the expansion of macro > arguments? It seems that there are a few possibilities of what > trimming could mean, so this would be an opportunity to allow them all > (n is the argument number): > > $:n - remove whitespace and linebreaks before argument > $.n - remove whitespace and linebreaks after argument > $n - same as $:.n > $+n - replace whitespace and linebreaks inside arguments >with a single space > $*n - same as $:+.n > $~n - literal argument (no trimming) The current trend for macros is to be really simple so that advanced (and not-so advanced) tasks are done with Babel instead. IOW, macros are only useful if they are simpler than the simplest form of Babel usage. In every other case, Babel is a superior choice. Your suggestion is interesting, but I think it would go backwards wrt this. Regards, -- Nicolas Goaziou
Re: [O] Bug: Export of table.el to LaTeX fails [7.9.4 (7.9.4-dist @ c:/Users/kwilliams/share/emacs/site-lisp/org/)]
Hello, Ken Williams writes: > Something apparently even ate part of the attachment - there are some > Null bytes in there I guess. Here's a paste of the rest of the > attachment, as viewed in `less` to zap the non-ASCIIs. FWIW, I cannot reproduce the problem on Org-mode version 8.0-pre (release_8.0-pre-199-g2746c7) Regards, -- Nicolas Goaziou
Re: [O] Bug: Export of table.el to LaTeX fails [7.9.4 (7.9.4-dist @ c:/Users/kwilliams/share/emacs/site-lisp/org/)]
Something apparently even ate part of the attachment - there are some Null
bytes in there I guess. Here's a paste of the rest of the attachment, as
viewed in `less` to zap the non-ASCIIs.
-Ken
Debugger entered--Lisp error: (error "Invalid search bound (wrong side of
point)")
re-search-forward("\\s *\\'" 53 t)
table--buffer-substring-and-trim(54 53)
#[514
"\307\310^C\302@B!\310^C\302@B!\"\311\312!r\211q\210\313\314\315\316\317\320^F^F!\321\"\322\323%DC\216^Ac\210eb\210\324\325\326\327#\203_^@\330\224\203E^@\212\330\224b\210\331c\210)\202,^@\322\224\203S^@\332\333\327\211#\210\202,^@\332\334\335\336!\334Q!\210\202,^@ed{\262^B*\210r\300q\210\306@\204\200^@`Sf\337=\203{^@\340\202|^@\341\342\261^B\210\305@\330V\203\234^@\343\344\305@\306@\203\224^@\345\202\225^@\340^D$c\210\202\237^@\211c\210)\306\326\240\210\305\330\240\210\303\304@\3018\240\207"
[# (1 12) (5) (12) (2) (1) (nil)
table--buffer-substring-and-trim table--goto-coordinate generate-new-buffer "
*temp*" funcall make-byte-code 0 "\301\300!\205 ^@\302\300!\207" vconcat
vector [buffer-name kill-buffer] 2 "\n\n(fn)" re-search-forward
"\\([#$~_^%{}]\\)\\|\\(\\)\\|\\([<>|]\\)" nil t 1 "\\" replace-match
"$\\backslash$" "$" match-string 3 32 "" " " "& " format
"\\multicolumn{%d}{%sl|}{%s}" "|"] 11 "\n\n(fn FROM TO)"](12 11)
table--generate-source-scan-lines(# latex (43 .
53) (101 . 111) (1 12) (5 7))
table-generate-source(latex "*org-export-table*" "caption")
org-export-latex-convert-table\.el-table()
org-export-latex-tables(t)
org-export-latex-content(#("\n\nExample:\n\n+--+---+\n|Name
|Examples |\n+--+---+\n|foo |x ... y
|\n+--+---+\n\n\n" 0 12 (fontified t) 12 24 (fontified t)
24 40 (fontified t) 40 41 (fontified t) 41 69 (fontified t org-caption nil
org-caption-shortn nil org-attributes nil org-label nil) 69 70 (fontified t) 70
82 (fontified t) 82 98 (fontified t) 98 99 (fontified t) 99 127 (fontified t
org-caption nil org-caption-shortn nil org-attributes nil org-label nil) 127
128 (fontified t) 128 140 (fontified t) 140 156 (fontified t) 156 159
(fontified t)))
org-export-latex-subcontent(((pos . 2) (level . 1) (occur . 1) (heading . #("
Failing table " 1 2 (target "sec-1" fontified t) 2 14 (target "sec-1" fontified
t))) (content . #("\n\nExample:\n\n+--+---+\n|Name
|Examples |\n+--+---+\n|foo |x ... y
|\n+--+---+\n\n\n" 0 12 (fontified t) 12 24 (fontified t)
24 40 (fontified t) 40 41 (fontified t) 41 69 (fontified t org-caption nil
org-caption-shortn nil org-attributes nil org-label nil) 69 70 (fontified t) 70
82 (fontified t) 82 98 (fontified t) 98 99 (fontified t) 99 127 (fontified t
org-caption nil org-caption-shortn nil org-attributes nil org-label nil) 127
128 (fontified t) 128 140 (fontified t) 140 156 (fontified t) 156 159
(fontified t))) (subcontent)) t)
#[(x) "\30\"\207" [x num org-export-latex-subcontent] 3](((pos . 2)
(level . 1) (occur . 1) (heading . #(" Failing table " 1 2 (target "sec-1"
fontified t) 2 14 (target "sec-1" fontified t))) (content .
#("\n\nExample:\n\n+--+---+\n|Name |Examples
|\n+--+---+\n|foo |x ... y
|\n+--+---+\n\n\n" 0 12 (fontified t) 12 24 (fontified t)
24 40 (fontified t) 40 41 (fontified t) 41 69 (fontified t org-caption nil
org-caption-shortn nil org-attributes nil org-label nil) 69 70 (fontified t) 70
82 (fontified t) 82 98 (fontified t) 98 99 (fontified t) 99 127 (fontified t
org-caption nil org-caption-shortn nil org-attributes nil org-label nil) 127
128 (fontified t) 128 140 (fontified t) 140 156 (fontified t) 156 159
(fontified t))) (subcontent)))
mapc(#[(x) "\30 \"\207" [x num org-export-latex-subcontent] 3] (((pos .
2) (level . 1) (occur . 1) (heading . #(" Failing table " 1 2 (target "sec-1"
fontified t) 2 14 (target "sec-1" fontified t))) (content .
#("\n\nExample:\n\n+--+---+\n|Name |Examples
|\n+--+---+\n|foo |x ... y
|\n+--+---+\n\n\n" 0 12 (fontified t) 12 24 (fontified t)
24 40 (fontified t) 40 41 (fontified t) 41 69 (fontified t org-caption nil
org-caption-shortn nil org-attributes nil org-label nil) 69 70 (fontified t) 70
82 (fontified t) 82 98 (fontified t) 98 99 (fontified t) 99 127 (fontified t
org-caption nil org-caption-shortn nil org-attributes nil org-label nil) 127
128 (fontified t) 128 140 (fontified t) 140 156 (fontified t) 156 159
(fontified t))) (subcontent
org-export-latex-subpos . 2) (level . 1) (occur . 1) (heading . #("
Failing table " 1 2 (target "sec-1" fontified t) 2 14 (target "sec-1" fontified
t))) (content . #("\n\nExample:\n\n+--+---+\n|Name
|Examples |\n+--+---+\n|foo |x ... y
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hello, Achim Gratz writes: >> It wouldn't allow paragraphs within the annotation. > > ??? > > 8< > There is an annotation by the original author here > #+BEGIN_ANNOTATION >I never meant to break this paragraph. > >But here's a second one in the annotation, >still not braking the outer paragraph. > #+END_ANNOTATION > in the middle of the paragraph. > >8 Then you're contradicting yourself, since you also said: I suggest to follow the lead of (La)TeX and determine begin and end of such blocks by blank lines. In your example, the end of the "P-block" isn't at the blank line. My comment was on that precise part of your message. >> Anyway, every back-end has its own interpretation of what a paragraph >> is. Some back-ends don't even know what a paragraph is. Org cannot fit >> them all. > > That's why Org can't impose its much more restricted paragraph model on > backends with different paragraph models. As I explained, it doesn't impose anything on back-ends: it merely offers its reasonable view. You can always ignore its definition, as written just below. >> On the other hand, as the ox-odt patch somehow demonstrates, it is >> possible for a back-end to ignore Org paragraph definition and rolls its >> own. It requires some additional code, but I'm open to discussion about >> implementing tools in ox.el in order to ease the process. > > Yes, and footnotes with paragraphs... Anyway, for me this is the main > sticking point with how Org syntax is defined, because it currently > implies Org syntax == Backend semantics, which is simply not the case > for most if not all backends. You're stating the obvious. Org syntax is indeed different from back-end semantics. Otherwise, we wouldn't need export back-ends to do the transcoding job, would we? > Working around this in each and every backend doesn't look appealing. It didn't prevent dedicated people to rewrite almost all previous back-ends and implement additional ones. >> In any case, I think we ought to keep raw Org syntax as simple as >> possible. The current definition of a paragraph is simple enough. > > The syntax wouldn't change all that much, except that blank lines would > need to be made tokens during parsing. This is not only about blank lines. Remember your example: There is an annotation by the original author here #+BEGIN_ANNOTATION I never meant to break this paragraph. #+END_ANNOTATION in the middle of the paragraph. There is no blank line, and, yet, it should be parsed differently than it is actually. Therefore, it's not just about blank lines. It's about allowing indirectly paragraphs within paragraphs. Do not misunderstand me: I agree that the current paragraph model is restricted. But remember we're working with plain text which should be readable as plain text, not with a full-fledged XML-like markup. The strength of this paragraph definition lies in its simplicity. And I am impressed about how much is done with such a simple syntax. IMO, this kind of syntax, i.e. mixing blocks and paragraphs, is just ugly. It makes it impossible to read property the paragraph and emphasizes the annotation, which is counter-productive. A good rule of thumb is that blocks should be used as containers, never as inlined elements. Speaking of inlined elements, I repeat that [note:label] within the paragraph should offer a good markup for annotations. Regards, -- Nicolas Goaziou
[O] Bug: Export of table.el to LaTeX fails [7.9.4 (7.9.4-dist @ c:/Users/kwilliams/share/emacs/site-lisp/org/)]
My email client seems to be eating the formatting in the bug report, so I'm
attaching it as a text file. Hope that's okay.
-Ken
CONFIDENTIALITY NOTICE: This e-mail message is for the sole use of the intended
recipient(s) and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution of any kind is strictly
prohibited. If you are not the intended recipient, please contact the sender
via reply e-mail and destroy all copies of the original message. Thank you.
To: emacs-orgmode@gnu.org
Subject: Bug: Export of table.el to LaTeX fails [7.9.4 (7.9.4-dist @
c:/Users/kwilliams/share/emacs/site-lisp/org/)]
From: ken.willi...@windlogics.com
--text follows this line--
Remember to cover the basics, that is, what you expected to happen and
what in fact did happen. You don't know how to make a good report? See
http://orgmode.org/manual/Feedback.html#Feedback
Your bug report will be posted to the Org-mode mailing list.
When I try to export the following example document to LaTeX, I get a
failure "Invalid search bound (wrong side of point)". The key piece
seems to be the '...' string in the 4th cell.
=
#+TITLE: Example Doc
#+AUTHOR: Ken Williams
* Failing table
Example:
+--+---+
|Name |Examples |
+--+---+
|foo |x ... y|
+--+---+
=
Here's a stack trace:
Debugger entered--Lisp error: (error "Invalid search bound (wrong side of
point)")
re-search-forward("\\s *\\'" 53 t)
table--buffer-substring-and-trim(54 53)
#[514
"\307\310\302@B!\310\302@B!\"\311\312!r\211q\210\313\314\315\316\317\320!\321\"\322\323%DC\216c\210eb\210\324\325\326\327#\203_ \330\224\203E \212\330\224b\210\331c\210)\202, \322\224\203S \332\333\327\211#\210\202, \332\334\335\336!\334Q!\210\202, ed{\262*\210r\300q\210\306@\204\200 `Sf\337=\203{ \340\202| \341\342\261\210\305@\330V\203\234 \343\344\305@\306@\203\224 \345\202\225 \340$c\210\202\237 \211c\210)\306\326\240\210\305\330\240\210\303\304@\3018\240\207"
[# (1 12) (5) (12) (2) (1) (nil)
table--buffer-substring-and-trim table--goto-coordinate generate-new-buffer "
*temp*" funcall make-byte-code 0 "\301\300!\205 \302\300!\207" vconcat vector
[buffer-name kill-buffer] 2 "\n\n(fn)" re-search-forward
"\\([#$~_^%{}]\\)\\|\\(\\)\\|\\([<>|]\\)" nil t 1 "\\" replace-match
"$\\backslash$" "$" match-string 3 32 "" " " "& " format
"\\multicolumn{%d}{%sl|}{%s}" "|"] 11 "\n\n(fn FROM TO)"](12 11)
table--generate-source-scan-lines(# latex (43 .
53) (101 . 111) (1 12) (5 7))
table-generate-source(latex "*org-export-table*" "caption")
org-export-latex-convert-table\.el-table()
org-export-latex-tables(t)
org-export-latex-content(#("\n\nExample:\n\n+--+---+\n|Name
|Examples |\n+--+---+\n|foo |x ... y
|\n+--+---+\n\n\n" 0 12 (fontified t) 12 24 (fontified t)
24 40 (fontified t) 40 41 (fontified t) 41 69 (fontified t org-caption nil
org-caption-shortn nil org-attributes nil org-label nil) 69 70 (fontified t) 70
82 (fontified t) 82 98 (fontified t) 98 99 (fontified t) 99 127 (fontified t
org-caption nil org-caption-shortn nil org-attributes nil org-label nil) 127
128 (fontified t) 128 140 (fontified t) 140 156 (fontified t) 156 159
(fontified t)))
org-export-latex-subcontent(((pos . 2) (level . 1) (occur . 1) (heading . #("
Failing table " 1 2 (target "sec-1" fontified t) 2 14 (target "sec-1" fontified
t))) (content . #("\n\nExample:\n\n+--+---+\n|Name
|Examples |\n+--+---+\n|foo |x ... y
|\n+--+---+\n\n\n" 0 12 (fontified t) 12 24 (fontified t)
24 40 (fontified t) 40 41 (fontified t) 41 69 (fontified t org-caption nil
org-caption-shortn nil org-attributes nil org-label nil) 69 70 (fontified t) 70
82 (fontified t) 82 98 (fontified t) 98 99 (fontified t) 99 127 (fontified t
org-caption nil org-caption-shortn nil org-attributes nil org-label nil) 127
128 (fontified t) 128 140 (fontified t) 140 156 (fontified t) 156 159
(fontified t))) (subcontent)) t)
#[(x) "\302 \"\207" [x num org-export-latex-subcontent] 3](((pos . 2)
(level . 1) (occur . 1) (heading . #(" Failing table " 1 2 (target "sec-1"
fontified t) 2 14 (target "sec-1" fontified t))) (content .
#("\n\nExample:\n\n+--+---+\n|Name |Examples
|\n+--+---+\n|foo |x ... y
|\n+--+---+\n\n\n" 0 12 (fontified t) 12 24 (fontified t)
24 40 (fontified t) 40 41 (fontified t) 41 69 (fontified t org-caption nil
org-caption-shortn nil org-attributes nil org-label nil) 69 70 (fontified t) 70
82 (fontified t) 82 98 (fontified t) 98 99 (fontified t) 99 127 (fontified t
org-cap
[O] SQL result as a single string, rather than table?
I'd like to be able to put a result from SQL inline into my exported
document. Something like this:
Latest database record is from src_sql[:colnames no :results scalar]{select
DATE(CreatedAt) from Event order by CreatedAt desc limit 1;}.
In that case, the SQL result almost works (it surrounds the results with
=...=), but at least on my Windows machine there is an extra ^M and newline
in there. I'd be happy to submit a patch to strip whitespace from the end
of the line in scalar mode, if people think that's a good idea.
In fact here's what I propose:
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 658a54f..ac999f4 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -138,7 +138,8 @@ This function is called by
`org-babel-execute-src-block'."
(org-babel-eval command "")
(org-babel-result-cond result-params
(with-temp-buffer
- (progn (insert-file-contents-literally out-file) (buffer-string)))
+ (progn (insert-file-contents-literally out-file)
+ (replace-regexp-in-string "[ \t\r\n]*$" "" (buffer-string
(with-temp-buffer
(cond
((or (eq (intern engine) 'mysql)
--
Gary
Re: [O] :session question
On Wed, Mar 27, 2013 at 3:35 PM, Eric Schulte wrote: > Andreas Leha writes: > > [...] >> >> Is that just not working for me? And any ideas, what I could do about >> it? >> > > I have no good ideas. Is the `org-babel-default-header-args:R' variable > defined on your system before you load this file? If not, maybe you > should be sure to add > > (require 'ob-R) > > to your emacs initialization. If the ":" in the variable name is > somehow confusing your Emacs, then possibly you could use the alternate > format of specifying file local variables (see the info link in my > attached example). > By "alternate" do you mean: # Local Variables: # stuff # End: vs. -*-stuff-*- ? If so, this isn't working for me either (I get "malformed modeline"): -*- org-babel-default-header-args:R: ((:session . "foo")) -*- I read through the *info* on local file variables and both of the above seem like they should be correct. Wouldn't it be the colon? Emacs is looking for VAR:VALUE. Here's from files.el, which contains the function =hack-local-variables=. While not an elisper, this looks like it wouldn't figure out two colons: (while (and (not (eobp)) (or (not mode-only) (not result))) ;; Find the variable name; strip whitespace. (skip-chars-forward " \t") (setq beg (point)) (skip-chars-forward "^:\n") (if (eolp) (error "Missing colon in local variables entry")) (skip-chars-backward " \t") Isn't this sort of saying, "split up the var:value pair by starting at line beginning, going to the first =:=, and then looking for a newline? If so, I'd take the execution as trying to set: =org-babel-default-header-args= to a value of =R: ((:session . "foo"))= John > I hope one of these works, aside from that I have no idea why our Emacs > versions would differ in such fundamental behavior. > > Cheers, > > -- > Eric Schulte > http://cs.unm.edu/~eschulte >
Re: [O] :session question
On Thu, Mar 28, 2013 at 5:25 AM, Andreas Leha wrote: > Hi Eric, > > Eric Schulte writes: > >> Andreas Leha writes: >> >> [...] >>> >>> Is that just not working for me? And any ideas, what I could do about >>> it? >>> >> >> I have no good ideas. Is the `org-babel-default-header-args:R' variable >> defined on your system before you load this file? If not, maybe you >> should be sure to add >> >> (require 'ob-R) >> Is this the right way to require a language anymore? I thought it was: ;; active Babel languages (org-babel-do-load-languages 'org-babel-load-languages '((R . t))) (http://orgmode.org/worg/org-contrib/babel/languages.html) > > The variable is defined (value is nil). I added the (require 'ob-R) to > my initialization nonetheless, but no avail. The value of > `org-babel-default-header-args:R' stays nil. > >> to your emacs initialization. If the ":" in the variable name is >> somehow confusing your Emacs, then possibly you could use the alternate >> format of specifying file local variables (see the info link in my >> attached example). > > I tried (the file is below). In this case I even get the question on > unsafe variables. > > [...] > Well that's good; it's trying to start a session. > > Thanks for the suggestions anyway, > Andreas > > PS: the file again: > #+begin_org > #+Title: Example > #+Author: Eric Schulte > > For more information on file local variables see > [[info:elisp#File%20Local%20Variables][info:elisp#File Local > Variables]]. > > Because there is a default :session values assigned locally for R > blocks we have the following. > > #+begin_src R > x <- 1 > x > #+end_src > > #+RESULTS: > : 1 > > #+begin_src R > x > #+end_src > > #+RESULTS: > > But non-R code blocks do not have a default session value. > > #+begin_src sh > date > #+end_src > > #+RESULTS: > : Mi 27. Mär 21:18:49 CET 2013 > > # Local Variables: > # org-babel-default-header-args:R: ((:session . "foo")) > # End: > #+end_org > Haven't really been following along, but this works for me (after execution): #+begin_src emacs-lisp (setq org-babel-default-header-args:R '((:session . "org-R"))) #+end_src These aren't: -*- org-babel-default-header-args:R: ((:session . "foo")) -*- #-*- org-babel-default-header-args:R: ((:session . "foo")) -*- There were a lot of suggestions made above and I've never used the -*-setting-*- syntax and am not searching the right things to find out more about how this is supposed to work. ETA: Ah, I had to re-open the file after adding this to the buffer to get it to recognize it: # Local Variables: # org-babel-default-header-args:R: ((:session . "foo")) # End: This produces the same issue as you, Andreas: Wrong type argument: sequencep, R: Not sure. I'm on 8.0-pre (release_8.0-pre-193-gaa7b1e). John >
Re: [O] Proposal for new/updated exporter tutorials on Worg
On Mar 28, 2013 5:37 AM, "Carsten Dominik" wrote: > > > On 28 mrt. 2013, at 06:31, Thomas S. Dye wrote: > > > Aloha John, > > > > Nice work. I look forward to contributing. > > > Another part is either getting rid of, or clearly labeling, all the Worg > > pages that deal with the old exporters. I can see them being a source > > of real confusion when 8.0 is adopted by users. > > Indeed. Maybe start by adding an OUTDATED banner or something like this to the page. Or we could move all these pages to a separate directory and keep it there for a while, until 8.0 has made it into an Emacs *release*. > I was thinking about that too. Someone already created a redirect page from org-tutorials/beamer to exportets/beamer. Is this recommended to prevent link rot? I'll get on the templates shortly! John > - Carsten > > > > > All the best, > > Tom > > > > -- > > Thomas S. Dye > > http://www.tsdye.com > > >
[O] [BUG] [ODT] Subtree export gives wrong footnote style
Hi, The new ODT exporter sometimes, but not always fails to put footnotes in Footnote style as expected. They are left in Text Body, which is wrong (and surprisingly difficult to fix in LibreOffice). After a bit of trial and failure, it seems the error depends on the scope of export: Exporting the whole buffer gives correct footnote style. Exporting a subtree only fails to give the correct style -- *unless* the footnote is included in the subtree. In the example below, I actually get a mix of stylesm depending on whether the footnote is defined in the exported section or outside it. Org-mode is clearly able to find both footnotes, and recognize them as footnotes, so I'm baffled at the different styling. -Begin example #+TITLE: Test ODT footnote style #+OPTIONS: num:nil toc:nil * This is a heading This is a bit of body text.[fn:1] It has footnotes.[fn:2] [fn:1] This is a footnote I have placed in the same section that I am exporting. It is in Footnote style (correct). * Footnotes [fn:2] This is a footnote in a footnote section. When I export the section above as a subtree, this footnote is in Text Body (wrong). When I export the whole document, it's in Footnote style (correct). -End example Yours, Christian
Re: [O] Proposal for new/updated exporter tutorials on Worg
On 28 mrt. 2013, at 06:31, Thomas S. Dye wrote: > Aloha John, > > Nice work. I look forward to contributing. > > Another part is either getting rid of, or clearly labeling, all the Worg > pages that deal with the old exporters. I can see them being a source > of real confusion when 8.0 is adopted by users. Indeed. Maybe start by adding an OUTDATED banner or something like this to the page. Or we could move all these pages to a separate directory and keep it there for a while, until 8.0 has made it into an Emacs *release*. - Carsten > > All the best, > Tom > > -- > Thomas S. Dye > http://www.tsdye.com >
Re: [O] Proposal for new/updated exporter tutorials on Worg
Hi John, these are all excellent ideas, thank you for making the start to a systematic way to put this kind of information onto Worg. If you have time to make a template, I am sure this would be appreciated. - Carsten On 28 mrt. 2013, at 05:51, John Hendy wrote: > Greetings, > > > I just pushed a changed to the 8.0 upgrade guide (scroll all the way > to the bottom): > - http://orgmode.org/worg/org-8.0.html > > It features a table similar to that of the Babel languages: > - http://orgmode.org/worg/org-contrib/babel/languages.html > > It simply lists the exporters Org offers, their .el location with > respect to Org directory (either in ./lisp/ox-* or > ./contrib/lisp/ox-*) and a column for what I hope will turn into links > to updated exporter tutorials/detailed documentation similar to what > exists for Org Babel. Currently, Org exporter tutorials are spread > between =worg.git/org-tutorials= and =worg.git/exporters=. It looks > like the most up to date have started settling in > =worg.git/exporters=; what does the list think about deciding to stick > with that as the home for all new ox-* related documentation on Worg? > > I'd propose they simply be titled according to the new names, > =worg.git/exporters/ox-*=. > > I'm happy to help with a template (probably just porting > ob-doc-template to ox-template or something like that). I think the > Babel table is great; perhaps after Org-8.0 actually launches, the new > exporters could receive a similar "landing page" > (=worg.git/exporters/ox-summary= or similar) where that table could > reside and be updated as the new platform grows. > > Individuals could contribute and add links at the table they can. I > think getting placeholders created for each exporter in the very near > future (which I also volunteer to do) will be really helpful as the > official shift to 8.0 happens. It will lower the barrier to entry for > getting information out of the mailing list and into Worg (I > anticipate lots more questions as infrequent upgraders/non-git users > migrate over). > > > Thanks for any comments/suggestions! > John >
Re: [O] :session question
Hi Eric, Eric Schulte writes: > Andreas Leha writes: > > [...] >> >> Is that just not working for me? And any ideas, what I could do about >> it? >> > > I have no good ideas. Is the `org-babel-default-header-args:R' variable > defined on your system before you load this file? If not, maybe you > should be sure to add > > (require 'ob-R) > The variable is defined (value is nil). I added the (require 'ob-R) to my initialization nonetheless, but no avail. The value of `org-babel-default-header-args:R' stays nil. > to your emacs initialization. If the ":" in the variable name is > somehow confusing your Emacs, then possibly you could use the alternate > format of specifying file local variables (see the info link in my > attached example). I tried (the file is below). In this case I even get the question on unsafe variables. [...] Thanks for the suggestions anyway, Andreas PS: the file again: #+begin_org #+Title: Example #+Author: Eric Schulte For more information on file local variables see [[info:elisp#File%20Local%20Variables][info:elisp#File Local Variables]]. Because there is a default :session values assigned locally for R blocks we have the following. #+begin_src R x <- 1 x #+end_src #+RESULTS: : 1 #+begin_src R x #+end_src #+RESULTS: But non-R code blocks do not have a default session value. #+begin_src sh date #+end_src #+RESULTS: : Mi 27. Mär 21:18:49 CET 2013 # Local Variables: # org-babel-default-header-args:R: ((:session . "foo")) # End: #+end_org
Re: [O] Org-mode as a replacement for Google Reader
I did also try rss2email r2e and that needs its config.py file put in the ~/.rss2email/ directory and users will need to edit that config.py file to set things correct for local installations. It does work once this gets done. On Wed, 27 Mar 2013, Carmine Casciato wrote: > > Jude DaShiell writes: > > > newsticker has been part of emacs since 22.x and it's supposed to be > > able to read rss feeds and display them. Now, how to get from what's in > > info newsticker to actually adding a real feed and have newsticker work > > is another matter entirely. I'm reading what's in info newsticker and > > don't yet fully understand where to store the feed and specifically what > > commands need be used to add feeds and delete feeds from a feeds list > > yet. > > > > On Wed, 27 Mar 2013, Samuel Loury wrote: > > > > > I tried it a few days ago, and it worked right of the box. It even > includes a few feeds you can start with. The customize-group for > newsticker was all I needed. > > The problem was when I tried to import the hundred-blog opml file, which > it did fine. However, due to the threaded nature of emacs, it froze > emacs for a long time as it went and called each blog. Perhaps async.el > can help here. In any case, it made emacs quite unusable. Shame, cuz > it's a nice setup for rss reading. > > --- jude Microsoft, windows is accessible. why do blind people need screen readers?
Re: [O] A t-shirt idea;)
* Marcin Borkowski wrote: > Dnia 2013-03-27, o godz. 19:34:45 > Jude DaShiell napisał(a): > >> Maybe something like: >> Feng Shui for your computer, >> ORG-MODE! >> would work. > > Well, I have strong negative associations with feng shui, so I guess > not. ... and you have positive associations with the Borg? *SCNR* ;-) -- Karl Voit
Re: [O] [BUG] [ODT] Annotations break paragraphs
Hi again, While we're at it, there's trouble with custom author and date info in annotations. I hadn't really noticed, since my name was inserted anyway and dates didn't matter much to my work. 1. Author and date attributes of the annotation are ignored, unless I'm writing them wrong (I've tried three syntaxes -- below the signature). My name is used for the authorname, whatever I put as :author in the #+begin_annotation line. No date is found. 2. In LibreOffice the annotations all say "no date", and indeed, no date ( element) is inserted at all. Maybe it should be. When I remove the condition testing for a date "(and date <...>)", all the annotations get stamped with the time of export if the exporter doesn't find any other date. That was the behavior of the old exporter. It's debatable whether it's the right thing to do, but I saw it as a feature, saving work to insert timestamps. Yours, Christian Here's what I've tried for the author/date attributes. This is the syntax originally used when Jambunathan introduced the feature: There is an annotation by a reviewer - "Someone else" - here. #+begin_annotation author "Someone else" date "<2011-10-22 Wed 15:43>" Yes I do. #+end_annotation I have tried these as well: There is an annotation by a reviewer - "Someone else" - here. #+begin_annotation :author "Someone else" :date "<2011-10-22 Wed 15:43>" Yes I do. #+end_annotation There is an annotation by a reviewer - "Someone else" - here. #+begin_annotation :author Someone else :date <2011-10-22 Wed 15:43> Yes I do. #+end_annotation Christian Moe writes: > Nicolas Goaziou writes: >>> Minor cosmetic annoyance: An extra space is inserted >>> before the annotation. >>> >>> Pending the introduction of a dedicated syntax, could we have this fix >>> in master please? >> >> Sure, but, if it's not too much work, I'd like the extra space removed >> first. Do you have an idea about the XML reason behind this? > > Yes, there's a newline inserted before the opening > tag. I guess that since it's inside a tag, it gets interpreted > as whitespace that's part of the text, and collapsed to a space. But the > newline is only there to make the XML more readable, so it's expendable. > > Sorry, I really could have taken the ten minutes to investigate that > before my previous message. > > Yours, > Christian
[O] org-babel: two confirmations for org/HTML "macro"?
Hallo, we currently use MACROs for adding http://microformats.org/wiki/hcard information to web pages we create from org sources. As these MACROs have 12+ arguments, this is an error prone and inelegant way of getting the desired result. Nicolas Goaziou suggested using a babel approach so we could have named arguments - obviously, this is a much better solution (thanks again, Nicolas!). Here is a minimal example of the principle: -- snip #+name: html-ex1 #+header: :var who="World" #+BEGIN_SRC org :exports none Hallo $who #+END_SRC * Simple HTML export #+call: html-ex1(who="Stefan") :results html -- snip When exporting this code (new exporter), I need two confirmations: Evaluate this org code block (html-ex1)... Evaluate this emacs-lisp block... I can understand the first question, but why the second? What is the best way to safely "auto-confirm" for this simple application? Many thanks in advance. Warm regards, Stefan -- Dr. Stefan Vollmar, Dipl.-Phys. Head of IT group Max-Planck-Institut für neurologische Forschung Gleueler Str. 50, 50931 Köln, Germany Tel.: +49-221-4726-213 FAX +49-221-4726-298 Tel.: +49-221-478-5713 Mobile: 0160-93874279 E-Mail: voll...@nf.mpg.de http://www.nf.mpg.de smime.p7s Description: S/MIME cryptographic signature
Re: [O] [ox-publish] handling of white space in arguments of macros, named arguments?
Dear Nicolas,
On 27.03.2013, at 17:26, Nicolas Goaziou wrote:
>> ...
>>
>> but now the white space around the arguments is no longer stripped and/or
>> other effects cause "<" and ">" in the macro to be exported as "<" etc.
>>
>> This version seems to work fine:
>>
>> {{{mhead-hcard(Dr. Stefan
>> Vollmar,Stefan,,Vollmar,Dr.,stefan-vollmar.jpg,stefan-vollmar.html,Head
>> of IT Group\,Physicist\, Software
>> Developer,voll...@nf.mpg.de,it,+49 221 4726-213,+49 221 4726-298)}}}
>
> I removed trimming around arguments a few days ago, since it wasn't an
> explicit specification for macros. Therefore, newline characters are
> inserted in your template, which means that the HTML keyword doesn't
> affect all lines of the generated code and, as a consequence, some "<"
> are exported as "<".
OK, thanks - that obviously explains it. I think you are absolutely right that
our previous solution was build around unspecified assumptions.
> I think all newline characters should be replaced with a whitespace
> character in macro arguments. Indeed, macro templates are only one line
> long but unwanted "\n" could be inserted by paragraph filling in
> arguments.
You are referring to some workaround that could mimick the old behaviour? Could
you give an example? (Maybe this might be of interest for some simple "legacy
cases" of ours)
> I also don't mind trimming arguments again, provided this is added as an
> explicit behaviour and there is no opposition to it.
From my point of view it would be convenient for some code we already have and
do not need to change - but, on second thoughts, you are right: it is somewhat
artificial.
>> Yes, I could use it as a workaround, but I would prefer something
>> similar to the above version for improved readability - maybe by
>> adding "line continuation markers" like "\"? Obviously, more complex
>> macros (the one above has 12 individual arguments) are less than ideal
>> anyway and the best solution (by far) would be "named arguments".
>> Maybe there already is a better way of using (HTML) templates?
>
> I think you really shouldn't use macros for that. For example, consider
> adding the following in your buffer (or, better, in the Library of
> Babel):
>
> #+name: mhead-hcard
> #+header: :var cname="Complete Name" gname="Given Name" photo="photo.jpg"
> prefix=""
> #+header: :var web="web-page.html"
> #+BEGIN_SRC org :exports none
>
>
>
>
>
> />
>
> href="http://www.nf.mpg.de/cv/$web";>
>
> $prefix
> $gname
> ...
> #+END_SRC
>
> Then, you insert a hcard with:
>
> #+call: mhead-hcard(cname="Dr. Stefan
> Vollmar",gname="Stefan",prefix="Dr.",web="stefan-vollmar.html",photo="stefan-vollmar.jpg")
> :results html
EXCELLENT - this is much better than what I had hoped for. Here is another
happy Babel fan!
Warm regards,
Stefan
--
Dr. Stefan Vollmar, Dipl.-Phys.
Head of IT group
Max-Planck-Institut für neurologische Forschung
Gleueler Str. 50, 50931 Köln, Germany
Tel.: +49-221-4726-213 FAX +49-221-4726-298
Tel.: +49-221-478-5713 Mobile: 0160-93874279
E-Mail: voll...@nf.mpg.de http://www.nf.mpg.de
smime.p7s
Description: S/MIME cryptographic signature
Re: [O] [BUG] [ODT] Annotations break paragraphs
Nicolas Goaziou writes: >> Minor cosmetic annoyance: An extra space is inserted >> before the annotation. >> >> Pending the introduction of a dedicated syntax, could we have this fix >> in master please? > > Sure, but, if it's not too much work, I'd like the extra space removed > first. Do you have an idea about the XML reason behind this? Yes, there's a newline inserted before the opening tag. I guess that since it's inside a tag, it gets interpreted as whitespace that's part of the text, and collapsed to a space. But the newline is only there to make the XML more readable, so it's expendable. Sorry, I really could have taken the ten minutes to investigate that before my previous message. Yours, Christian
