Re: [O] emacs-orgmode youtube videos questions
At Fri, 16 Sep 2011 23:34:44 -0400 (EDT), Jude DaShiell wrote: > > Will mplayer play those videos? mplayer-mt from debian-multimedia.org on Debian GNU/Linux 6.0.2 (current stable) has no problems to play videos I downloaded with youtube-dl (from Wheezy). IIRC the mplayer shipped with Debian 6.0.2 had no problems with .flv neither. > If yes, what kind of .mailcap entry will be needed to enable the > lynx browser to have mplayer used to play those videos when I hit > enter on a link? Can't help with that. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpBPQ3CdlKaM.pgp Description: PGP signature
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
[O] emacs-orgmode youtube videos questions
Will mplayer play those videos? If yes, what kind of .mailcap entry will be needed to enable the lynx browser to have mplayer used to play those videos when I hit enter on a link? I heard a little bit of one of these videos on a windows system and would like to arrange that capability on debian. Jude "I love the Pope, I love seeing him in his Pope-Mobile, his three feet of bullet proof plexi-glass. That's faith in action folks! You know he's got God on his side." ~ Bill Hicks
[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
[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] 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
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
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
>To: Org-Mode List
>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
>
>
>
>
[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] [babel] Some variables with no default value don't provoke an error
Hi Eric, Eric Schulte wrote: > "Sebastien Vauban" writes: >> Eric Schulte wrote: >>> "Sebastien Vauban" 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] 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] Bug: unable to open link unless `...from-string' [7.7 (release_7.7.292.g0d4e8.dirty)]
on Fri Sep 16 2011, David Maus 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:""/%%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
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
[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] 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 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)
[forgot to cc: the list] Cook, Malcolm 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] 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
[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
"Errand&TODO<>\"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-a
Re: [O] [babel] Export problem (Wrong type argument: consp, nil)
Hi "Sebastien Vauban" 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/
Re: [O] Four issues with org-babel-tangle
Christopher Genovese 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 wrote: > >> - Show quoted text - >> Christopher Genovese 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
Re: [O] [babel] Some variables with no default value don't provoke an error
Hi, "Sebastien Vauban" writes: > Hi Eric, > > Eric Schulte wrote: >> "Sebastien Vauban" 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] [babel] error when loading library-of-babel after update this morning
"Sebastien Vauban" 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/
[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] 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
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
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
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] Some variables with no default value don't provoke an error
Hi Eric, Eric Schulte wrote: > "Sebastien Vauban" 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] error when loading library-of-babel after update this morning
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... Best regards, Seb -- Sebastien Vauban
[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] Automatically insert R source code block?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16/09/11 02:22, Michael Hannon wrote: >> From: suvayu ali >> >> Hey Mike, >> >> On Fri, Sep 16, 2011 at 1:18 AM, Michael Hannon >> > 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 > -- 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-
