Re: [O] Automatically insert R source code block?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/09/11 02:22, Michael Hannon wrote: From: suvayu ali fatkasuvayu+li...@gmail.com Hey Mike, On Fri, Sep 16, 2011 at 1:18 AM, Michael Hannon jm_han...@yahoo.com wrote: but Emacs complains about an org-mode fontification error and doesn't give me an executable R source-code block. I've tried numerous minor variations on this theme, but I don't think it's worth wasting your time by listing all of the thrashing I've done. The solution is probably obvious to people with a decent understanding of elisp. Do you have org-src-fontify-natively set to t? If so I am taking a shot in the dark here, emacs probably doesn't know how to fontify R source. Do you have emacs-ess installed? I would expect an error like this if its not. But I could be wrong here as I don't use either of emacs-ess or R. Hi, Suvayu. The variable org-src-fontify-natively was set to nil, but I get the same result with it set to 't'. I do have Emacs-ess installed. I've been assuming that I was just messing up the syntax, but maybe there's something deeper involved. Thanks for your note. Don't worry - try to insert the s template and observe - the error is also there (at least most of the time). But as soon as I go into the code block, everything is fine - so I would not worry to much, but to hope that this will be fixed? org version: Org-mode version 7.7 (release_7.7.285.ge73b) and Org-mode version 7.7 (release_7.7.291.g37db) Rainer -- Mike - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zDYIACgkQoYgNqgF2egr3cACdG2UdRP9ykebSD6f746C3h3CQ uv4AnA+8KjVna9H5jkllrvM1L9GM0tlK =nnRu -END PGP SIGNATURE-
[O] [babel] error when loading library-of-babel after update this morning
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi when evaluating #+begin_src emacs-lisp (org-babel-lob-ingest ~/.emacs.d/org-mode/contrib/babel/library-of-babel.org) #+end_src I get the following error: executing Emacs-Lisp code block... variable nil must be assigned a default value this occurred after the update this morning to Org-mode version 7.7 (release_7.7.291.g37db) Cheers, Rainer - -- Rainer M. Krug, PhD (Conservation Ecology, SUN), MSc (Conservation Biology, UCT), Dipl. Phys. (Germany) Centre of Excellence for Invasion Biology Stellenbosch University South Africa Tel : +33 - (0)9 53 10 27 44 Cell: +33 - (0)6 85 62 59 98 Fax : +33 - (0)9 58 10 27 44 Fax (D):+49 - (0)3 21 21 25 22 44 email: rai...@krugs.de Skype: RMkrug -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk5zDr8ACgkQoYgNqgF2egrqgQCfdJ9cSI5HnblPcbJyZPUGPpkZ DvMAniv4ooDCUmR1LQ4EIepxKlaj/G66 =PbAM -END PGP SIGNATURE-
Re: [O] [babel] Some variables with no default value don't provoke an error
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Weirdly enough, in the following code block, I must add a default value for vars `table', `column' and `type' but not for the var `nullability'. I've even been able to add fake vars `something' and `else' with no error being reported (at ingestion time): #+srcname: add-column-in-table(table=, column=, something, type=, else, nullability) #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column') BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src Note that, in the above state, the code block is ingested with no error, but, if I remove the default value of var `table', it then generates back an error... I've just pushed up a check for these functional-syntax variables which will ensure that each is given a default value. Since this check takes place at the location of the code block it /does/ include the name of the code block in the error message. If you have a couple of minutes, can you clarify some points to be sure I can understand: - What do you call functional-syntax vars? The ones in the #+srcname, next to the block name, as opposed to the ones declared as :var arguments? The fact, then, that we can get a clearer message in case of error, seems to me an incentive to use that type of declaration... - Why was `nullability' not detected to have no default value? Why were `table', `column' and `type' well correctly detected? Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Export problem (Wrong type argument: consp, nil)
Hi Eric, Eric Schulte wrote: Question: Would it be possible to add the src-name in the error message? Unfortunately the code block name is not known to the function (namely `org-babel-merge-params') which throws errors when variables are not assigned default values. In fact this function may be called when there are no code blocks present. I think that this is why you ran into problems trying to thread the code block info down into this error message. Another option may be to check when a code block is initially parsed to ensure that all variables are assigned default parameters. If the checking is done initially then the code block name and position will be known and could be included into the error message. There exists a function for checking code blocks (namely `org-babel-check-src-block'), I've added a TODO to this function to add a check that all variables are initialized. OK. Thanks. * Test #+begin_src emacs-lisp (ert-deftest test-org-babel/no-defaut-value-for-var () Test that the absence of a default value for a variable does throw a proper error. (org-test-at-id f2df5ba6-75fa-4e6b-8441-65ed84963627 (org-babel-next-src-block) (should-error (org-babel-execute-src-block)) :type 'error)) #+end_src Though, I have 2 questions: - How can I differentiate between the clean error (with a message) and the one which wasn't correctly trapped? Based on the first line of a backtrace (string comparison) or on the type of the error? In the latter case, how can I know what's the type of the current error thrown, and the one of the error before your fix? I believe Martyn answered this question Yes, he did. Thanks Martyn. - I wonder why we need twice the =org-babel-next-src-block= call, and not only once in the =should-error= form. I only see a single call to org-babel-next-src-block in the above test. OK, I misread `org-babel-next-src-block' and `org-babel-execute-src-block'. It was late, I guess. Sorry for the noise. Thanks for working on this test, I look forward to adding it once it is completed. With Martyn's patch, updated with the brand new source name figuring in the error message, the completed version becomes: * Code block with no default value for vars :PROPERTIES: :ID: f2df5ba6-75fa-4e6b-8441-65ed84963627 :END: There is no default value assigned to =x= variable. This is not permitted anymore. #+source: carre(x) #+begin_src python return x*x #+end_src * Test #+begin_src emacs-lisp (ert-deftest test-org-babel/no-defaut-value-for-var () Test that the absence of a default value for a variable DOES THROW an error. (org-test-at-id f2df5ba6-75fa-4e6b-8441-65ed84963627 (org-babel-next-src-block) (let ((err (should-error (org-babel-execute-src-block) :type 'error))) (should (equal '(error variable \x\ in block \carre\ must be assigned a default value) err) #+end_src I'll send you a patch for this. Best regards, Seb -- Sebastien Vauban
Re: [O] [babel] Export problem (Wrong type argument: consp, nil)
Hi Eric,
Eric Schulte wrote:
Thanks for working on this test, I look forward to adding it once it is
completed.
As promised, a patch for checking that vars with no default value will
generate an error with a full explanation.
I edited 2 files:
- lisp/test-ob.el
- examples/babel.org
Tell me if this is following your expected way of receiving patches. I believe
so, but tell me anything that would not have been done correctly...
Best regards,
Seb
--
Sebastien Vauban
From 453c0d5e54544ef5812098817746b4280375f5e4 Mon Sep 17 00:00:00 2001
From: Sebastien Vauban s...@mygooglest.com
Date: Fri, 16 Sep 2011 12:06:21 +0200
Subject: [PATCH] Add test checking that any variable declared with no default
value will generate a proper error message.
---
testing/lisp/test-ob.el | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 2e71a59..f78ca98 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -1,6 +1,6 @@
;;; test-ob.el --- tests for ob.el
-;; Copyright (c) 2010 Eric Schulte
+;; Copyright (c) 2010, 2011 Eric Schulte
;; Authors: Eric Schulte, Martyn Jago
;; Released under the GNU General Public License version 3
@@ -421,6 +421,15 @@
(next-result)
(should (not (org-babel-in-example-or-verbatim))
+(ert-deftest test-org-babel/no-defaut-value-for-var ()
+ Test that the absence of a default value for a variable DOES THROW
+ a proper error.
+ (org-test-at-id f2df5ba6-75fa-4e6b-8441-65ed84963627
+(org-babel-next-src-block)
+(let ((err
+ (should-error (org-babel-execute-src-block) :type 'error)))
+ (should (equal '(error variable \x\ in block \carre\ must be assigned a default value) err)
+
(provide 'test-ob)
;;; test-ob ends here
--
1.7.5.1
From 3e04371aa9a7afcacf5c26877328a829b8067830 Mon Sep 17 00:00:00 2001
From: Sebastien Vauban s...@mygooglest.com
Date: Fri, 16 Sep 2011 12:07:19 +0200
Subject: [PATCH] Add test checking that any variable declared with no default
value will generate a proper error message.
---
testing/examples/babel.org | 13 +
1 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index b892124..82dd8ee 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -307,3 +307,16 @@ src_sh{echo 2} blocks on the src_emacs-lisp{same} line
#+results:
[[file:./cv.cls]]
+
+* no default value for vars
+ :PROPERTIES:
+ :ID: f2df5ba6-75fa-4e6b-8441-65ed84963627
+ :END:
+
+There is no default value assigned to =x= variable. This is not permitted
+anymore.
+
+#+source: carre(x)
+#+begin_src python
+ return x*x
+#+end_src
--
1.7.5.1
[O] [PATCH] Continue numbering from any previous numbered snippet with +n, even when previous numbered snippet does not immediately precede it.
* org-mode/lisp/org-exp.el (org-export-number-lines): Check whether number parameter (this is a numbered block!) is non-nil as well as whether cont is nil (this numbered block should *not* continue numbering where we left off before!) before resetting the count to zero. From the docs: If you use a `+n' switch, the numbering from the previous numbered snippet will be continued in the current one. With this change I believe the code complies with the docs. --- lisp/org-exp.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/org-exp.el b/lisp/org-exp.el index 9884a31..12590e1 100644 --- a/lisp/org-exp.el +++ b/lisp/org-exp.el @@ -2731,7 +2731,7 @@ INDENT was the original indentation of the block. (defun org-export-number-lines (text optional skip1 skip2 number cont replace-labels label-format) (setq skip1 (or skip1 0) skip2 (or skip2 0)) - (if (not cont) (setq org-export-last-code-line-counter-value 0)) + (if (and number (not cont)) (setq org-export-last-code-line-counter-value 0)) (with-temp-buffer (insert text) (goto-char (point-max)) -- 1.7.4.1
Re: [O] [babel] error when loading library-of-babel after update this morning
Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Rainer, Rainer M Krug wrote: when evaluating #+begin_src emacs-lisp (org-babel-lob-ingest ~/.emacs.d/org-mode/contrib/babel/library-of-babel.org) #+end_src I get the following error: executing Emacs-Lisp code block... variable nil must be assigned a default value this occurred after the update this morning to Org-mode version 7.7 (release_7.7.291.g37db) I confirm that, with the exact same message, for my own local LOB, since this morning's update. And I don't have a `nil' variable either in the (only) code block... Hi, I introduced this bug yesterday when I made the change which checks that all functional-syntax variables are assigned values. While checking the new code deletes the variables value! I've just pushed up a fix. Cheers -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [babel] Some variables with no default value don't provoke an error
Hi, Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Weirdly enough, in the following code block, I must add a default value for vars `table', `column' and `type' but not for the var `nullability'. I've even been able to add fake vars `something' and `else' with no error being reported (at ingestion time): #+srcname: add-column-in-table(table=, column=, something, type=, else, nullability) #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column') BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src Note that, in the above state, the code block is ingested with no error, but, if I remove the default value of var `table', it then generates back an error... I've just pushed up a check for these functional-syntax variables which will ensure that each is given a default value. Since this check takes place at the location of the code block it /does/ include the name of the code block in the error message. If you have a couple of minutes, can you clarify some points to be sure I can understand: - What do you call functional-syntax vars? The ones in the #+srcname, next to the block name, as opposed to the ones declared as :var arguments? yes, that's exactly it, I don't know what functional-syntax is a good or descriptive term, but it is used in the source code so I'm now repeating it. The fact, then, that we can get a clearer message in case of error, seems to me an incentive to use that type of declaration... I personally prefer the traditional :var style, I'll have to add similar error checking there... - Why was `nullability' not detected to have no default value? Why were `table', `column' and `type' well correctly detected? Meaning after you assigned values to the first three no error was thrown when the fourth (nullability) wasn't assigned a value? Could you provide a minimal example? Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Four issues with org-babel-tangle
Christopher Genovese genovese...@gmail.com writes: I'll write up this change as it may end up being longer than 10 lines, and if I write it we don't have to wait for your FSF assignment to clear (which can sometimes take months) before applying the patch. That sounds good, thanks. In fact... if this attached patch looks good to you (i.e., allows the behavior you originally intended) then please let me know and I'll apply it immediately. Ideally, I'd like to combine the customizable processing with the simple fix code (which eliminates the two related bugs and the extra *s). Something like the following in place of the corresponding section in the patch you sent. The extra (match-end 0) and (point-min)'s prevent those problems. Otherwise, it all looks great. + (funcall +org-babel-process-comment-text +(buffer-substring + (max (condition-case nil + (save-excursion +(org-back-to-heading t); sets match data +(match-end 0)) +(error (point-min))) + (save-excursion +(if (re-search-backward + org-babel-src-block-regexp nil t) +(match-end 0) + (point-min + (point) I'm happy to take a look at the patch again anytime. OK, I've just applied this simple change on top of the previously discussed change directly to the Org-mode git repository. Please let me know if anything looks amiss. Hmm, but #+tangle is not an official Org-mode directive in the same way that #+source:, #+headers:, and #+call: are. Unless I'm forgetting something #+tangle: lines would have no functional effect, in which case why not just use a normal org-mode comment (e.g., a line starting with # ). You're right, I agree. I'm just being particular about indentation. I don't like to have a line starting with # when everything else is indented. And I don't like having to put a space after the #+ to prevent export, so I just wanted #+tangle (or #+noop or #+comment or whatever) to count as a non-exported comment too, just like #+ tangle would. But I can see that it's not worth the effort or the confusion with a functional directive that it would cause. I'll just suck it up and use the extra space. Probably the best way forward. Sorry I can't be more help here. Cheers -- Eric Thanks again, Eric. Best, Christopher On Thu, Sep 15, 2011 at 18:02, Eric Schulte schulte.e...@gmail.com wrote: - Show quoted text - Christopher Genovese genovese...@gmail.com writes: Hi Eric, Thanks for your note. I would encourage you to begin the FSF assignment process if you anticipate potentially contributing more fixes in the future. Could you please send a git format-patch version of the simple fix to the list so that I might apply it? I will begin the FSF assignment process, and I will send a git-format patch based on the simple fix. (I'll send that tonight.) Fantastic. I like the idea of introducing a customizable function for comment text transformation, however ... rather perhaps we should just leave the default value of this function as simple as possible and allow users to customize it That makes sense, and I like the way you did it. In particular, I absolutely agree that the org-babel-trim should be removed from org-babel-spec-to-string (to allow flexibility in the customization). Making it the default processor works well, I think. Would you like me to submit a separate patch based on this change or should I include that as part of the patch with the simple fix? I'll write up this change as it may end up being longer than 10 lines, and if I write it we don't have to wait for your FSF assignment to clear (which can sometimes take months) before applying the patch. In fact... if this attached patch looks good to you (i.e., allows the behavior you originally intended) then please let me know and I'll apply it immediately. Finally I'm not sure I fully understand what you mean by ... Sorry, I wasn't clear. It's a small thing. If you put '#+tangle' in column 0, the line is not exported because it begins with #; if you put #+ tangle on a line (spaces after + and possibly before #), the line is not exported because it begins with #+; but if you put #+tangle (no spaces after the + but spaces before the #), the line is exported. I think it would be useful if something like #+tangle's (with no spaces between the # and +) were *not* exported because such lines can support useful customizations. Having to put the spaces after the + is a bit bothersome and looks uglier to me. Hmm, but #+tangle is not an official Org-mode directive in the same way that #+source:, #+headers:, and #+call: are. Unless I'm forgetting something #+tange: lines would have no functional effect, in
Re: [O] [babel] Export problem (Wrong type argument: consp, nil)
Hi Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Hi Eric, Eric Schulte wrote: Thanks for working on this test, I look forward to adding it once it is completed. As promised, a patch for checking that vars with no default value will generate an error with a full explanation. I edited 2 files: - lisp/test-ob.el - examples/babel.org Great! Thanks for contributing these test cases. They are now applied and are passing. Tell me if this is following your expected way of receiving patches. I believe so, but tell me anything that would not have been done correctly... Yes, I do prefer these format of patch (i.e., generated using git format-patch), however I would prefer if you only sent a single patch for all changed files, rather than splitting the commit up into two patches. Thanks -- Eric Best regards, Seb -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]
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.
I have an Org link as follows:
[[message://m2k4n46n5p.wl%d...@boostpro.com]]
When I try to `C-c C-o' it, opening fails because the link-handling code
sees this string for the link:
m2k4n46n5p.wlÚv...@boostpro.com
which you may notice is different. If I do
(org-open-link-from-string message://m2k4n46n5p.wl%d...@boostpro.com)
on the other hand, it works just fine.
Emacs : GNU Emacs 23.3.1 (x86_64-apple-darwin10.8.0, Carbon Version 1.6.0
AppKit 1038.36)
of 2011-09-12 on pluto.luannocracy.com
Package: Org-mode version 7.7 (release_7.7.292.g0d4e8.dirty)
current state:
==
(setq
org-x-backends '(ox-org ox-redmine)
org-agenda-deadline-leaders '(D: D%d: )
org-clock-in-switch-to-state STARTED
org-agenda-skip-scheduled-if-deadline-is-shown t
org-export-latex-after-initial-vars-hook '(org-beamer-after-initial-vars)
org-x-redmine-title-prefix-match-function 'org-x-redmine-title-prefix-match
org-speed-command-hook '(org-speed-command-default-hook
org-babel-speed-command-hook)
org-agenda-custom-commands '((E Errands (next 3 days) tags
ErrandTODO\DONE\TODO\CANCELED\STYLE\habit\SCHEDULED\+3d\
((org-agenda-overriding-header Errands (next 3
days
(A Priority #A tasks agenda
((org-agenda-ndays 1)
(org-agenda-overriding-header Today's priority #A tasks: )
(org-agenda-skip-function
(quote (org-agenda-skip-entry-if (quote
notregexp) \\=.*\\[#A\\])))
)
)
(b Priority #A and #B tasks agenda
((org-agenda-ndays 1)
(org-agenda-overriding-header Today's priority
#A and #B tasks: )
(org-agenda-skip-function
(quote (org-agenda-skip-entry-if (quote
regexp) \\=.*\\[#C\\])))
)
)
(p Un-prioritized tasks agenda
((org-agenda-overriding-header Today's
un-prioritized tasks: )
(org-agenda-skip-function
(quote (org-agenda-skip-entry-if (quote
notregexp) \\=.*\\[#[ABC]\\])))
)
)
(w Waiting/delegated tasks tags
TODO=\WAITING\|TODO=\DELEGATED\
((org-agenda-overriding-header
Waiting/delegated tasks:)
(org-agenda-sorting-strategy (quote
(todo-state-up priority-down category-up
)
(u Unscheduled tasks tags
AREA\Work\TODO\\TODO{DONE\\|CANCELED\\|NOTE\\|PROJECT}
((org-agenda-files (quote
(~/Documents/Tasks/todo.txt)))
(org-agenda-overriding-header Unscheduled
tasks: )
(org-agenda-skip-function
(quote
(org-agenda-skip-entry-if (quote scheduled)
(quote deadline) (quote timestamp)
(quote regexp) \\*
\\(DEFERRED\\|SOMEDAY\\))
)
)
(org-agenda-sorting-strategy (quote
(priority-down
)
(U Deferred tasks tags TODO=\DEFERRED\
((org-agenda-files (quote
(~/Documents/Tasks/todo.txt)))
(org-agenda-overriding-header Deferred
tasks:))
)
(Y Someday tasks tags TODO=\SOMEDAY\
((org-agenda-overriding-header Someday
tasks:)))
(G Ledger tasks (all) alltodo
((org-agenda-files (quote
(~/src/ledger/plan/TODO)))
(org-agenda-overriding-header Ledger tasks:)
(org-agenda-sorting-strategy (quote
(todo-state-up priority-down category-up
)
(N Ledger tasks (all, alphabetical) alltodo
((org-agenda-files (quote
(~/src/ledger/plan/TODO)))
(org-agenda-overriding-header Ledger tasks,
alphabetical:)
[O] HOWTO?: export without (re)eval-ing src blocks (was? disable automatic source block evaluation but allow manual)
I would like to be able to export a buffer as HTML, LaTex, what-have-you without having to re-evaluate any source blocks, and without having to modify the :eval tag in any source header blocks. Is there any way to accomplish this via hooks, flags, appropriate function calls? I think my concerns run similarly to those discussed in http://lists.gnu.org/archive/html/emacs-orgmode/2010-12/msg00827.html and so have cc:ed its discussants except my hope is to find a way of de-coupling export form evaluation. Cheers Thanks! Malcolm Cook
Re: [O] HOWTO?: export without (re)eval-ing src blocks (was? disable automatic source block evaluation but allow manual)
[forgot to cc: the list] Cook, Malcolm m...@stowers.org wrote: I would like to be able to export a buffer as HTML, LaTex, what-have-you without having to re-evaluate any source blocks, and without having to modify the :eval tag in any source header blocks. Is there any way to accomplish this via hooks, flags, appropriate function calls? ... Maybe this: , | org-export-babel-evaluate is a variable defined in `ob-exp.el'. | Its value is t | | This variable is safe as a file local variable if its value | satisfies the predicate `(lambda (x) (eq x nil))'. | | Documentation: | Switch controlling code evaluation during export. | When set to nil no code will be evaluated as part of the export | process. ` Nick
Re: [O] HOWTO?: export without (re)eval-ing src blocks (was? disable automatic source block evaluation but allow manual)
Nick, Exactly what I needed, thanks, somehow missed that And this advice is what I needed to do next: http://lists.gnu.org/archive/html/emacs-orgmode/2011-06/msg00034.html ~Malcolm -Original Message- From: nicholas.do...@hp.com [mailto:nicholas.do...@hp.com] Sent: Friday, September 16, 2011 12:01 PM To: Cook, Malcolm Cc: 'emacs-orgmode@gnu.org'; 'andreas.l...@med.uni-goettingen.de'; nicholas.do...@hp.com Subject: Re: [O] HOWTO?: export without (re)eval-ing src blocks (was? disable automatic source block evaluation but allow manual) [forgot to cc: the list] Cook, Malcolm m...@stowers.org wrote: I would like to be able to export a buffer as HTML, LaTex, what-have-you without having to re-evaluate any source blocks, and without having to modify the :eval tag in any source header blocks. Is there any way to accomplish this via hooks, flags, appropriate function calls? ... Maybe this: , | org-export-babel-evaluate is a variable defined in `ob-exp.el'. | Its value is t | | This variable is safe as a file local variable if its value | satisfies the predicate `(lambda (x) (eq x nil))'. | | Documentation: | Switch controlling code evaluation during export. | When set to nil no code will be evaluated as part of the export | process. ` Nick
[O] Problems with Org-Mode export
Greetings. I've been having problems lately in exporting Org-Mode source-code documents to HTML and/or PDF. I'm running Org-Mode 7.7 with Emacs 23 on 64-bit linux (Fedora 15). I've appended a document that exhibits at least some of the problem. The problems are similar to the problem described at: http://comments.gmane.org/gmane.emacs.orgmode/45316 and can *sometimes* be circumvented by executing org-reload. In the particular example shown below, the HTML export works as expected, but the PDF export fails with message: org-export-latex-preprocess: Wrong type argument: stringp, nil By the way, everything worked fine in the example until I added the last source block: #+begin_src R x #+end_src I tried using what I take to be the latest version of Org-Mode: Org-mode version 7.7 (release_7.7.290.g65d05) but that only made things worse. I tried an HTML export with this version, and it generated a horrendous-looking message that begins with: org-babel-R-evaluate: Wrong number of arguments: #[(session body result-type result-params column-names-p row-names-p) Æ=}... followed by a bunch of stuff containing enough non-printing characters that it's hard to reproduce in email, and ending with: ...org-mode/lisp/ob-R.elc . 9734)], 5 I'd welcome any help/advice that anybody can provide. Thanks, -- Mike ## Sample file that exhibits some export problems #+TITLE: This is a test #+AUTHOR: Michael Hannon #+email: jm_han...@yahoo.com #+BABEL: :session *R* :cache yes :results output graphics :exports both :tangle yes * Getting Started ** Batch Mode #+begin_src R :exports code pdf(xh.pdf) # set graphical output file hist(rnorm(100)) # generate 100 N(0,1) variates and plot their histogram dev.off() # close the graphical output file #+end_src If we put the code above in a file called =z.R=, we can execute the code from the command line via: =R CMD BATCH z.R= #+begin_src R x - c(1, 3, 5) #+end_src #+begin_src R x[3] #+end_src #+begin_src R q - c(x,x,8) #+end_src #+begin_src R x #+end_src
Re: [O] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]
At Fri, 16 Sep 2011 12:03:51 -0400, Dave Abrahams wrote: 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. I have an Org link as follows: [[message://m2k4n46n5p.wl%d...@boostpro.com]] When I try to `C-c C-o' it, opening fails because the link-handling code sees this string for the link: m2k4n46n5p.wlÚv...@boostpro.com which you may notice is different. If I do (org-open-link-from-string message://m2k4n46n5p.wl%d...@boostpro.com) How did you enter the link into the Org file? The original link [[message://m2k4n46n5p.wl%d...@boostpro.com]] Is unescaped, but Org treats links as always percent-escaped. What happens is that %da is treated as a percent escaped character and unescaped after read from buffer. The link should read: message://m2k4n46n5p.wl%25d...@boostpro.com This is a troublesome situation https://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00257.html But up to know I didn't find a solution for it. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpXiewk8yzTV.pgp Description: PGP signature
Re: [O] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]
on Fri Sep 16 2011, David Maus dmaus-AT-ictsoc.de wrote: How did you enter the link into the Org file? The original link [[message://m2k4n46n5p.wl%d...@boostpro.com]] Is unescaped, but Org treats links as always percent-escaped. What happens is that %da is treated as a percent escaped character and unescaped after read from buffer. The link should read: message://m2k4n46n5p.wl%25d...@boostpro.com Yeah, I finally figured that out. This is a troublesome situation https://lists.gnu.org/archive/html/emacs-orgmode/2011-09/msg00257.html But up to know I didn't find a solution for it. Hmm, well, ... the link started out as a a wanderlust link of a form more like this: [[wl:/message-id:m2k4n46n5p.wl%d...@boostpro.com/%%5BGmail%5D/All%20Mail#103387bf-79b8-4389-ad51-955087347...@gmail.com]] _That_ link used to work. I transformed links like that by search/replace into: [[message://m2k4n46n5p.wl%d...@boostpro.com]] So maybe it's my fault? -- Dave Abrahams BoostPro Computing http://www.boostpro.com
[O] pdf exports on remote files
Hi. Can anyone tell me how, while working in org-mode on a remote host (accessed with tramp), I could tell emacs that the pdf file I want to export (C-c C-e d) should be created with my local machine? The hosts I'm concerned with don't have any pdf generating capability, and I'd prefer to avoid making local copies of the text files in this case. Thanks! -- amp
Re: [O] [babel] Some variables with no default value don't provoke an error
Hi Eric, Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Eric Schulte wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Weirdly enough, in the following code block, I must add a default value for vars `table', `column' and `type' but not for the var `nullability'. I've even been able to add fake vars `something' and `else' with no error being reported (at ingestion time): #+srcname: add-column-in-table(table=, column=, something, type=, else, nullability) #+begin_src sql -- add column `$column' (if column does not exist yet) IF NOT EXISTS (SELECT * FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME = '$table' AND COLUMN_NAME = '$column') BEGIN ALTER TABLE $table ADD $column $type $nullability END #+end_src Note that, in the above state, the code block is ingested with no error, but, if I remove the default value of var `table', it then generates back an error... I've just pushed up a check for these functional-syntax variables which will ensure that each is given a default value. Since this check takes place at the location of the code block it /does/ include the name of the code block in the error message. If you have a couple of minutes, can you clarify some points to be sure I can understand: - What do you call functional-syntax vars? The ones in the #+srcname, next to the block name, as opposed to the ones declared as :var arguments? yes, that's exactly it, I don't know what functional-syntax is a good or descriptive term, but it is used in the source code so I'm now repeating it. OK. The fact, then, that we can get a clearer message in case of error, seems to me an incentive to use that type of declaration... I personally prefer the traditional :var style, I'll have to add similar error checking there... Good to know. - Why was `nullability' not detected to have no default value? Why were `table', `column' and `type' well correctly detected? Meaning after you assigned values to the first three no error was thrown when the fourth (nullability) wasn't assigned a value? Could you provide a minimal example? Yes, you summed up exactly what I (can assure you that) observed yesterday. Though, now that the message includes the src-name, it is somehow fixed. I can't reproduce it anymore... Thanks. Best regards, Seb -- Sebastien Vauban
[O] Collapsing tracked time?
For one particular long running TODO, I have to scroll over several (well... more than one) screen pages of time stamps until I get to the payload. Is it possible to let the time stamps be collapsed/hidden by default, and only toggle them visible if I need to adjust a time stamp or two? Thanks! - Steinar
Re: [O] Problems with Org-Mode export
FYI: the problem described below is worse with: Org-mode version 7.7 (release_7.7.298.gbf3e9) -- Mike From: Michael Hannon jm_han...@yahoo.com To: Org-Mode List emacs-orgmode@gnu.org Sent: Friday, September 16, 2011 10:50 AM Subject: [O] Problems with Org-Mode export Greetings. I've been having problems lately in exporting Org-Mode source-code documents to HTML and/or PDF. I'm running Org-Mode 7.7 with Emacs 23 on 64-bit linux (Fedora 15). I've appended a document that exhibits at least some of the problem. The problems are similar to the problem described at: http://comments.gmane.org/gmane.emacs.orgmode/45316 and can *sometimes* be circumvented by executing org-reload. In the particular example shown below, the HTML export works as expected, but the PDF export fails with message: org-export-latex-preprocess: Wrong type argument: stringp, nil By the way, everything worked fine in the example until I added the last source block: #+begin_src R x #+end_src I tried using what I take to be the latest version of Org-Mode: Org-mode version 7.7 (release_7.7.290.g65d05) but that only made things worse. I tried an HTML export with this version, and it generated a horrendous-looking message that begins with: org-babel-R-evaluate: Wrong number of arguments: #[(session body result-type result-params column-names-p row-names-p) Æ=}... followed by a bunch of stuff containing enough non-printing characters that it's hard to reproduce in email, and ending with: ...org-mode/lisp/ob-R.elc . 9734)], 5 I'd welcome any help/advice that anybody can provide. Thanks, -- Mike ## Sample file that exhibits some export problems #+TITLE: This is a test #+AUTHOR: Michael Hannon #+email: jm_han...@yahoo.com #+BABEL: :session *R* :cache yes :results output graphics :exports both :tangle yes * Getting Started ** Batch Mode #+begin_src R :exports code pdf(xh.pdf) # set graphical output file hist(rnorm(100)) # generate 100 N(0,1) variates and plot their histogram dev.off() # close the graphical output file #+end_src If we put the code above in a file called =z.R=, we can execute the code from the command line via: =R CMD BATCH z.R= #+begin_src R x - c(1, 3, 5) #+end_src #+begin_src R x[3] #+end_src #+begin_src R q - c(x,x,8) #+end_src #+begin_src R x #+end_src
Re: [O] Collapsing tracked time?
Take a look at the org-clock-into-drawer and org-log-into-drawer variables: http://orgmode.org/manual/Clocking-commands.html http://orgmode.org/manual/Tracking-TODO-state-changes.html Does this do what you want? Stuart On 09/16/2011 09:01 PM, Steinar Bang wrote: For one particular long running TODO, I have to scroll over several (well... more than one) screen pages of time stamps until I get to the payload. Is it possible to let the time stamps be collapsed/hidden by default, and only toggle them visible if I need to adjust a time stamp or two? Thanks! - Steinar -- Stuart Hickinbottom
[O] Escaping in HTML Export
I'm seeing an example where Org-mode fails to escape and signs on HTML exporting. This is also breaking the claim of XHTML Strict. -- - Pavel Panchekha
[O] shortcuts to hide nearest heading or sparse tree
I have been studying extensively and have not found a quick way to hide the nearest heading (which contains point) as well as the entire sparse tree. I often have two or more sparse trees open as I go look for information elsewhere and then want to return to the place I was at. So, can I be lazy and do these operations with a few keys?
[O] Feature Request: fully reveal links when isearch stops there
When I isearch for `foo' and find it in `[[foo][bar]]', I would like org buffers to show me the whole link, verbatim, rather than merely showing bar. It's not very useful to see only the description in these cases. TIA, -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Re: [O] Problems with Org-Mode export
At Fri, 16 Sep 2011 10:50:01 -0700 (PDT), Michael Hannon wrote: Greetings. I've been having problems lately in exporting Org-Mode source-code documents to HTML and/or PDF. I'm running Org-Mode 7.7 with Emacs 23 on 64-bit linux (Fedora 15). I've appended a document that exhibits at least some of the problem. The problems are similar to the problem described at: http://comments.gmane.org/gmane.emacs.orgmode/45316 and can *sometimes* be circumvented by executing org-reload. In the particular example shown below, the HTML export works as expected, but the PDF export fails with message: org-export-latex-preprocess: Wrong type argument: stringp, nil By the way, everything worked fine in the example until I added the last source block: #+begin_src R x #+end_src I tried using what I take to be the latest version of Org-Mode: Org-mode version 7.7 (release_7.7.290.g65d05) but that only made things worse. I tried an HTML export with this version, and it generated a horrendous-looking message that begins with: org-babel-R-evaluate: Wrong number of arguments: #[(session body result-type result-params column-names-p row-names-p) Æ=}... followed by a bunch of stuff containing enough non-printing characters that it's hard to reproduce in email, and ending with: ...org-mode/lisp/ob-R.elc . 9734)], 5 I'd welcome any help/advice that anybody can provide. Could I ask you to provide the entire backtrace for both errors? M-x toggle-debug-on-error RET The backtrace might contain information about the exact place where a string is expected. If you can't copy it into the email program save to disk + gzip + attach should do the trick. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpAA75epbMNO.pgp Description: PGP signature
