Re: [O] LaTeX export: footnotes vs. angle brackets in Babel snippets
Hello, l...@gnu.org (Ludovic Courtès) writes: The LaTeX exporter of Org 7.7 from a recent Emacs snapshot improperly interprets sequences with angle brackets in Babel snippets as if they were footnote references, as in: #+BEGIN_src C int array[2]; #+END_src This leads to a wrong-type-arg error in ‘org-export-latex-preprocess’. This bug has been fixed in the development version. You may upgrade or wait for Org 7.8. Regards, -- Nicolas Goaziou
[O] Bugs in lisp/ob-lilypond.el
Dear Martyn Jago, dear all, I just pulled the latest version of Org mode and noticed a few bugs in the Lilypond support of Org babel that have not been there in the previous version (so far I was still using version 7.6). In general, there seems to be problems in parsing the line that starts #+begin_src lilypond. More specifically, - Global :noweb settings are now ignored - Any settings after the setting :file will be added to output file name! - Settings after :noweb yes cause trouble (disable this setting) Again, thanks for lisp/ob-lilypond.el in the first place. Best wishes, Torsten -- Dr Torsten Anders Course Leader, Music Technology University of Bedfordshire Park Square, Room A315 torsten.and...@beds.ac.uk http://strasheela.sourceforge.net http://www.torsten-anders.de
Re: [O] Not overwriting unchanged source code files when tangling
Such tools are for example scons is a make alternative that rethinks make's older timestamp = rebuild From www.scons.org/architecture/index.html *(S)Cons decides if a file was out-of-date by using MD5 checksums of the contents of files, not timestamps. * SCons also comes to mind because you are using make for R not (traditional) programming *Most of the build tools just mentioned were written by programmers and for programmers. The fact that most programmer-friendly utilities do a poor job of fulfilling the needs of non-programmers prompted Greg Wilson to organize the Software Carpentry competition in January 2000. Software Carpentry was an open design contest with the express goal of producing a set of next-generation utilities, including a build tool, that would be accessible not only to programmers but also to computer **users** such as physical scientists. * [Disclaimer: Ive not tried scons myself]
Re: [O] How to estimate effort by week?
Christoph LANGE ch.la...@jacobs-university.de writes: Hi Christian, 2011-11-18 17:32 Christian Egli: Christoph LANGEch.la...@jacobs-university.de writes: is there any way of estimating effort by week? Have a look at the doc string of org-effort-durations. Documentation: Conversion factor to minutes for an effort modifier. Thanks for your pointer, but (if I got you right) that wasn't what I meant to ask. So let me try to ask more precisely: I was not interested in expressing that a task would take me an estimated time of N weeks, but in expressing that I would spend at most some amount of time per week on that task. Hi Christoph, Is this to help limit you to that time per week or for estimating? For limiting you can set up something like this: --8---cut here---start-8--- * STARTED Some task SCHEDULED: 2011-11-21 Mon +1w :LOGBOOK: - State DONE from STARTED[2011-11-19 Sat 10:27] CLOCK: [2011-11-19 Sat 10:25]--[2011-11-19 Sat 10:27] = 0:02 CLOCK: [2011-11-19 Sat 09:28]--[2011-11-19 Sat 10:27] = 0:59 :END: :PROPERTIES: :Effort: 1:00 :LAST_REPEAT: [2011-11-19 Sat 10:27] :END: Limit work to 60 minutes per week Let it repeat for next week --8---cut here---end---8--- where the task repeats at some interval (weekly since you want to work up to 1 hour per week on this task). When you clock in the task the modeline shows your current clocked minutes on the task _since your last repeat_. Set your Effort property to the limit you want for the task for the interval and set your repeat to the size of your interval (1 hour per week in this case) So when you reach the limit of 1 hour (in this case) you mark the task DONE which stops the clock and rescheduled the task to the next repeat date. When you clock the task in again the modeline shows 0:00 and counts up to the effort limit again. Does that help? Regards, Bernt
Re: [O] Bugs in lisp/ob-lilypond.el
Also, the setting results: silent seems to be ignored. Best wishes, Torsten On 19 Nov 2011, at 15:22, Torsten Anders wrote: Dear Martyn Jago, dear all, I just pulled the latest version of Org mode and noticed a few bugs in the Lilypond support of Org babel that have not been there in the previous version (so far I was still using version 7.6). In general, there seems to be problems in parsing the line that starts #+begin_src lilypond. More specifically, - Global :noweb settings are now ignored - Any settings after the setting :file will be added to output file name! - Settings after :noweb yes cause trouble (disable this setting) Again, thanks for lisp/ob-lilypond.el in the first place. Best wishes, Torsten -- Dr Torsten Anders Course Leader, Music Technology University of Bedfordshire Park Square, Room A315 torsten.and...@beds.ac.uk http://strasheela.sourceforge.net http://www.torsten-anders.de
Re: [O] Not overwriting unchanged source code files when tangling
Sorry for the earlier mail: Send got pressed on a half-cooked mail :-) Heres a cleanup. -- Build-tools like scons rethink make's older timestamp = rebuild model. You may want to look at one such. From http://www.scons.org/architecture/index.html (S)Cons decides if a file was out-of-date by using MD5 checksums of the contents of files, not timestamps. SCons also comes to mind because you are using make for R not (traditional) programming [Again from the above link] Most of the build tools just mentioned were written by programmers and for programmers. (SCons arose from a) design contest with the express goal of producing a set of next-generation utilities, including a build tool, that would be accessible not only to programmers but also to computer users such as physical scientists. [Disclaimer: Ive not tried Scons myself]
Re: [O] Not overwriting unchanged source code files when tangling
Holger Hoefling hhoef...@gmail.com writes: Hi Carsten, thanks for the suggestion, but as I agree with Brian. If there is more than one source file in the org-file, then the whole project would still be recompiled, not just the updated file.To be more exact, I actually don#39;t want to compile things, but run R scripts using make. There are caching tools in R that might handle this. packages weaver and cacheSweave come to mind. For example, tangling your *.org file to produce a trivial Sweave document consisting of a single code chunk with the 'cache=T' argument, then Sweaving it using the 'weaver' driver from the weaver package will cache all the computations. Subsequent changes to the code followed by a new weave will result in cached values being used when possible and fresh computations being done as needed. I believe this is done on an expression by expression basis so adding a bit of whitespace or a comment will not trigger recomputation. So you can overwrite the document and making trivial changes to expressions without having to recompute expressions that have not changed (and have no dependencies that are changed). HTH, Chuck So the waiting time if a computationally intensive step is repeated although it is not necessary can be substantial. I wonder how difficult the following change would be (no emacs lisp experience, also do not know the org source code):- would it be possible to write out the source files when tangling into a temporary directory, then compare to the actual target files and overwrite only if something has changed? Then the time stamps would stay fixed. Hopefully, this would not involve too much work: - creating temporary files and remembering the mapping to true files- tangling out as usual into temporary files (so probably little change there)- compare temporary file to true file (does emacs already have a diff utility that could be used?) - overwrite true file if any changes- delete temporary filesEspecially, with this method no dependencies would be necessary and it would not be necessary to keep track in the org files which source blocks have been changed since the last tangling Thank you for your suggestionHolger On Fri, Nov 18, 2011 at 6:02 PM, Carsten Dominik span dir=ltrmailto:carsten.domi...@gmail.com/span wrote: On 18.11.2011, at 14:17, Holger Hoefling wrote: Hi, I have a problem/request for org-mode and was looking for help. I am using org-mode to write source code files and tangle them out. I want to compile them using make. My problem now is that org-mode overwrites the old files every time I tangle them out, therefore also updating the time stamp - even if nothing has changed. Subsequently, when I run make, everything gets recompiled, not just the changed source code files as all time stamps have changed. Is there an option for org-mode to only overwrite source code files that get tangled out if they have truly changed? How about changing the make file so that the dependence is on the Org file, not on the source file? You could then arrange for make to call emacs in batch-mode to tangle the source file and then compile it? Something along the lines of (untested, and probably wrong in this way...) file.o: http://somefile.org emacs -batch --eval #39;(org-babel-tangle-file http://somefile.org;)#39; cc file.o - Carsten -- Charles C. BerryDept of Family/Preventive Medicine cbe...@tajo.ucsd.eduUC San Diego http://famprevmed.ucsd.edu/faculty/cberry/ La Jolla, San Diego 92093-0901
[O] Feature request: hide target brackets
Targets and radio targets are great for ensuring that internal hyperlinks go to the right place in your org document. The problem with them, though, is that they clutter up the text, making it less readable. Attempts to get around this problem cause more problems. For example, to avoid the clutter, I often end up making a target below a headline that is an exact copy of the headline text, like this: * Correlation * Mutual Information Mutual Information *** parametric *** non-parametric * Correntropy When the top headlines are collapsed, the above looks like: * Correlation * Mutual Information * Correntropy This is cleaner than putting the target in the headline, which would look like this when collapsed: * Correlation * Mutual Information * Correntropy However, my redundant headline target is a maintenance mess (if you change the headline, you need to remember to change the target) and when the headline is expanded, things are even more cluttered. So, here's my feature request: Hide the target angle brackets in the same way that square brackets are hidden for hyperlinks. In other words, targets or radio targets should be displayed as targets and radio targets where a unique font tells you that they are targets. The hidden angle brackets could be exposed by hitting delete when at the right side of the target (similar to how hidden hyperlink text is exposed now). Code already exists to to do exactly this for [[hyperlinks]], and I thought that it would be easy to reuse it for hiding targets. But after several hours of digging around, I realized that this is a job for the experts. Is anyone interested in taking it on? I think it would be a big improvement. Thanks everybody for all the excellent work on org-mode! Scott
Re: [O] Not overwriting unchanged source code files when tangling
Hi everyone, I wanted to thank everyone for their helpful suggestions and wanted to share the best solutions I heard of and found. One solution is to include a rule in the makefile for every sourcecode file that that copies it and only updates the copy if something has changed (see Nick's email below). Another one is the use of a non-standard make program like makepp, that allows for using md5 checksums for files instead of timestamp in order to derive which files have to be rebuild. Thanks again! Holger On Sat, Nov 19, 2011 at 7:58 AM, Holger Hoefling hhoef...@gmail.com wrote: Hey Nick, thank you very much. That sounds like a very good solution to my problem that does not require changes to org-mode. Best Holger On Sat, Nov 19, 2011 at 5:00 AM, Nick Dokos nicholas.do...@hp.com wrote: Holger Hoefling hhoef...@gmail.com wrote: I think you misunderstood me there - I am actually not worried about how computationally intensive the tangling process is. This always works very quickly, so even if they have to be copied around and take a bit longer, I would not mind. Ah, ok - so you are talking about tanglecompile org --- bunch of files - output The tangling step produces a bunch of files that are (re)compiled (or in any case require some sort of lengthy processing) to produce some output file. IMO, the best way to deal with it is still make: let's say foo.org a.x b.x c.x -- foo.out where the first arrow is the tangle and the second arrow is some processor, call it X. The standard way to set up a makefile is schematically: --8---cut here---start-8--- foo.out: a.x b.x c.x X a.x b.c c.x -o foo.out a.x b.x c.x: foo.org tangle foo.org --8---cut here---end---8--- Rewrite the make file as follows: --8---cut here---start-8--- foo.out: a.y b.y c.y X a.y b.y c.y -o foo.out a.y: a.x cmp --silent a.x a.y || cp a.x a.y b.y: b.x cmp --silent b.x b.y || cp b.x b.y c.y: c.x cmp --silent c.x c.y || cp c.x c.y a.x b.x c.x: foo.org tangle foo.org --8---cut here---end---8--- So if the *contents* of (say) a.x have not changed by the tangling, it compares equal to a.y and the copy is skipped. That leaves a.y untouched. OTOH, if the contents of a.x change (or a.y does not exist in the first place), the comparison fails and we copy a.x to a.y. That updates a.y and forces further updates on anything that depends on it. Using some make fu (works for GNU make, but not necessarily for other makes), you can write it more compactly: --8---cut here---start-8--- foo.out: a.y b.y c.y X a.y b.y c.y -o foo.out %.y: %.x -cmp --silent $ $@ || cp $ $@ a.x b.x c.x: foo.org tangle foo.org --8---cut here---end---8--- HTH, Nick
[O] pc-keys mode does not work in org mode
I just started using: http://www.emacswiki.org/cgi-bin/wiki/download/pc-keys.el Very handy indeed. As far as I can see know, it works okay except in org-mode. I think this is because of these two lines in org.el: (define-key org-mode-map [home] 'org-beginning-of-line) (define-key org-mode-map [end] 'org-end-of-line) Could they be removed, or made more intelligent? Because org-mode is one of the most used modes for me and it would be very nice if I could use pc-keys there also. -- Cecil Westerhof Senior Software Engineer LinkedIn: http://www.linkedin.com/in/cecilwesterhof
Re: [O] Details of compling and running C++ code from Org-mode?
Nice. Very interesting and informative. Thanks, Eric.
-- Mike
- Original Message -
From: Eric Schulte schulte.e...@gmail.com
To: Michael Hannon jm_han...@yahoo.com
Cc: Org-Mode List emacs-orgmode@gnu.org
Sent: Friday, November 18, 2011 11:39 AM
Subject: Re: [O] Details of compling and running C++ code from Org-mode?
Hi Michael,
Michael Hannon jm_han...@yahoo.com writes:
Greetings. I'm curious about the process of executing a program that
is
compiled from a source block in Org-mode.
Some background: I was playing with some C++ code (a slight generalization
of
some code I found in a book). I wanted to use the assign
method to
initialize a vector, as:
vectorint testVec(5, 0);
testVec.assign({2, 4, 6, 8, 10});
It turns out that to do this one has to tell g++ (in my case) to use the
latest version of the C++ standard. I discovered that I could do this via:
(setq org-babel-C++-compiler g++ -std=c++0x)
You could also use the :flags header argument (:flags -std=c++0x) to
pass this flag to g++.
This got me to wondering if there were any similar hooks that relate to
running the program once it's compiled. I looked through the list of
org-babel* variables, but didn't find anything obvious.
So what does happen when I hit C-c C-c in, say, a cpp source-code block?
The
contents of the file are evidently written to a temporary file, after which
the command specified by org-babel-C++-compiler is run on that file. The
results of the compilation are stuck some place -- another temporary file,
I
suppose. Then the second, executable file is run and the results
collected.
Thanks for asking this question, and sorry it took so long to respond.
I've placed an annotated copy of the relevant code up at [1] which
should explain the evaluation process for c/c++ code. In many cases
browsing the relevant org-babel-execute:* function for your language is
the best way to discover what flags are available.
What command runs the file?
The file itself is called directly.
Is there any control from Org-mode over this second stage of the
process?
Yes, the :cmdline header argument may be used to pass values to the
executing file.
Best -- Eric
Thanks,
-- Mike
Footnotes:
[1] http://cs.unm.edu/~eschulte/data/babel-c-execution.html
http://cs.unm.edu/~eschulte/data/babel-c-execution.org
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] Bugs in lisp/ob-lilypond.el
Hi Torston Torsten Anders torsten.and...@beds.ac.uk writes: Also, the setting results: silent seems to be ignored. Best wishes, Torsten On 19 Nov 2011, at 15:22, Torsten Anders wrote: Dear Martyn Jago, dear all, I just pulled the latest version of Org mode and noticed a few bugs in the Lilypond support of Org babel that have not been there in the previous version (so far I was still using version 7.6). In general, there seems to be problems in parsing the line that starts #+begin_src lilypond. More specifically, - Global :noweb settings are now ignored - Any settings after the setting :file will be added to output file name! - Settings after :noweb yes cause trouble (disable this setting) Thanks for the heads-up Torsten - there have been many changes to the bare-metal Org as you probably are aware. Your observations will come in very useful to sort out the transition to the new improved order (which I am totally in favor of by the way), and the details you provide will prove very useful. Certainly consider checking out a `less hot' release to get working again ( i.e. git checkout release_7.7 ). In the mean-time I will work on compatibility (tomorrow hopefully) - and better regression tests. Great to hear you're making use of ob-lilypond by the way! Best, Martyn Again, thanks for lisp/ob-lilypond.el in the first place. Best wishes, Torsten -- Dr Torsten Anders Course Leader, Music Technology University of Bedfordshire Park Square, Room A315 torsten.and...@beds.ac.uk http://strasheela.sourceforge.net http://www.torsten-anders.de
[O] [PATCH] Fix marker in no buffer error for task state change in an indirect buffer
* lisp/org-clock.el (org-clock-out-if-current): Fix marker in no buffer error for task state change in an indirect buffer org-clock-out-when-current was enhanced in 098cf35 (Clock: Clock out when done also in indirect buffers, 2009-03-23) to handle indirect buffers. This enhancement uses (buffer-base-buffer (org-clocking-buffer)) but when not clocking (org-clocking-buffer) returns nil - so buffer-base-buffer returns the base buffer of the current buffer which is never nil. This leads to marker in no buffer errors trying to stop the clock when it is not running. Now we explicitly check up front that the clock is running before any other conditions that lead to stopping the clock. --- cc:ing Carsten since this is his code Hi Dave, After much difficulty I was able to reproduce this problem. It would have been helpful to include basic information about what triggers the bug for you. - clock is not running - You are working in an indirect buffer - You change a todo state keyword to DONE This works fine for me when not in an indirect buffer. The git commit you have referenced in this report is not part of the org repository which also made me think you had local changes that affected this issue since I couldn't reproduce it for the first 20 minutes of looking at this issue. Please try this patch and report back if it works or not. Thanks, Bernt lisp/org-clock.el |3 ++- 1 files changed, 2 insertions(+), 1 deletions(-) diff --git a/lisp/org-clock.el b/lisp/org-clock.el index 5dbe4dc..9107400 100644 --- a/lisp/org-clock.el +++ b/lisp/org-clock.el @@ -1696,7 +1696,8 @@ from the `before-change-functions' in the current buffer. Clock out if the current entry contains the running clock. This is used to stop the clock after a TODO entry is marked DONE, and is only done if the variable `org-clock-out-when-done' is not nil. - (when (and org-clock-out-when-done + (when (and (org-clocking-p) +org-clock-out-when-done (or (and (eq t org-clock-out-when-done) (member state org-done-keywords)) (and (listp org-clock-out-when-done) -- 1.7.8.rc3
[O] Bug: Cloning tasks deletes clock time in the original [7.7 (release_7.7-571-gf558105)]
Consider the following org file: --8---cut here---start-8--- * Orig Task 1 SCHEDULED: 2011-11-19 Sat +1w :LOGBOOK: - Note taken on [2011-11-19 Sat 21:24] \\ foo CLOCK: [2011-11-18 Fri 20:30]--[2011-11-18 Fri 21:24] = 0:54 CLOCK: [2011-11-19 Sat 20:23]--[2011-11-19 Sat 21:23] = 1:00 :END: [2011-11-19 Sat 21:23] --8---cut here---end---8--- This is a repeating task with some clock time on it. Now I need to change the 2nd occurrence from now so I clone the task to create 2 more followed by the repeater as follows: On the task do C-c C-x c 2 RET +1w RET Now I get this so I can edit one of the individual entries --8---cut here---start-8--- * Orig Task 1 SCHEDULED: 2011-11-19 Sat :LOGBOOK: - Note taken on [2011-11-19 Sat 21:24] \\ foo :END: [2011-11-19 Sat 21:23] * Orig Task 1 SCHEDULED: 2011-11-26 Sat :LOGBOOK: - Note taken on [2011-11-26 Sat 21:24] \\ foo :END: [2011-11-26 Sat 21:23] * Orig Task 1 SCHEDULED: 2011-12-03 Sat :LOGBOOK: - Note taken on [2011-12-03 Sat 21:24] \\ foo :END: [2011-12-03 Sat 21:23] * Orig Task 1 SCHEDULED: 2011-12-10 Sat +1w :LOGBOOK: - Note taken on [2011-12-10 Sat 21:24] \\ foo :END: [2011-12-10 Sat 21:23] --8---cut here---end---8--- I have the entries I want but my original clock lines have been deleted. I would expect this behaviour for the newly created clones only - not the original entry. I ran into this for a weekly meeting task I cloned and ended up recovering my clock lines from my hourly git repository but this shouldn't be necessary. I'm also not sure exactly why I get 3 entries when I ask for two -- maybe that's a special case of the repeater in the original task but it feels weird. Regards, Bernt Emacs : GNU Emacs 23.2.1 (i486-pc-linux-gnu, GTK+ Version 2.20.0) of 2010-12-11 on raven, modified by Debian Package: Org-mode version 7.7 (release_7.7-571-gf558105)
