[O] Zero Warnings against Emacs-24
It is extremely good to see Org-mode builds against Emacs-24 with zero warnings. (with make up1 autoloads) Org-mode rocks, /and/ plays nicely with Emacs. Thanks Bastien, Achim, and Maintainers ~ I for one think such attention to detail is a real sign of quality. Also with zero test failures on my system - this must be a good sign for Emacs-24 up-coming release. Thanks, Martyn
Re: [O] local.mk and SUDO
Achim Gratz writes: > Martyn Jago writes: >>>> diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el >>>> old mode 100644 >>>> new mode 100755 [...] > Then you yourself must most likely have changed the mode of those files > to "executable". There is nothing in the build system that even > attempts to change modes. Hi Achim Since the new makefile uses the `install' command as opposed to `cp' to install files, the following is noted in man install: ,[*Man install*] | -m Specify an alternate mode. The default mode is set to rwxr-xr-x | (0755). The specified mode may be either an octal or symbolic value; | see chmod(1) for a description of possible mode values. ` Since the mode of .el files on git is 0644, this causes git to flag the files as modified (since I am running Org from the distribution directory). So the obvious answer is to not to use make install (as per the documentation). This is a heads-up to me since I believed install did more than simply moving .el and .elc files from A to B. However this is new behavior and worth mentioning. 'make install' (no sudo) used to silently `install' (or not as the case may be) and not change modes as above. Personally I wouldn't call it a regression though since make install is pointless IIUC in this situation. Since I can no longer use `make up2' it seems that `make up1' is the correct command for my situation. This works fine except that org-version points to the wrong org-install: --8<---cut here---start->8--- Org-mode version 7.8.09 (release_7.8.09-441-g6732d6.dirty @ /Applications/Emacs.app/Contents/Resources/lisp/org/org-install.el.gz) --8<---cut here---end--->8--- So for my case I've added the target upgrade to local.mk: --8<---cut here---start->8--- upgrade: up1 autoloads --8<---cut here---end--->8--- HTH Best, Martyn > Regards, > Achim.
Re: [O] Symbol's value as variable is void: org-version
Martyn Jago writes: > Hi Thomas > > t...@tsdye.com (Thomas S. Dye) writes: > > >> Aloha all, >> >> In the last day or so, I started running into a problem with a variable, >> org-version. >> >> When I look at Org/Documentation/Show Version, I get: >> Org-mode version N/A (N/A @ /Users/dk/.emacs.d/src/org/lisp/org-install.el) > > The quick answer - you can try make `autoloads' That should have been `make autoloads' Best, Martyn
Re: [O] Symbol's value as variable is void: org-version
Hi Thomas t...@tsdye.com (Thomas S. Dye) writes: > Aloha all, > > In the last day or so, I started running into a problem with a variable, > org-version. > > When I look at Org/Documentation/Show Version, I get: > Org-mode version N/A (N/A @ /Users/dk/.emacs.d/src/org/lisp/org-install.el) The quick answer - you can try make `autoloads' There have been recent threads about this problem. Best, Martyn [...] > > -- > Thomas S. Dye > http://www.tsdye.com
Re: [O] var `date' lacks a prefix warnings
Hi Bastien Bastien writes: > Hi Martyn, > > Martyn Jago writes: > [...] > We first need to fix Calendar so that it doesn't use ̀date' and `entry' > as the name for dynamically variables that are passed around. > > Then preparing a patch for Org would be great. > > I'll ping Glenn on the emacs-devel mailing list about this. I took in Glen's and Edward's replies - wow what a history lesson! - quote Edward Reingold: "who'd have guessed how much it would grow over almost 30 years, or that my code would still be around" [1] So it doesn't look like the problem will be fixed at source any time quickly. I'm going to persevere until I've talked myself out of it since I'm learning a lot! Best, Martyn bookmark: http://article.gmane.org/gmane.emacs.devel/150087
Re: [O] var `date' lacks a prefix warnings
Hi Achim Achim Gratz writes: > Martyn Jago writes: >> Regarding the remaining Org-mode `lacks a prefix' warnings and >> particularly in light of the recent message on emacs.devel [1] would it >> not be sufficient to simply alias date and entry locally: >> >> (defvaralias 'org--date 'date) >> (defvaralias 'org--entry 'entry) > > That doesn't work, AFAIK: defvaralias binds the symbol (it looks up > what is behind the symbol and creates another symbol for it), but > dynamic scoping does not (you look up what's behind the symbol each time > you use it). The problem is that when a symbol gets dynamically scoped > it cannot be used as a lexical symbol after that, so any code that uses > "date" and "entry" after the defvar doesn't get a lexcial binding. You > would need a language construct that would let you capture a symbol > dynamically, internalize it (in essence it would be renaming that symbol > in some scope) and then erase all traces of that symbol having been > symbolically scoped so that it can be used lexically again. I don't > think anything like that currently exists. I appreciate `defvaralias' doesn't work nicely with lexical variables, but I am assuming somewhat that we are talking about dynamic variables here? If the global date / entry are dynamic then the dynamic `defvaralias' alias will also be dynamic, and any prior use of the dynamic variable will surely be a dynamic binding? I'm going to do some further testing anyway, since I'm interested, but so far things appear to work. >> p.s. I should point out that my personal view is that a serious well >> maintained Emacs library such as Org-mode should have a zero warning >> policy for official releases. > > Here's a problem that originates outside of our control. At the very > least, we can't fix it just in org. I agree we can't fix the source of the problem but IF we can fix the warning by removing `lack of prefixes' in Org-mode, then we have demonstrated that we acknowledge the warning and have dealt with it. In other words, if we can fix the problem within Org-mode we are not propagating the problem. If we don't, then perhaps we didn't fix the warning because we don't fix warnings. However, it may indeed be impossible to fix as you pointed out! Best, Martyn
Re: [O] local.mk and SUDO
Hi Achim Achim Gratz writes: > Martyn Jago writes: >> However, when I've just gone to run `make up2' (awesome command by the >> way), I get the error: > [...] >> diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el >> old mode 100644 >> new mode 100755 > > That's a well-known problem with anything that expects POSIX file > semantics on Windows... and Git does rely very heavily on it. > I'm not on Windows, I'm on Mac OS X which usually handles Git nicely - I use it all the time. Best, Martyn
[O] var `date' lacks a prefix warnings
Regarding the remaining Org-mode `lacks a prefix' warnings and particularly in light of the recent message on emacs.devel [1] would it not be sufficient to simply alias date and entry locally: --8<---cut here---start->8--- (defvaralias 'org--date 'date) (defvaralias 'org--entry 'entry) --8<---cut here---end--->8--- Presumably this would be backwardly-compatible, and given a subsequent name change in diary-lib.el a very simple integration test could catch that very quickly. If I get a positive response I can perhaps look at a patch and tests, but if my understanding is amiss I will appreciate the heads-up. Best, Martyn p.s. I should point out that my personal view is that a serious well maintained Emacs library such as Org-mode should have a zero warning policy for official releases. Footnotes: [1] From: Chong Yidong Subject: Evil defvars in org.el Newsgroups: gmane.emacs.devel To: Bastien Guerry Cc: emacs-de...@gnu.org Date: Fri, 27 Apr 2012 11:17:37 +0800 (9 hours, 36 minutes, 57 seconds ago)
[O] local.mk and SUDO
I have a local.mk set up with my particular settings, and with SUDO set to blank, as per the comment in default.mk: ,[default.mk] | # How to obtain administrative privileges | # SUDO= # leave blank if you don't need this | SUDO = sudo ` ...since my org-mode files location doesn't require supervisor access (typically I have 4 org-mode installs, and 4 Emacs versions for testing, although currently I'm just running my working system). However, when I've just gone to run `make up2' (awesome command by the way), I get the error: --8<---cut here---start->8--- > make up2 git remote update Fetching origin git pull Updating abd49c8..0233eb9 error: Your local changes to the following files would be overwritten by merge: contrib/lisp/org-export.el lisp/ob-R.el lisp/ob-python.el lisp/ob.el lisp/org-agenda.el lisp/org-beamer.el lisp/org-bibtex.el lisp/org-capture.el lisp/org-clock.el lisp/org-colview-xemacs.el lisp/org-colview.el lisp/org-ctags.el lisp/org-exp.el lisp/org-faces.el lisp/org-footnote.el lisp/org-gnus.el lisp/org-latex.el lisp/org-mouse.el lisp/org-odt.el lisp/org-publish.el lisp/org-table.el lisp/org.el --8<---cut here---end--->8--- After investigation it turns out the problem is a permissions issue: --8<---cut here---start->8--- diff --git a/lisp/org-mobile.el b/lisp/org-mobile.el old mode 100644 new mode 100755 --8<---cut here---end--->8--- After further investigation, I have modified git config to overide the core.filemode setting which works for me: , | core.fileMode |If false, the executable bit differences between the index and the |working copy are ignored; useful on broken filesystems like FAT. |See git-update-index(1). True by default. ` --8<---cut here---start->8--- git config core.filemode false --8<---cut here---end--->8--- So really - this is just a heads-up of my experience setting SUDO to blank, but it would be nice to know if this is expected behavior? If it turns out that it is, then perhaps I can supply a documentation patch (an extra comment in default.mk). HTH Best, Martyn
Re: [O] missing autoloads / (void-variable org-version)
Hi Achim Achim Gratz writes: > Since my Makefile branch was merged I've been getting flak for breaking > certain setups. Now, the change didn't actually break them, but I did > make (perhaps foolishly) a deliberate decision to make that particular > breakage fatal rather than silent. It would be very easy to continue to > paper over the breakage and pretend things are working when they're not. > What irritates me greatly is that quite a few of the people that insist > on this "solution" are the ones who would have to deal with the > Heisenbugs thus introduced. So let me explain once more what is broken: > [...] Thanks for this post - it has certainly helped me see the `rock' and the `hard place'. As an aside, I haven't used MS windows for some two years (using OS X and Linux), but this will change shortly as my next project will require a working Windows system with MSys. I could certainly document the setup of Org-mode including functioning tests etc. on a line-by-line basis if it will help. Best, Martyn > > Regards, > Achim.
Re: [O] error on opening org-file with #+startup: indent
Hi Achim Achim Gratz writes: > Fritz Kunze writes: >> I ran M-x load-library org followed by M-x org-version - which >> returned 7.8.09. > > You didn't generate and (require 'org-install). > >> (Incidentally, and for the sake of completeness in this >> report, I built the compiled version of this upgrade by using >> >> M-x cd ~/.emacs.d/org-7.8.09/ followed by C-u 0 M-x >> byte-recompile-directory) > > You still don't have org-install.el > I think this tone of reply is very harsh, and I feel for the OP. Has it suddenly become a requirement to know emacs-lisp, and have a reasonable understanding of `autoload' to even install? A very formal announcement and good documentation would perhaps have been a good idea. Don't get me wrong - I like the new makefile, but there *is* now magic that there never was, without question. I think it would be better to refer to some good documentation rather than short terse admonishment over something that `used to work'. My 2c. Best, Martyn >> I renamed the org-6.36 folder. I started up emacs and the error >> still appeared. > > You do not have org-install.el and you are picking up outdated autoload > definitions from your emacs installation. > >> As an experiment, I modified the load-path to consist only of one >> statement: >> (add-to-list 'load-path "~/.emacs.d/org-7.8.09/") >> ; (add-to-list 'load-path "~/.emacs.d/org-7.8.09/contrib/lisp") >> And suddenly the "bug" vanished. What's going on - do you have any >> idea? I thought I would certainly need this >> directory "~/.emacs.d/org-7.8.09/contrib/lisp" in my load-path. > > Fix the installation first and then worry about things in contrib/. > > > Regards, > Achim.
Re: [O] Makefile restructuring
Achim Gratz writes: Hi Achim > Martyn Jago writes: >> Works nicely for me too, and I have a modified local.mk config for >> multiple Emacs versions and a non-default org location. >> >> Note: `make install check' will make, install, and run the tests! > > Actually, "make up2" will update all remotes, do a "git pull" on the > current branch, compile and test and then finally install org all in one > go. Once you have set things up the way you like, that's the fastest > way to keep current. The real advantage however is that if there > happens to be an error someplace, make is smart enough to stop right > there and not install a not-quite working org over an older, but working > version. > > > Regards, > Achim. Very good! Is it documented? Love it. Best, Martyn
Re: [O] Makefile restructuring
Hi Achim François Allisson writes: >> Achim's branch is now merged in Org's git master branch. >> >> Please test this and report any problem while using make >> to install Org. >> >> -- >> Bastien >> > > It runs smoothly for me, using make clean, make, make doc, and make > install (without local.mk, having yet no need of it). > > François. Works nicely for me too, and I have a modified local.mk config for multiple Emacs versions and a non-default org location. Note: `make install check' will make, install, and run the tests! Thanks Achim. Best, Martyn
[O] [bug] Regression due to relocation of org-export.el
Hi There's a small regression in org-export due to removal of EXPERIMENTAL / relocation. Best, Martyn >From eb3c7717cdd4a4dc1e5f76da4746293ff6f40d17 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Sat, 21 Apr 2012 18:02:27 +0100 Subject: [PATCH] Fix require path due to removal of EXPERIMENTAL * contrib/lisp/org-export.el: path relative to org-export.el has changed due to relocation of org-e-publish.el (removal of EXPERIMENTAL) --- contrib/lisp/org-export.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/contrib/lisp/org-export.el b/contrib/lisp/org-export.el index 142b0fa..939a697 100644 --- a/contrib/lisp/org-export.el +++ b/contrib/lisp/org-export.el @@ -97,7 +97,7 @@ (require 'org-e-html "./org-e-html.el") (require 'org-e-latex "./org-e-latex.el") (require 'org-e-odt "./org-e-odt.el") -(require 'org-e-publish "../org-e-publish.el") +(require 'org-e-publish "./org-e-publish.el") -- 1.7.3.4
Re: [O] org-program-exists vs executable-find
Hi "Sebastien Vauban" writes: > Hi Bastien, > > Bastien wrote: >> "Sebastien Vauban" writes: >> The name `org-program-exists' is actually misleading, it should be `org-executable-call' instead, while still checking if the executable exists before calling it. >>> >>> Nope, the name is not misleading. The documentation string is false -- what >>> I hadn't noticed, btw. >>> >>> That function just checks if the executable can be found; it does _not_ >>> call it afterward. >> >> You're right, I just fixed the docstring. >> >>> On Linux and Mac OS, it just calls "which + ", no more... On >>> Windows, it simply fails immediately (even if the program could be found). >> >> If there is an equivalent of `which' on windows let me know, > > Not that I know, reason why I (must) have Cygwin... > >> we can generalize this function. > > Why not replacing it simply by `executable-find': I don't see what it adds to > it? I would not say so if it was some upper abstraction, but I do feel > they're simply the same. > > If not, the opposite should be done: replacing the 10 calls to > `executable-find' by calls to `org-program-exists'... > > Best regards, > Seb IIRC on Mac OS `which' is not guaranteed to work anyway, since by default the `which database' is not instantiated or maintained. I had to kick that off manually here to have use of `which'. Best, Martyn
Re: [O] Frequent crashes of Emacs 24 on Mac OS X 10.7.3 due to org-mode
Ho Marius Marius Hofert writes: > There was another crash this morning, here is the report (as from > Console.app): > > Process: Emacs [6378] > Path:/Applications/Emacs.app/Contents/MacOS/Emacs > Identifier: org.gnu.Emacs > Version: Version 24.0.95 (9.0) > Code Type: X86-64 (Native) > Parent Process: launchd [117] > > Date/Time: 2012-04-17 11:57:41.796 +0200 > OS Version: Mac OS X 10.7.3 (11D50) > Report Version: 9 > > Crashed Thread: 0 Dispatch queue: com.apple.main-thread > > Exception Type: EXC_BAD_ACCESS (SIGABRT) > Exception Codes: KERN_INVALID_ADDRESS at 0x0018 > > VM Regions Near 0x18: > --> > __TEXT 0001-000100203000 [ 2060K] r-x/rwx > SM=COW /Applications/Emacs.app/Contents/MacOS/Emacs > > Application Specific Information: > objc[6378]: garbage collection is OFF > abort() called > > Thread 0 Crashed:: Dispatch queue: com.apple.main-thread > 0 libsystem_kernel.dylib0x7fff9801a82a __kill + 10 > 1 org.gnu.Emacs 0x0001000a824b fatal_error_signal + > 347 > 2 libsystem_c.dylib 0x7fff981cecfa _sigtramp + 26 > 3 libsystem_kernel.dylib0x7fff9801ace2 __pthread_kill + 10 > 4 libsystem_c.dylib 0x7fff9817c7d2 pthread_kill + 95 > 5 libsystem_c.dylib 0x7fff9816da7a abort + 143 > 6 org.gnu.Emacs 0x000100191f41 ns_term_shutdown + 81 > 7 org.gnu.Emacs 0x0001000a8217 fatal_error_signal + > 295 > 8 libsystem_c.dylib 0x7fff981cecfa _sigtramp + 26 > 9 libobjc.A.dylib 0x7fff9a22d3af > objc_msgSend_vtable14 + 47 > 10 org.gnu.Emacs 0x000100196268 > x_free_frame_resources + 216 > 11 org.gnu.Emacs 0x0001001963e9 x_destroy_window + 25 > 12 org.gnu.Emacs 0x0001000115bc delete_frame + 828 > 13 org.gnu.Emacs 0x000100123c55 Ffuncall + 1125 > 14 org.gnu.Emacs 0x00010011fff6 Fcall_interactively > + 6374 > 15 org.gnu.Emacs 0x000100123c42 Ffuncall + 1106 > 16 org.gnu.Emacs 0x000100123e26 call3 + 38 > 17 org.gnu.Emacs 0x0001000bc16e command_loop_1 + 1134 > 18 org.gnu.Emacs 0x000100122285 > internal_condition_case + 293 > 19 org.gnu.Emacs 0x0001000b1787 command_loop_2 + 55 > 20 org.gnu.Emacs 0x000100122389 internal_catch + 217 > 21 org.gnu.Emacs 0x0001000b1f0c recursive_edit_1 + > 364 > 22 org.gnu.Emacs 0x0001000b2082 Frecursive_edit + 290 > 23 org.gnu.Emacs 0x0001000a8f4e main + 3262 > 24 org.gnu.Emacs 0x000122f4 start + 52 > > Thread 1:: Dispatch queue: com.apple.libdispatch-manager > 0 libsystem_kernel.dylib0x7fff9801b7e6 kevent + 10 > 1 libdispatch.dylib 0x7fff931885be _dispatch_mgr_invoke > + 923 > 2 libdispatch.dylib 0x7fff9318714e _dispatch_mgr_thread > + 54 > > Thread 2: > 0 libsystem_kernel.dylib0x7fff9801b192 __workq_kernreturn + > 10 > 1 libsystem_c.dylib 0x7fff9817c594 _pthread_wqthread + > 758 > 2 libsystem_c.dylib 0x7fff9817db85 start_wqthread + 13 > > Thread 3: > 0 libsystem_kernel.dylib0x7fff9801b192 __workq_kernreturn + > 10 > 1 libsystem_c.dylib 0x7fff9817c594 _pthread_wqthread + > 758 > 2 libsystem_c.dylib 0x7fff9817db85 start_wqthread + 13 > > Thread 0 crashed with X86 Thread State (64-bit): > rax: 0x rbx: 0x0006 rcx: 0x7fff5fbfe628 > rdx: 0x > rdi: 0x18ea rsi: 0x0006 rbp: 0x7fff5fbfe660 > rsp: 0x7fff5fbfe628 >r8: 0x0001 r9: 0x0010 r10: 0x7fff9801ad0a > r11: 0xff80002d8220 > r12: 0x0006 r13: 0x00010058a688 r14: 0x7fff7f356960 > r15: 0x00010058a79c > rip: 0x7fff9801a82a rfl: 0x0202 cr2: 0x7fff7f34da28 > Logical CPU: 0 > > Binary Images: >0x1 -0x100202fef +org.gnu.Emacs (Version 24.0.95 - > 9.0) <7C48528A-6CE3-F9D3-AECA-8F5120471764> > /Applications/Emacs.app/Contents/MacOS/Emacs >0x100b29000 -0x100b2dff7 libFontRegistryUI.dylib (??? - ???) > <46FDC6A3-EF17-3E57-AACD-8B36AB1F00E9> > /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ATS.framework/Resources/libFontRegistryUI.dylib >0x100e69000 -0x100e6ffef libcldcpuengine.dylib (1.50.69 - > compatibility 1.0.0) > /System/Library/Frameworks/OpenCL.framework/Libraries/libcldcpuengine.dylib >0x100e76000
Re: [O] Frequent crashes of Emacs 24 on Mac OS X 10.7.3 due to org-mode
Hi Marius Marius Hofert writes: > Hi, > > I work with GNU Emacs 24.0.95.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) > [installed as Emacs-pretest-24.0.95-universal-10.6.8 from > http://emacsformacosx.com/builds ] on Mac OS X 10.7.3. (The reason for Emacs > 24 > is because of the latest features in Gnus). The org-mode version I use is > 7.8.08. > > I frequently experience crashes of Emacs during various tasks (see > http://stackoverflow.com/questions/10164425/emacs-almost-random-crashes-about-2-3-times-a-day-on-mac-os-x#comment13039387_10164425 > which I posted earlier today when I didn't know the cause of the crashes). By > checking Console.app, I found what I also suspected: org-mode causes the > crashes. The problem is, I don't know how to solve this problem (I'm an > enthusiastic [although maybe not really experienced] org-mode user and would > *really* like to use org-mode in the future as well). My setup is as follows: Org-mode version 7.8.08 (release_7.8.03.594.g013d.dirty) GNU Emacs 24.0.94.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-02-28 on bob.porkrind.org ... and Emacs never crashes - never ever! I don't use Sweave. - can you isolate what you do most use in your .emacs (easy if it's written in Org-babel). - Revert to 7.7. ~ test - Revert to 24.0.94.1 (macforosx binary build) ~ test I use it all the time (mostly Emacs but in and out of Org and Babel constantly) and it's solid, so it's probably your configuration. Best, Martyn
Re: [O] Ever used org-mode contrib packages?
suvayu ali writes: > Hi François, > > On Wed, Apr 11, 2012 at 21:22, François Allisson wrote: >> I'm curious >> to know what you are using from org-contrib... > > - I use org-notmuch to link to emails from org files. > - I also use org-occur-goto for easier navigation. > - I also use org-google-weather to display weather information in my > Agenda - org-drill - org-learn org-drill - heavily dependent on org-learn. If I had kids doing O-levels I would surely recommend it. Invaluable for stuff you want to learn by heart. Good documentation too. Best, Martyn
[O] [bug] (org-todo-list ) causes exception with sticky agenda buffers.
Hi I've noticed that if (org-todo-list ) is called programatically where `org-agenda-sticky' is set to t, an exception is caused: The exception happens in (org-prepare-agenda ): --8<---cut here---start->8--- (defun org-prepare-agenda (&optional name) (if (org-agenda-use-sticky-p) (progn ;; Popup existing buffer (org-prepare-agenda-window (get-buffer org-agenda-buffer-name)) (message "Sticky Agenda buffer, use `r' to refresh") (throw 'exit nil)) --8<---cut here---end--->8--- This looks somewhat intentional. Unfortunately this kills further execution of the calling script. NOTE: This only appears to happen once the agenda buffer exists (and is buried). The debug trace follows: --8<---cut here---start->8--- Debugger entered--Lisp error: (no-catch exit nil) throw(exit nil) (progn (org-prepare-agenda-window (get-buffer org-agenda-buffer-name)) (message "Sticky Agenda buffer, use `r' to refresh") (throw (quote exit) nil)) (if (org-agenda-use-sticky-p) (progn (org-prepare-agenda-window (get-buffer org-agenda-buffer-name)) (message "Sticky Agenda buffer, use `r' to refresh") (throw (quote exit) nil)) (setq org-todo-keywords-for-agenda nil) ... --8<---cut here---end--->8--- Calling (org-todo-list ) interactively appears to exhibit the same behavior. Best, Martyn --- Org-mode version 7.8.06 (release_7.8.03.594.g013d) GNU Emacs 24.0.94.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-02-28 on bob.porkrind.org
Re: [O] buffer-wide tangle filename
"Julian Burgos" writes: > Hello everyone, > This may be a very simple question. I want to tangle multiple source code > blocks into a single file. Instead of using the same output filename as a > block header (e.g. :tangle output.el) in each code block, can I I define a > buffer-wide tangle filename? Something like this (which does not work)? > > #+PROPERTY :tangle output.el > > > Any ideas? > > Julian --8<---cut here---start->8--- #+PROPERTY: tangle output.el --8<---cut here---end--->8--- Best, Martyn
Re: [O] Sticky Agenda buffer: Announcement and request for testing
Rainer Stengele writes: [...] +1 Works very well for me. My Org Agenda usage has modified somewhat thanks to the use of 'org-agenda-sticky and I really like my current usage. Thanks! Martyn --- Org-mode version 7.8.06 (release_7.8.03.594.g013d) GNU Emacs 24.0.94.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2012-02-28 on bob.porkrind.org
Re: [O] GSoC 2012 -- Elisp backend for Ragel
Hi, and welcome Aurélien, Nicolas Goaziou writes: > Hello, > > Aurélien Aptel writes: > >> On Sun, Mar 25, 2012 at 6:17 AM, Rustom Mody wrote: >>> FYI, there is already an elisp Org parser being worked on in development >>> branch of Org mode. It isn't finished yet, but still advanced enough so >>> a generic exporter could be built upon it. >> >>> Is there any interest in ignoring it and restart all the work from >>> scratch? >>> >>> Yes I agree, no point redoing work unnecessarily. Maybe the optimal >>> solution would be for Aurélien to work with Nicolas and Adrian to minimize >>> useless rework? >> >> Regardless of the org-mode parser, I think I should work on the elisp >> backend for ragel which is something that can benefit any elisp >> project. > > Certainly. > >> As for the new org-mode parser, I could not find it on the repo. Could >> you point me to the relevant files? > > See org-element.el in contrib/ directory. You need development version. > >> Is it still hand written? > > Yes. > >> If so, I think it's ultimately a bad idea and it should be rewritten >> using ragel. > > It may be. But it allows for flexibility. Org's syntax is evolving, and > I consider org-element.el as a parser, but also as a guidance in that > process. Since there is no formal description for Org syntax yet, an > org-element.el is more useful than a full-blown parser generator for > now. > > I don't know ragel (save for a short excursion in its website), but I'm > pretty sure that even if it generates elisp code without dependency, any > evolution to Org syntax will require to use it again. At that time, it > may be difficult to find someone able and willing to undertake that > updating task in a reasonable delay (since we're talking about a core > feature). On the other hand, there are quite a few elisp hackers in > Emacs's world. > > Now, if ragel can improve org-element.el while preserving its > flexibility (and a compatible output, since I assume you won't also > rewrite the generic export engine), I'm all ears. I am a big fan of formalizing as much state design as possible into formal state-machines, and have been for some time. For the design process I currently use the excellent plantuml library from within Org-mode (Aurélien, see lisp/ob-plantuml.el for the Org-babel interface), although have previously used a bespoke Ruby/Graphviz library of my design, and previous to that Ragel. For that reason I think it would be great to see an `Org-Babel' implementation of Ragel. I think it could be a very useful tool. However, I don't use code auto-generation by Ragel and the like for the following reasons... 1) It complicates the build process 2) It adds yet more SOUP (software of unknown provenance) to the build process which may then need mitigating against (this is relevant to me, although possibly not to Org-mode). 3) FSM implementation into code is inherently very simple anyway What I do instead is validate the FSM code against the formal state representation as an integration test (which is fairly easy to arrange). So my point is, I personally don't see the use of FSM code generators as a panacea to perfect super-fast code. To me their usefulness is in the visual representation of the state interaction (during development, and subsequent code documentation), and the resulting code quality. Just my 10c Best, Martyn > > > Regards,
Re: [O] [patch][babel] ob-lilypond maintenance
Hi Bastien
Bastien writes:
> Hi Martyn,
>
> Martyn Jago writes:
>
>> Maintenance patches:
>>
>> 1) Fix compiler warning
>> 2) Leave versioning to Org
>> 3) Set `no cache' default in audition mode
>> 4) Redirect `homepage' to Worg
>
> Thanks a lot.
>
> Patch #1 applies correctly on hotfix-7.8.06 and master.
>
> #2-3-4 apply on master but not on hotfix-7.8.06.
>
> Can you submit the patches for hotfix-7.8.06? This is
> not critical and we can go for master if you want. Let
> me know.
>
> Best,
Here's #1,2,4. #3 Makes no sense in context of code difference between
hotfix-7.8.06 against master.
Best, Martyn
>From 2d12de6b60196871303438ca51f9d50e3ae19342 Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Wed, 21 Mar 2012 10:49:57 +
Subject: [PATCH 1/3] Fix compiler warning.
* lisp/ob-lilypond.el: Fix compiler warning.
---
lisp/ob-lilypond.el |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 1f412fd..19fe465 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -30,10 +30,9 @@
(require 'ob)
(require 'ob-eval)
(require 'ob-tangle)
+(require 'outline)
(defalias 'lilypond-mode 'LilyPond-mode)
-(declare-function show-all "outline" ())
-
(add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))
(defvar org-babel-default-header-args:lilypond '()
--
1.7.3.4
>From 78e9de9942947ea47c5983367dfee8c6b67b0f77 Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Wed, 21 Mar 2012 10:52:49 +
Subject: [PATCH 2/3] Leave versioning to Org.
* lisp/ob-lilypond.el:
Leave versioning to Org.
* testing/lisp/test-ob-lilypond.el:
Leave versioning to Org.
---
lisp/ob-lilypond.el | 11 +--
testing/lisp/test-ob-lilypond.el | 10 --
2 files changed, 1 insertions(+), 20 deletions(-)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 19fe465..90a1b60 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -38,9 +38,6 @@
(defvar org-babel-default-header-args:lilypond '()
"Default header arguments for js code blocks.")
-(defconst ly-version "0.3"
- "The version number of the file ob-lilypond.el.")
-
(defvar ly-compile-post-tangle t
"Following the org-babel-tangle (C-c C-v t) command,
ly-compile-post-tangle determines whether ob-lilypond should
@@ -407,13 +404,7 @@ If TEST is non-nil, it contains a simulation of the OS for test purposes"
(message (concat "Arrange mode has been "
(if ly-arrange-mode "ENABLED." "DISABLED."
-(defun ly-version (&optional insert-at-point)
- (interactive)
- (let ((version (format "ob-lilypond version %s" ly-version)))
-(when insert-at-point (insert version))
-(message version)))
-
- (defun ly-switch-extension (file-name ext)
+(defun ly-switch-extension (file-name ext)
"Utility command to swap current FILE-NAME extension with EXT"
(concat (file-name-sans-extension
diff --git a/testing/lisp/test-ob-lilypond.el b/testing/lisp/test-ob-lilypond.el
index 2ca0597..2c35eca 100644
--- a/testing/lisp/test-ob-lilypond.el
+++ b/testing/lisp/test-ob-lilypond.el
@@ -43,16 +43,6 @@
(should-error (org-babel-prep-session:lilypond nil nil))
:type 'error)
-(ert-deftest ob-lilypond/ly-version-const ()
- (should (boundp 'ly-version)))
-
-(ert-deftest ob-lilypond/ly-version-command ()
- (should (equal "ob-lilypond version 0.3" (ly-version)))
- (with-temp-buffer
-(ly-version t)
-(should (equal "ob-lilypond version 0.3"
- (buffer-substring (point-min) (point-max))
-
(ert-deftest ob-lilypond/ly-compile-lilyfile ()
(should (equal
`(,(ly-determine-ly-path);program
--
1.7.3.4
>From 71755479fd315167b67875bd647376b48c126085 Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Wed, 21 Mar 2012 10:56:52 +
Subject: [PATCH 3/3] Re-direct homepage to Worg.
* lisp/ob-lilypond.el:
Re-direct homepage to Worg.
---
lisp/ob-lilypond.el |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 90a1b60..6b03bd8 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -4,7 +4,7 @@
;; Author: Martyn Jago
;; Keywords: babel language, literate programming
-;; Homepage: https://github.com/mjago/ob-lilypond
+;; Homepage: http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
;; This file is part of GNU Emacs.
--
1.7.3.4
[O] [patch][babel] ob-lilypond maintenance
Maintenance patches:
1) Fix compiler warning
2) Leave versioning to Org
3) Set `no cache' default in audition mode
4) Redirect `homepage' to Worg
Best, Martyn
>From 5fc49bc167c8fcc194c1c5761ea25c0a625500cb Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Wed, 21 Mar 2012 09:31:53 +
Subject: [PATCH 1/4] Fix compiler warning.
* lisp/ob-lilypond.el: Fix compiler warning.
---
lisp/ob-lilypond.el |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 0e9b0c6..0404c7e 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -34,10 +34,9 @@
(require 'ob)
(require 'ob-eval)
(require 'ob-tangle)
+(require 'outline)
(defalias 'lilypond-mode 'LilyPond-mode)
-(declare-function show-all "outline" ())
-
(add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))
(defvar org-babel-default-header-args:lilypond '()
--
1.7.3.4
>From 16bd78584237ed5699b4fe8615a8f62329b7e811 Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Wed, 21 Mar 2012 09:33:34 +
Subject: [PATCH 2/4] Leave versioning to Org.
* lisp/ob-lilypond.el: Leave versioning to Org
* testing/lisp/test-ob-lilypond.el: Leave versioning to Org
---
lisp/ob-lilypond.el | 11 +--
testing/lisp/test-ob-lilypond.el | 10 --
2 files changed, 1 insertions(+), 20 deletions(-)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 0404c7e..84b4c1d 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -44,9 +44,6 @@
NOTE: The arguments are determined at lilypond compile time.
See (ly-set-header-args)")
-(defconst ly-version "7.6"
- "The version number of the file ob-lilypond.el.")
-
(defvar ly-compile-post-tangle t
"Following the org-babel-tangle (C-c C-v t) command,
ly-compile-post-tangle determines whether ob-lilypond should
@@ -436,13 +433,7 @@ If TEST is non-nil, it contains a simulation of the OS for test purposes"
(message (concat "Arrange mode has been "
(if ly-arrange-mode "ENABLED." "DISABLED."
-(defun ly-version (&optional insert-at-point)
- (interactive)
- (let ((version (format "ob-lilypond version %s" ly-version)))
-(when insert-at-point (insert version))
-(message version)))
-
- (defun ly-switch-extension (file-name ext)
+(defun ly-switch-extension (file-name ext)
"Utility command to swap current FILE-NAME extension with EXT"
(concat (file-name-sans-extension
diff --git a/testing/lisp/test-ob-lilypond.el b/testing/lisp/test-ob-lilypond.el
index 306c48a..1a60eab 100644
--- a/testing/lisp/test-ob-lilypond.el
+++ b/testing/lisp/test-ob-lilypond.el
@@ -38,16 +38,6 @@
(should-error (org-babel-prep-session:lilypond nil nil))
:type 'error)
-(ert-deftest ob-lilypond/ly-version-const ()
- (should (boundp 'ly-version)))
-
-(ert-deftest ob-lilypond/ly-version-command ()
- (should (equal "ob-lilypond version 7.6" (ly-version)))
- (with-temp-buffer
-(ly-version t)
-(should (equal "ob-lilypond version 7.6"
- (buffer-substring (point-min) (point-max))
-
(ert-deftest ob-lilypond/ly-compile-lilyfile ()
(should (equal
`(,(ly-determine-ly-path);program
--
1.7.3.4
>From 4bb6929dc2d4514a58900c3fe1b77dbed7f95ebf Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Wed, 21 Mar 2012 09:35:44 +
Subject: [PATCH 3/4] Set no cache default in audition mode.
* lisp/ob-lilypond.el:
Set no cache default in audition mode.
* testing/lisp/test-ob-lilypond.el:
Set no cache default in audition mode.
---
lisp/ob-lilypond.el |1 -
testing/lisp/test-ob-lilypond.el |2 --
2 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 84b4c1d..d77c5b6 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -447,7 +447,6 @@ mode i.e. ARRANGE-MODE is t"
'((:tangle . "yes")
(:noweb . "yes")
(:results . "silent")
- (:cache . "yes")
(:comments . "yes")))
(t
'((:results . "file")
diff --git a/testing/lisp/test-ob-lilypond.el b/testing/lisp/test-ob-lilypond.el
index 1a60eab..16cb055 100644
--- a/testing/lisp/test-ob-lilypond.el
+++ b/testing/lisp/test-ob-lilypond.el
@@ -354,7 +354,6 @@
(should (equal '((:tangle . "yes")
(:noweb . "yes")
(:results . "silent")
- (:cache . "yes")
(:comments . "yes"))
(ly-set-header-args t)))
(should (equal '((:results . "file")
@@ -366,7 +365,6 @@
(should (equal '((:tangle . "yes")
Re: [O] Should maint branch be deprecated?
Bastien writes: Hi Bastien, Achim > Hi Martyn, > > Martyn Jago writes: > >> As an infrequent committer to org-mode, I wonder if the maint branch is >> more pain than gain. > > It is a pain when too many things should happen on it. > > IMO It is a gain when we dedicate it to releases only. > > No pain should come out of introducing hotfix-* branches, > as they are transient branches. > > Now I'm off to a well-deserved bed :) I certainly appreciate the need to stabilize releases. But I did get to wondering lately if the original purpose of maint was kind of lost in the overall high-throughput repo activity. I'm a big fan of Git, and have started using it for non-version control activities, so I appreciate things can always be fine-tuned to suit the current situation. Thanks for the considered replies. Best, Martyn
[O] Should maint branch be deprecated?
As an infrequent committer to org-mode, I wonder if the maint branch is more pain than gain. I've read through the mails arguing for its conception, and the benefits just don't appear to be resultant. Add to that - infrequent committer's who commit via the list generally know nothing about the maintenance branch (including me), which just leads to more confusion. I follow the commits to master, and the work to core developers due to the maint branch is clearly not insignificant? If the gain is greater than the pain then somebody needs to clue me up. Best, Martyn
Re: [O] Org release 7.8.04 (BUGFIX-only release)
Hi Since all the `errors' are whitespace it may be better to work around the release? Best Martyn Achim Gratz writes: > Achim Gratz writes: >> Well, all this "manual reverting" messed up master quite royally. I >> haven't checked maint, but things might be a bit easier there. I'm >> currently trying to re-trace what master and maint should have been and >> make a patch on top of the mangled versions... > > Here are two patches to clean up master and maint to where they should > be (IMHO, please check). Needless to say, you _will_ have to do another > release with these fixes. > > diff --git a/contrib/babel/langs/ob-oz.el b/contrib/babel/langs/ob-oz.el > index > 2482ed61685cde75f38f803f564ed128e1063e68..b778b4a228c6e75d982db81f280515806cbed4d6 > 100644 > --- a/contrib/babel/langs/ob-oz.el > +++ b/contrib/babel/langs/ob-oz.el > @@ -1,6 +1,6 @@ > ;;; ob-oz.el --- org-babel functions for Oz evaluation > > -;; Copyright (C) 2009-2012 Torsten Anders and Eric Schulte > +;; Copyright (C) 2009-2012 Torsten Anders and Eric Schulte > > ;; Author: Torsten Anders and Eric Schulte > ;; Keywords: literate programming, reproducible research > diff --git a/contrib/scripts/StartOzServer.oz > b/contrib/scripts/StartOzServer.oz > index > 9d41e838dc121b8a82e1516cb0e0d7fb7d0e6b72..db12dec58d783992529aa51273eeaf2e8e5fba38 > 100644 > --- a/contrib/scripts/StartOzServer.oz > +++ b/contrib/scripts/StartOzServer.oz > @@ -1,5 +1,5 @@ > %%% * > -%%% Copyright (C) 2009-2012 Torsten Anders (www.torsten-anders.de) > +%%% Copyright (C) 2009-2012 Torsten Anders (www.torsten-anders.de) > %%% This program is free software; you can redistribute it and/or > %%% modify it under the terms of the GNU General Public License > %%% as published by the Free Software Foundation; either version 2 > diff --git a/lisp/ob-exp.el b/lisp/ob-exp.el > index > 2299dd47f4117ad16f3368f2c56df4b72dcd3424..06d193a1a17ce1054086c1a6e1386de3a3989593 > 100644 > --- a/lisp/ob-exp.el > +++ b/lisp/ob-exp.el > @@ -120,7 +120,7 @@ (defun org-babel-exp-src-block (body &rest headers) > (org-babel-noweb-wrap) "" (nth 1 info)) > (if (org-babel-noweb-p (nth 2 info) :export) > (org-babel-expand-noweb-references > - info (org-babel-exp-get-export-buffer)) > + info (org-babel-exp-get-export-buffer)) > (nth 1 info > (org-babel-exp-do-export info 'block hash) > > diff --git a/lisp/org-inlinetask.el b/lisp/org-inlinetask.el > index > dbb9b22ef3cb825cd603c766d2a7ce47e63cea1c..d969a29213a0b92635afc4350ec7a722f1c7350d > 100644 > --- a/lisp/org-inlinetask.el > +++ b/lisp/org-inlinetask.el > @@ -90,7 +90,7 @@ (defgroup org-inlinetask nil > > (defcustom org-inlinetask-min-level 15 >"Minimum level a headline must have before it is treated as an inline task. > -Don't set it to something higher than `29' or clocking will break since this > +Don't set it to something higher than `29' or clocking will break since this > is the hardcoded maximum number of stars `org-clock-sum' will work with. > > It is strongly recommended that you set `org-cycle-max-level' not at all, > diff --git a/lisp/org-vm.el b/lisp/org-vm.el > index > 16987495b142fb10c81f4d61e21c6b43eda2b97b..b509c4108d16819bcb383ac89810484d9473f789 > 100644 > --- a/lisp/org-vm.el > +++ b/lisp/org-vm.el > @@ -71,7 +71,7 @@ (defun org-vm-store-link () > (save-excursion >(vm-select-folder-buffer) >(let* ((message (car vm-message-pointer)) > -(subject (vm-su-subject message)) > + (subject (vm-su-subject message)) >(to (vm-get-header-contents message "To")) >(from (vm-get-header-contents message "From")) > (message-id (vm-su-message-id message)) > diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el > index > f86d84ae336f940f5096007fad8a65e43a75ab68..342ebed0bf5e24a16d5d32f6732f48d3483c5530 > 100644 > --- a/testing/lisp/test-ob-exp.el > +++ b/testing/lisp/test-ob-exp.el > @@ -267,3 +267,4 @@ > (provide 'test-ob-exp) > > ;;; test-ob-exp.el ends here > + > diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el > index > 5f9e29cb4e2bf03044cefe6a0e7318a6faf8f497..b01e4b2ba2b8c350f1b81991b76a7a45050122cb > 100644 > --- a/testing/lisp/test-ob.el > +++ b/testing/lisp/test-ob.el > @@ -875,7 +875,7 @@ (defun test-ob-verify-result-and-removed-result (result > buffer-text) >(re-search-forward "\\#\\+results:" nil t) >(forward-line) >(should (string= > -"" > +"" > (buffer-substring-no-properties (point-at-bol) > (point-at-eol)) >(org-test-with-temp-text-in-file " > #+begin_src emacs-lisp :var a=2 > @@ -887,7 +887,7 @@ (defun test-ob-verify-result-and-removed-result (result > buffer-text) >(re-search-forward "\\#\\+results:" nil t) >
Re: [O] ob-lilypond open pdf and midi asynchroniously
Hi Ezequiel > Ezequiel Birman writes: > Is there a reason to not append "&" to shell-command's args? I get > disconnected from ERC/Bitlbee each time I peek at the score too long. Apologies for my delayed response - I've been rather busy. I've pushed a patch to the list to make auditioning of pdf and midi asynchronous processes. You can either wait to see if the patch makes it to git, or apply the patch yourself (git am). Hopefully this will alleviate your problems with ERC! Thanks for the heads-up. I'm hoping to introduce remote compiling of Lilypond to help alleviate the wait time felt when compiling Lilypond (slow but pretty)! I'm using a similar technique for parallel testing of embedded C, document generation, and building (using ZeroMQ). Best, Martyn
[O] [babel][patch] Make ob-lilypond audition calls asynchronous
Hi
A patch to make ob-lilypond audition calls asynchronous (and tests).
Best, Martyn
>From 2e7cd607cd6dbc25edd5ff9972fbd2528d48416e Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Sat, 10 Mar 2012 15:00:57 +
Subject: [PATCH] Make auditioning of midi and pdf generations asynchronous, and add easy pdf generation.
* lisp/ob-lilypond.el: Make auditioning of midi and pdf asynchronous,
and add easy pdf generation in the form of `ly-gen-pdf' variable.
* testing/lisp/test-ob-lilypond.el: Tests for above.
---
lisp/ob-lilypond.el | 68 ++---
testing/lisp/test-ob-lilypond.el | 22 +++-
2 files changed, 68 insertions(+), 22 deletions(-)
diff --git a/lisp/ob-lilypond.el b/lisp/ob-lilypond.el
index 0dde0de..fc9a639 100644
--- a/lisp/ob-lilypond.el
+++ b/lisp/ob-lilypond.el
@@ -3,7 +3,7 @@
;; Copyright (C) 2010-2012 Free Software Foundation, Inc.
;; Author: Martyn Jago
-;; Keywords: babel language, literate programming
+;; Keywords: babel language, literate programming, music score
;; Homepage: https://github.com/mjago/ob-lilypond
;; This file is part of GNU Emacs.
@@ -23,10 +23,14 @@
;;; Commentary:
-;; Installation / usage info, and examples are available at
-;; https://github.com/mjago/ob-lilypond
+;; Installation, ob-lilypond documentation, and examples are available at
+;; http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-lilypond.html
+;;
+;; Lilypond documentation can be found at
+;; http://lilypond.org/manuals.html
;;; Code:
+
(require 'ob)
(require 'ob-eval)
(require 'ob-tangle)
@@ -37,9 +41,11 @@
(add-to-list 'org-babel-tangle-lang-exts '("LilyPond" . "ly"))
(defvar org-babel-default-header-args:lilypond '()
- "Default header arguments for js code blocks.")
+ "Default header arguments for lilypond code blocks.
+NOTE: The arguments are determined at lilypond compile time.
+See (ly-set-header-args)")
-(defconst ly-version "0.3"
+(defconst ly-version "7.6"
"The version number of the file ob-lilypond.el.")
(defvar ly-compile-post-tangle t
@@ -86,6 +92,10 @@ LY-GEN-SVG to t")
"HTML generation can be turned on by default by setting
LY-GEN-HTML to t")
+(defvar ly-gen-pdf nil
+"PDF generation can be turned on by default by setting
+LY-GEN-PDF to t")
+
(defvar ly-use-eps nil
"You can force the compiler to use the EPS backend by setting
LY-USE-EPS to t")
@@ -203,18 +213,20 @@ FILE-NAME is full path to lilypond (.ly) file"
(arg-2 nil);infile
(arg-3 "*lilypond*") ;buffer
(arg-4 t) ;display
-(arg-5 (if ly-gen-png "--png" "")) ;&rest...
- (arg-6 (if ly-gen-html "--html" ""))
-(arg-7 (if ly-use-eps "-dbackend=eps" ""))
-(arg-8 (if ly-gen-svg "-dbackend=svg" ""))
-(arg-9 (concat "--output=" (file-name-sans-extension file-name)))
-(arg-10 file-name))
+ (arg-4 t) ;display
+ (arg-5 (if ly-gen-png "--png" "")) ;&rest...
+ (arg-6 (if ly-gen-html "--html" ""))
+(arg-7 (if ly-gen-pdf "--pdf" ""))
+(arg-8 (if ly-use-eps "-dbackend=eps" ""))
+(arg-9 (if ly-gen-svg "-dbackend=svg" ""))
+(arg-10 (concat "--output=" (file-name-sans-extension file-name)))
+(arg-11 file-name))
(if test
-`(,arg-1 ,arg-2 ,arg-3 ,arg-4 ,arg-5
- ,arg-6 ,arg-7 ,arg-8 ,arg-9 ,arg-10)
+`(,arg-1 ,arg-2 ,arg-3 ,arg-4 ,arg-5 ,arg-6
+ ,arg-7 ,arg-8 ,arg-9 ,arg-10, arg-11)
(call-process
- arg-1 arg-2 arg-3 arg-4 arg-5
- arg-6 arg-7 arg-8 arg-9 arg-10
+ arg-1 arg-2 arg-3 arg-4 arg-5 arg-6
+ arg-7 arg-8 arg-9 arg-10 arg-11
(defun ly-check-for-compile-error (file-name &optional test)
"Check for compile error.
@@ -307,8 +319,12 @@ If TEST is non-nil, the shell command is returned and is not run"
(concat (ly-determine-pdf-path) " " pdf-file)))
(if test
cmd-string
- (shell-command cmd-string)))
-(message "No pdf file generated so can't display!")
+ (start-process
+ "\"Audition pdf\""
+ "*lilypond*"
+ (ly-determine-pdf-path)
+ pdf-file)))
+ (message "No pdf file generated so can't display!")
(defun ly-attempt-to-play-midi (file-name &optional test)
"Attempt to play the generated MIDI file
@@ -322,7 +338,11 @@ If TEST is non-nil, the shell command is returned and is not run"
(concat (
Re: [O] [babel][patch] sqlite3 in org-babel
Added [babe][patch] to title to avoid patch being overlooked.
Best, Martyn
Daniel Clemente writes:
> Hi,
>org-babel works well with sqlite3 if you add this (which I propose for
> inclusion):
>
> -
> diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
> index 3f7882c..a59db7a 100644
> --- a/lisp/ob-sql.el
> +++ b/lisp/ob-sql.el
> @@ -82,6 +82,10 @@ This function is called by `org-babel-execute-src-block'."
> (org-babel-process-file-name in-file)
> (org-babel-process-file-name out-file)
> (or cmdline "")))
> +('sqlite3 (format "sqlite3 %s < %s > %s"
> +(or cmdline "")
> + (org-babel-process-file-name in-file)
> + (org-babel-process-file-name out-file)))
> (t (error "no support for the %s sql engine" engine)
> (with-temp-file in-file
>(insert (org-babel-expand-body:sql body params)))
>
> -
>
>
>
>Then you can use it in this way:
> #+BEGIN_SRC sql :cmdline "-header -list ~/pruebas.sqlite3" :engine sqlite3
> select * from web_categorias;
> #+END_SRC
>
>It's very useful! Org's results table is more interactive than the one you
> can see in sql-mode (M-x sql-sqlite).
>
>
>
>By the way, the code in ob-sql.el attempts to remove final newlines. I use
> (setq require-final-newline 'ask) and I am being asked about the temporary
> buffer, which is wrong. So I also propose this patch:
>
>
> diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
> index 3f7882c..8df0d98 100644
> --- a/lisp/ob-sql.el
> +++ b/lisp/ob-sql.el
> @@ -107,7 +107,8 @@ This function is called by `org-babel-execute-src-block'."
> (delete-char 1)
> (goto-char (point-max))
> (forward-char -1))
> - (write-file out-file))
> + (let ((require-final-newline nil))
> + (write-file out-file)))
> (org-table-import out-file '(16))
> (org-babel-reassemble-table
>(mapcar (lambda (x)
>
>
>
>
>
> Greetings,
>
> Daniel
Re: [O] Updating the Babel section of Worg
Hi Thomas and Eric
Love it. I will try to help!
Worg is a great resource that is getting better and better.
The template looks good (Babel wise) and should be up there as a
check-sheet, although maybe not as a requirement.
Eric - perhaps mark good pages as good rather than bad pages. They're
not necessarily bad?
It would be cool to say [Tested 2 days ago] at the top of the page
(in a nice green) or something like that. (or validation link in green /
yellow / red)
I also think that [Under development] should be removed from
index.html. Worg is always under development, that's what it is?
For anybody that is not that familiar with Worg, you can contribute to
it right now - it's pure community.
Best, Martyn
t...@tsdye.com (Thomas S. Dye) writes:
> Hi Eric,
>
> I've attached a first draft of a template for review and revision. It
> is heavily influenced by John Hendy's terrific gnuplot page. I
> believe it incorporates the points in your outline. Feel free to
> edit as appropriate.
>
> All the best,
> Tom
>
>
> #+OPTIONS:H:3 num:nil toc:2 \n:nil @:t ::t |:t ^:{} -:t f:t *:t TeX:t
> LaTeX:t skip:nil d:(HIDE) tags:not-in-toc
> #+STARTUP:align fold nodlcheck hidestars oddeven lognotestate hideblocks
> #+SEQ_TODO: TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
> #+TAGS: Write(w) Update(u) Fix(f) Check(c) noexport(n)
> #+TITLE: Language Source Code Blocks in Org Mode
> #+AUTHOR: Your name
> #+EMAIL: you[at]email[dot]org
> #+LANGUAGE: en
> #+STYLE: #outline-container-introduction{
> clear:both; }
> #+LINK_UP:../languages.php
> #+LINK_HOME: http://orgmode.org/worg/
> #+EXPORT_EXCLUDE_TAGS: noexport
>
> #+name: banner
> #+begin_html
>
>
> Org Mode support for http://language-site/";>Language
>
>
> http://language-site/";>
> http://language-site/graphic.file"/>
>
>
>
> #+end_html
>
> * Template Checklist [0/13]:noexport:
> - [ ] Revise #+TITLE:
> - [ ] Indicate #+AUTHOR:
> - [ ] Add #+EMAIL:
> - [ ] Revise banner source block [0/3]
> - [ ] Add link to a useful language web site
> - [ ] Replace "Language" with language name
> - [ ] Find a suitable graphic and use it to link to the language
> web site
> - [ ] Write an [[Introduction]]
> - [ ] Describe [[Requirements%20and%20Setup][Requirements and Setup]]
> - [ ] Replace "Language" with language name in
> [[Org%20Mode%20Features%20for%20Language%20Source%20Code%20Blocks][Org Mode
> Features for Language Source Code Blocks]]
> - [ ] Specify [[Org%20Mode%20Configuration][Org Mode Configuration]]
> - [ ] Describe [[Header%20Arguments][Header Arguments]]
> - [ ] Describe support for [[Sessions]]
> - [ ] Describe [[Result%20Types][Result Types]]
> - [ ] Describe [[Other]] differences from supported languages
> - [ ] Provide brief [[Examples%20of%20Use][Examples of Use]]
> * Introduction
> - Brief description of language.
> - Range of typical uses within Org Mode.
> - Link to this Org Mode file.
> * Requirements and Setup
> - Installation and configuration of language software
> - Emacs configuration
> * Org Mode Features for Language Source Code Blocks
> ** Org Mode Configuration
>- org-babel-do-load-languages
> ** Header Arguments
>- Language-specific default values
>- Language-specific header arguments
> ** Sessions
>- Support or not
>- Typical use for sessions
> ** Result Types
>- Which result types are supported?
> ** Other
>- Differences from other supported languages
> * Examples of Use
> - Hello World!
> - Common uses
> - Links to tutorials and other resources
>
>
> Eric Schulte writes:
>
>> Hi Tom,
>>
>> t...@tsdye.com (Thomas S. Dye) writes:
>>
>>> Hi Eric,
>>>
>>> Yes, this is overdue. I think your plan is a good one.
>>>
>>> Perhaps a few of the individual use cases could be moved to FIXME,
>>> instead? I'm thinking here of Feiming Chen's R setup and some of my
>>> contributions when I was experimenting writing LaTeX inside source
>>> code blocks. The authors could resurrect these as they see fit.
>>>
>>
>> I don't know what FIXME is, but if there is a way to keep the page in
>> the worg git repository but remove it from the exported HTML then that
>> sounds ideal.
>>
>>>
>>> Hopefully, others will contribute use examples. My sense from reading
>>> the list is there are many interesting ones.
>>>
>>> I'd like it if Org mode users designed a template for the language
>>> specific pages. Currently, these seem to me a mixed bag and it would be
>>> good to regularize them.
>>
>> The below is a modified version of a template which can be found in a
>> couple of the existing language tutorials, I think it serves as a good
>> starting point.
>>
>> - Install and Setup
>> - Instillation and configuration of software (e.g., the language itself)
>> - Configuration of Emacs (e.g., activate language, set command path)
>> - Examples
>> - Common
Re: [O] [babel][patch] BUG in inline source blocks
Hi Eric Andreas Leha writes: [...] >> Thanks for this patch Martyn, I just pushed up your [:punct:] change. >> >>> >>> Hi Martyn, >>> >>> thanks for this patch! It does half the job for me. Now export (or >>> evaluation) already work. But in the export I get a space inserted. >>> >>> I my example, I'd expect "(here)" to appear in the export, but I get >>> "( here)". >>> >> >> This should now be fixed. >> > > Thanks, Martyn and Eric! Indeed "both" issues are fixed now. > > Regards, > Andreas Thanks. But out of interest why were the tests discarded? They are after all the proof that the code works, and the `living specification' of expected behavior. Just wondering Best, Martyn
Re: [O] Export without code blocks
Martyn Jago writes: > Hi Aaron > > aaron barclay writes: > >> Hi, >> >> I am having trouble finding the correct way to export a document without >> the code blocks included. Should I be using #+EXPORT_EXCLUDE_TAGS? I can't >> seem to get it to work, anyone have the correct syntax? >> >> cheers, >> aaron. > > #+EXPORT_EXCLUDE_TAGS is for defining tags (such as NO_EXPORT) to > prevent headings or sub-headings (branches) being exported. As in: > > ** don't export me :NO_EXPORT: > stuff > > Possibly what you need is :exports none or :exports results : > > begin_src python :exports results > print "result" > end_src Of course this won't work in python since it will 'print' result, but not return it. so you also need :results output which makes, the `result' that which is printed to STDOUT (standard out). > What format are you exporting too? > > Best, Martyn
Re: [O] Export without code blocks
Hi Aaron aaron barclay writes: > Hi, > > I am having trouble finding the correct way to export a document without > the code blocks included. Should I be using #+EXPORT_EXCLUDE_TAGS? I can't > seem to get it to work, anyone have the correct syntax? > > cheers, > aaron. #+EXPORT_EXCLUDE_TAGS is for defining tags (such as NO_EXPORT) to prevent headings or sub-headings (branches) being exported. As in: ** don't export me :NO_EXPORT: stuff Possibly what you need is :exports none or :exports results : begin_src python :exports results print "result" end_src What format are you exporting too? Best, Martyn
Re: [O] [babel][patch] BUG in inline source blocks
Martyn Jago writes:
> Hi,
>
> Andreas Leha writes:
>
>> Hi all,
>>
>> I experience unexpected behaviour when an inline source block is not
>> preceded by whitespace.
>>
>> Example:
>> ===
>> * Test inline
>> This is a functional inline src_R{print("source block")}.
>>
>> This (src_R{print("here")}) is not.
>> ===
>>
>> Regards,
>> Andreas
>
> I can confirm this behaviour and provide a patch to allow for inline
> source blocks to be preceded by punctuation, or, for instance, enclosed
> in parenthesis, as in Andreas' example. Patch is attached for
> consideration.
>
> Best, Martyn
This is an updated version of the previous patch, with debug noise
removed, and a couple of extra tests.
Best, Martyn
>From b46e7a496c30f683c50759013ad39a9d8c6ff42b Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Thu, 26 Jan 2012 19:48:35 +
Subject: [PATCH] Fix for where inline source block is not preceded by whitespace but by
punctuation (reported by Andreas Leha).
* lisp/ob.el: Fix for where inline source block is not preceded by
whitespace but by punctuation.
* testing/lisp/test-ob.el: Regression tests.
---
lisp/ob.el | 30 ++--
testing/lisp/test-ob.el | 69 +++
2 files changed, 84 insertions(+), 15 deletions(-)
diff --git a/lisp/ob.el b/lisp/ob.el
index 70c258f..fd6a897 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -170,24 +170,24 @@ not match KEY should be returned."
(defun org-babel-get-inline-src-block-matches()
"Set match data if within body of an inline source block.
Returns non-nil if match-data set"
- (let ((src-at-0-p (save-excursion
+ (let* ((src-at-0-p (save-excursion
(beginning-of-line 1)
(string= "src" (thing-at-point 'word
(first-line-p (= 1 (line-number-at-pos)))
- (orig (point)))
-(let ((search-for (cond ((and src-at-0-p first-line-p "src_"))
- (first-line-p "[ \t]src_")
- (t "[ \f\t\n\r\v]src_")))
- (lower-limit (if first-line-p
- nil
- (- (point-at-bol) 1
- (save-excursion
- (when (or (and src-at-0-p (bobp))
- (and (re-search-forward "}" (point-at-eol) t)
- (re-search-backward search-for lower-limit t)
- (> orig (point
- (when (looking-at org-babel-inline-src-block-regexp)
- t ))
+ (orig (point))
+ (search-for (cond ((and src-at-0-p first-line-p "src_"))
+ (first-line-p "[ \t[:punct:]]src_")
+ (t "[ \f\t\n\r\v[:punct:]]src_")))
+ (lower-limit (if first-line-p
+ nil
+ (- (point-at-bol) 1
+(save-excursion
+ (when (or (and src-at-0-p (bobp))
+ (and (re-search-forward "}" (point-at-eol) t)
+ (re-search-backward search-for lower-limit t)
+ (> orig (point
+ (when (looking-at org-babel-inline-src-block-regexp)
+ t )
(defvar org-babel-inline-lob-one-liner-regexp)
(defun org-babel-get-lob-one-liner-matches()
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 7dccd22..f4363f6 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -430,6 +430,75 @@ this is simple"
(buffer-substring-no-properties
(point-min) (point-max)))
+(ert-deftest test-org-babel/inline-src_blk-preceded-punct ()
+ "Test inline source block where preceded by punctuation"
+
+ ;; inline-src-blk preceded by point
+ (let ((test-line ".src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ test-line
+ (forward-char 1)
+ (org-ctrl-c-ctrl-c)
+ (should (string= (concat test-line " =\"x\"=")
+ (buffer-substring-no-properties
+ (point-min) (point-max))
+
+ ;; inline-src-blk preceded by equality
+ (let ((test-line "=src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ test-line
+ (forward-char 1)
+ (org-ctrl-c-ctrl-c)
+ (should (string= (concat test-line " =\"x\"=")
+ (buffer-substring-no-properties
+ (point-min) (point-max))
+
+ ;; inline-src-blk enclosed within parenthesis
+ (let ((test-line "(src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ (concat test-line ")")
+ (forward-char 1)
+ (org-ctrl-c-ctrl-c)
+ (should (string= (concat test-line " =\"x\"=)" )
+ (buffer-substring-no-properties
+ (point-min) (point-max))
+
+ ;; inline-src-blk enclosed within parenthesis
+ (let ((test-line "{src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ (concat test-line "}")
+ (forward-c
Re: [O] [babel][patch] BUG in inline source blocks
Hi,
Andreas Leha writes:
> Hi all,
>
> I experience unexpected behaviour when an inline source block is not
> preceded by whitespace.
>
> Example:
> ===
> * Test inline
> This is a functional inline src_R{print("source block")}.
>
> This (src_R{print("here")}) is not.
> ===
>
> Regards,
> Andreas
I can confirm this behaviour and provide a patch to allow for inline
source blocks to be preceded by punctuation, or, for instance, enclosed
in parenthesis, as in Andreas' example. Patch is attached for
consideration.
Best, Martyn
>From ce7ccfe97ce640f47ed83cdb2fdb6ffa8a6d3c54 Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Thu, 26 Jan 2012 13:22:25 +
Subject: [PATCH] Fix for where inline source block is not preceded by whitespace but by
punctuation (reported by Andreas Leha).
* lisp/ob.el: Fix for where inline source block is not preceded by
whitespace but by punctuation.
* testing/lisp/test-ob.el: Regression test, testing inline source
block preceded by point, equality, and enclosed in parenthesis and
brackets.
---
lisp/ob.el | 21 -
testing/lisp/test-ob.el | 44
2 files changed, 56 insertions(+), 9 deletions(-)
diff --git a/lisp/ob.el b/lisp/ob.el
index 70c258f..fbf032b 100644
--- a/lisp/ob.el
+++ b/lisp/ob.el
@@ -170,24 +170,27 @@ not match KEY should be returned."
(defun org-babel-get-inline-src-block-matches()
"Set match data if within body of an inline source block.
Returns non-nil if match-data set"
- (let ((src-at-0-p (save-excursion
+ (let* ((src-at-0-p (save-excursion
(beginning-of-line 1)
(string= "src" (thing-at-point 'word
(first-line-p (= 1 (line-number-at-pos)))
- (orig (point)))
-(let ((search-for (cond ((and src-at-0-p first-line-p "src_"))
- (first-line-p "[ \t]src_")
- (t "[ \f\t\n\r\v]src_")))
- (lower-limit (if first-line-p
- nil
- (- (point-at-bol) 1
+ (orig (point))
+ (search-for (cond ((and src-at-0-p first-line-p "src_"))
+ (first-line-p "[ \t[:punct:]]src_")
+ (t "[ \f\t\n\r\v[:punct:]]src_")))
+ (lower-limit (if first-line-p
+ nil
+ (- (point-at-bol) 1
+ (message "src-at-0-p = %S" src-at-0-p)
+ (message "first-line-p = %S" src-at-0-p)
+ (message "search-for = %S" search-for)
(save-excursion
(when (or (and src-at-0-p (bobp))
(and (re-search-forward "}" (point-at-eol) t)
(re-search-backward search-for lower-limit t)
(> orig (point
(when (looking-at org-babel-inline-src-block-regexp)
- t ))
+ t )
(defvar org-babel-inline-lob-one-liner-regexp)
(defun org-babel-get-lob-one-liner-matches()
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index 7dccd22..fb38ead 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -430,6 +430,50 @@ this is simple"
(buffer-substring-no-properties
(point-min) (point-max)))
+(ert-deftest test-org-babel/inline-src_blk-preceded-punct ()
+ "Test inline source block where preceded by punctuation"
+
+ ;; inline-src-blk preceded by point
+ (let ((test-line ".src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ test-line
+ (forward-char 1)
+ (org-ctrl-c-ctrl-c)
+ (should (string= (concat test-line " =\"x\"=")
+ (buffer-substring-no-properties
+ (point-min) (point-max))
+
+ ;; inline-src-blk preceded by equality
+ (let ((test-line "=src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ test-line
+ (forward-char 1)
+ (org-ctrl-c-ctrl-c)
+ (should (string= (concat test-line " =\"x\"=")
+ (buffer-substring-no-properties
+ (point-min) (point-max))
+
+ ;; inline-src-blk enclosed within parenthesis
+ (let ((test-line "(src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ (concat test-line ")")
+ (forward-char 1)
+ (org-ctrl-c-ctrl-c)
+ (should (string= (concat test-line " =\"x\"=)" )
+ (buffer-substring-no-properties
+ (point-min) (point-max))
+
+ ;; inline-src-blk enclosed within parenthesis
+ (let ((test-line "{src_emacs-lisp[ :results verbatim ]{ \"x\" }"))
+(org-test-with-temp-text
+ (concat test-line "}")
+ (forward-char 1)
+ (org-ctrl-c-ctrl-c)
+ (should (string= (concat test-line " =\"x\"=}")
+ (buffer-substring-no-properties
+ (point-min) (point-max))
+
+ )
(ert-deftest test-org-babel/combining-scalar-and-raw-result-types ()
(org-test-with-temp-text-in-file "
--
1.7.3.4
Re: [O] [babel][patch] provide consistent result removal (type `wrap')
[...] Oops - patch provided at start of this thread is malformed and should be ignored. The correct patch is provided below for consideration. Apologies for the noise. Best, Martyn Martyn Jago writes: > Patch to fix `org-babel-result-end' command to provide consistent result > removal where result is type `wrap'>From 7b6f37164848931321c0f25d567cf65df2e5a4af Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Tue, 24 Jan 2012 16:12:29 + Subject: [PATCH] Fix `org-babel-result-end' command to provide consistent result removal where result is type `wrap'. * lisp/ob.el: Fix `org-babel-result-end' command to provide consistent result removal where result is type `wrap'. Prior to this fix multiple (org-ctrl-c-ctrl-c) commands will add multiple newlines to the end of results (one newline per block execution). This fixes the test `test-ob/org-babel-remove-result--results-wrap' * testing/lisp/test-ob.el: Uncomment test since it now passes. --- lisp/ob.el |3 ++- testing/lisp/test-ob.el | 28 ++-- 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index e8a6d88..4541226 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -1920,7 +1920,8 @@ code the results are extracted in the syntax of the source (prvs (org-list-prevs-alist struct))) (org-list-get-list-end (point-at-bol) struct prvs))) ((looking-at "^\\([ \t]*\\):RESULTS:") - (re-search-forward (concat "^" (match-string 1) ":END:"))) + (progn (re-search-forward (concat "^" (match-string 1) ":END:")) + (forward-char 1) (point))) (t (let ((case-fold-search t)) (if (looking-at (concat "[ \t]*#\\+begin_\\([^ \t\n\r]+\\)")) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index 178556e..7dccd22 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -771,20 +771,20 @@ replacement happens correctly." * next heading")) -;; TODO FIXME Activate when Eric's trailing newline fix has been committed -;; (ert-deftest test-ob/org-babel-remove-result--results-wrap () -;; (test-ob-verify-result-and-removed-result -;;":RESULTS: -;; hello there -;; :END:" -;; -;; "* org-babel-remove-result -;; -;; +begin_src emacs-lisp :results wrap -;; \"hello there\" -;; #+end_src -;; -;; * next heading")) +(ert-deftest test-ob/org-babel-remove-result--results-wrap () + "Test `org-babel-remove-result' with :results wrap." + (test-ob-verify-result-and-removed-result + ":RESULTS: +hello there +:END:" + + "* org-babel-remove-result + +#+begin_src emacs-lisp :results wrap +\"hello there\" +#+end_src + +* next heading")) (ert-deftest test-ob/org-babel-remove-result--results-org () "Test `org-babel-remove-result' with :results org." -- 1.7.3.4 .
[O] [babel][patch] provide consistent result removal (type `wrap')
Patch to fix `org-babel-result-end' command to provide consistent result removal where result is type `wrap'. Prior to this fix multiple (org-ctrl-c-ctrl-c) commands will add multiple newlines to the end of results (one newline per block execution). This patch also fixes the test `test-ob/org-babel-remove-result--results-wrap' which is uncommented in the patch. Best, Martyn >From a4b2f8484ec4810e7a891b4db0caf5463e96a58d Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Tue, 24 Jan 2012 15:39:30 + Subject: [PATCH] Fix `org-babel-result-end' command to provide consistent result removal where result is type `wrap'. * lisp/ob.el: Fix `org-babel-result-end' command to provide consistent result removal where result is type `wrap'. Prior to this fix multiple (org-ctrl-c-ctrl-c) commands will add multiple newlines to the end of results (one newline per block execution). This fixes the test `test-ob/org-babel-remove-result--results-wrap' * testing/lisp/test-ob.el: Uncomment test since it now passes. --- lisp/ob.el |3 ++- testing/lisp/test-ob.el | 28 ++-- 2 files changed, 16 insertions(+), 15 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index e8a6d88..895a5b6 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -1920,7 +1920,8 @@ code the results are extracted in the syntax of the source (prvs (org-list-prevs-alist struct))) (org-list-get-list-end (point-at-bol) struct prvs))) ((looking-at "^\\([ \t]*\\):RESULTS:") - (re-search-forward (concat "^" (match-string 1) ":END:"))) + (progn (re-search-forward (concat "^" (match-string 1) ":END:")) + (forward-char 1)) (t (let ((case-fold-search t)) (if (looking-at (concat "[ \t]*#\\+begin_\\([^ \t\n\r]+\\)")) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index 178556e..7dccd22 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -771,20 +771,20 @@ replacement happens correctly." * next heading")) -;; TODO FIXME Activate when Eric's trailing newline fix has been committed -;; (ert-deftest test-ob/org-babel-remove-result--results-wrap () -;; (test-ob-verify-result-and-removed-result -;;":RESULTS: -;; hello there -;; :END:" -;; -;; "* org-babel-remove-result -;; -;; +begin_src emacs-lisp :results wrap -;; \"hello there\" -;; #+end_src -;; -;; * next heading")) +(ert-deftest test-ob/org-babel-remove-result--results-wrap () + "Test `org-babel-remove-result' with :results wrap." + (test-ob-verify-result-and-removed-result + ":RESULTS: +hello there +:END:" + + "* org-babel-remove-result + +#+begin_src emacs-lisp :results wrap +\"hello there\" +#+end_src + +* next heading")) (ert-deftest test-ob/org-babel-remove-result--results-org () "Test `org-babel-remove-result' with :results org." -- 1.7.3.4
Re: [O] export-as-hmtl fail
Hi Aaron aaron barclay writes: > Hello, > > When I use a python code block in a document any export-as-html results in > the error "Invalid file-name". Without a code block the export goes without > a hitch. Other exports work no probs such as export-as-ascii. The code > block within the document acts as expected, it is only the export that > fails. I was on org7.5 but updated to 7.8.03 but have the same result. > > Also, it is only the python code blocks that fail, others work. > > My babel setup is > > (org-babel-do-load-languages > 'org-babel-load-languages > '( (dot . t) > (sh . t) > (python . t) > (emacs-lisp . t) >)) > > (setq org-babel-python-command "python2.6") > > My code block is > > #+begin_src python :results output > print "hi" > > #+end_src > > #+results: > : hi > > Does anyone have any tips on what I might do to troubleshoot this. Could it > be something else in my setup or system? Any else ever experienced this? > > cheers, > aaron. I can't replicate this error (see my versions below). Even breaking `org-babel-python-command' does not break your code for me in the way you describe. For diagnostic purposes, you may run the command: - `M-x toggle-debug-on-error' ...prior to exporting as html. This should give you a useful backtrace. Note also that if you are wishing to export the python results as opposed to the python code, you will also need :exports results since the default is `:exports code' . HTH Best, Martyn --- Org-mode version 7.8.03 (release_7.8.03.192.ga38b.dirty) GNU Emacs 24.0.92.1 (x86_64-apple-darwin, NS apple-appkit-1038.36) of 2011-12-02 on bob.porkrind.org
Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas Goaziou writes: [...] >> 1) The commented out `# :exports both' appears to be exported as >> uncommented and relevant (actually, this appears to be true of the >> original exporter too). > > I cannot reproduce it. Anyway, see my comments below. > >> 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), >> as shown above, then the exporter appears to export the in-buffer >> results /and/ the export-generated results (where :exports is results >> or both) resulting in two sets of identical results in the export. > > It's out of exporter's scope. When you ask to export some buffer, what > is really parsed is a copy of the current buffer with > `org-export-blocks-preprocess' applied to it. > > So, simply apply that function in your test buffer, and you will see > what is sent to the parser. That will explain why the results appear > twice. > > In other words, tweaking the output of `org-export-blocks-preprocess' > will automatically change the outcome of the export process. Ah yes, I see - thanks for the clear explanation. Best, Martyn
Re: [O] [ANN] ASCII back-end for new export engine
Hi Nicolas Nicolas Goaziou writes: > Hello, > > I've commited an ASCII back-end for new export engine. > > Assuming contrib directory is in your load-path, you just need to > (require 'org-export) to have both LaTeX and ASCII exporters ready to > boot. > > You can then access to the dispatcher with M-x org-export-dispatch and > test various configurations from there. > [...] I've been playing with (org-export-dispatch) with regard to some simple source blocks and have a couple of observations (apologies in advance if source blocks are not fully implemented yet). The test code is: --8<---cut here---start->8--- * Test #+begin_src emacs-lisp # :exports both ;; Add two numbers (+ 2 3) #+end_src #+results: : 5 --8<---cut here---end--->8--- 1) The commented out `# :exports both' appears to be exported as uncommented and relevant (actually, this appears to be true of the original exporter too). 2) If the source block is executed in buffer with (org-ctrl-c-ctrl-c), as shown above, then the exporter appears to export the in-buffer results /and/ the export-generated results (where :exports is results or both) resulting in two sets of identical results in the export. For the record, I much prefer your new Ascii layout, over that provided by the original exporter. HTH Best, Martyn
Re: [O] [BUG] Inconsistency in src block hiding
Hi Nicolas Goaziou writes: > Hello, > > Eric Schulte writes: > >> Well maybe we should roll back this change. > > Please don't. _That_ would be a regression. > These changes /have/ caused a software regression, and should be reverted immediately, since: - they change current expected and implemented behavior to the cost of users expectations and current use, with no prior discussion and agreement on behavior changes It has been proven that to achieve the required consistency set out by this thread /without/ breaking current expectations is less than straight-forward, and the changes should therefore be moved to EXPERIMENTAL - at least until the changes are proven not to break current expectations. Much of org-mode is currently inconsistent - and while it is highly desirable to improve on that situation, it should not become the major decision to change code at the cost of regression - org-mode is a very practical system used successfully by lots of (very appreciative) people, and while all users appreciate bug fixes / enhancements in the fast-moving repository that is org-mode (thanks Carsten), clear regression such as this should be avoided in master at all costs. At least that is my understanding of the development model as established by Carsten. If this is /not/ the case, then many people are wasting their time writing regression tests IMHO. Best, Martyn [...]
[O] org-property-accumulation tests broken
Just a testing head's up... commit f1043a53cc46d2ce2e578d3cb498f895dc65f1ff breaks the tests. FAILED test-org-property-accumulation-append-use FAILED test-org-property-accumulation-append-val FAILED test-org-property-accumulation-top-use FAILED test-org-property-accumulation-top-val Best, Martyn
Re: [O] Capitalisation and good taste ?
pin...@iro.umontreal.ca (François Pinard) writes: > Bastien writes: > >> Eric Schulte writes: > >>> That said I'm happy that Org-mode is forgiving enough to allow me to >>> lowercase most of my keywords locally. > >> Actually, I'm thinking of another solution: > >> - keep one-line option/environment keywords uppercase >> #+NAME >> #+HTML >> #+TITLE >> #+... > [...] Personally, I would like to be able to do: ** Some code ~~~> emacs-lisp (some-code goes-here) <~~~ ... which compands to: ** Some code <~~~> el... Personally I dislike capitalized labels immensely! [...] Best, Martyn
Re: [O] [patch][babel] `org-babel-result-end' bug fix and regression tests
Hi Eric
Eric Schulte writes:
[...]
>>
>> All the tests supplied with the exception of
>> `test-ob/org-babel-remove-result--results-raw' will still pass without
>> the change.
>>
>
> Alright, would you be willing to resubmit the patch including only those
> tests which should still apply? This results handling is certainly an
> area which will benefit from beefing up the test suite.
The attached patch contains the remaining tests.
Best, Martyn
>From 6700e3f350c76f68891ad0ccd35538b5523312d9 Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Fri, 6 Jan 2012 19:36:28 +
Subject: [PATCH] Regression tests regarding code block results and result removal/replacement.
* testing/lisp/test-ob.el:
Regression tests regarding code block results and result removal/replacement
---
testing/lisp/test-ob.el | 205 +--
1 files changed, 198 insertions(+), 7 deletions(-)
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index dac6866..64e261a 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -137,13 +137,7 @@
#+name: i-have-a-name
#+begin_src emacs-lisp
42
-#+end_src
-
-#+name:
-: 42
-
-#+name: i-have-a-name
-: 42"
+#+end_src"
(progn
(org-babel-next-src-block 1)
@@ -671,6 +665,203 @@ on two lines
(org-babel-balanced-split ":a 1 :b [2 3] :c (4 :d (5 6))"
'((32 9) . 58)
+(ert-deftest test-ob/commented-last-block-line-no-var ()
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp
+;;
+#+end_src"
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (should (re-search-forward "\\#\\+results:" nil t))
+ (forward-line)
+ (should
+ (string=
+ ""
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol))
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp
+\"some text\";;
+#+end_src"
+
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (should (re-search-forward "\\#\\+results:" nil t))
+ (forward-line)
+ (should
+ (string=
+ ": some text"
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
+
+(ert-deftest test-ob/commented-last-block-line-with-var ()
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp :var a=1
+;;
+#+end_src"
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (re-search-forward "\\#\\+results:" nil t)
+ (forward-line)
+ (should (string=
+ ""
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol))
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp :var a=2
+2;;
+#+end_src"
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (re-search-forward "\\#\\+results:" nil t)
+ (forward-line)
+ (should (string=
+ ": 2"
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
+
+(defun test-ob-verify-result-and-removed-result (result buffer-text)
+ "Test helper function to test `org-babel-remove-result'.
+A temp buffer is populated with BUFFER-TEXT, the first block is executed,
+and the result of execution is verified against RESULT.
+
+The block is actually executed /twice/ to ensure result
+replacement happens correctly."
+ (org-test-with-temp-text
+ buffer-text
+(progn
+ (org-babel-next-src-block) (org-ctrl-c-ctrl-c) (org-ctrl-c-ctrl-c)
+ (should (re-search-forward "\\#\\+results:" nil t))
+ (forward-line)
+ (should (string= result
+ (buffer-substring-no-properties
+ (point-at-bol)
+ (- (point-max) 16
+ (org-babel-previous-src-block) (org-babel-remove-result)
+ (should (string= buffer-text
+ (buffer-substring-no-properties
+ (point-min) (point-max)))
+
+(ert-deftest test-ob/org-babel-remove-result--results-default ()
+ "Test `org-babel-remove-result' with default :results."
+ (mapcar (lambda (language)
+ (test-ob-verify-result-and-removed-result
+ "\n"
+ (concat
+"* org-babel-remove-result
+#+begin_src " language "
+#+end_src
+
+* next heading")))
+ '("sh" "emacs-lisp")))
+
+(ert-deftest test-ob/org-babel-remove-result--results-list ()
+ "Test `org-babel-remove-result' with :results list."
+ (test-ob-verify-result-and-removed-result
+ "- 1
+- 2
+- 3
+- (quote (4 5))"
+
+"* org-babel-remove-result
+#+begin_src emacs-lisp :results list
+'(1 2 3 '(4 5))
+#+end_src
+
+* next heading"))
+
+;; TODO FIXME Activate when Eric's trailing newline fix has been committed
+;; (ert-deftest test-ob/org-babel-remove-result--results-wrap ()
+;; (test-ob-verify-result-and-removed-result
Re: [O] [patch][babel] `org-babel-result-end' bug fix and regression tests
Eric Schulte writes: Hi Eric > Hi Martyn, > > Unfortunately there is no way to remove raw results because there is no > way to know where the results end. While your patch will certainly work > most of the time, it will not work in cases where the results includes > an empty line, and ultimately I think any attempt to remove raw results > will result in confusion. Yes I appreciate that would be a problem if there were empty lines. I just thought that most of the time is better than none of the time, but I understand your choice. Certainly wrap works fine. I have noticed one small issue regarding :results wrap, which is that an extra newline is appended to the end of the result each time `org-babel-execute-src-block' is executed. I imagine this can be safely removed? There are a few other minor issues also with `org-babel-remove-results' that probably should be fixed at some time (regarding append and prepend). > I think this patch should not be applied (although maybe some of the > test cases could still be useful). All the tests supplied with the exception of `test-ob/org-babel-remove-result--results-raw' will still pass without the change. Best, Martyn
Re: [O] [patch][babel] Fix latest block export tests to suit Emacs 22
Bastien writes: > Martyn Jago writes: > >> What appears to be a subtle difference in html export detail between >> Emacs 22 and Emacs 23+ breaks these latest tests on Emacs 22. >> >> The attached patch fixes them (and the subtle difference is not relevant >> to these tests). > > Applied, thanks! > > This commit has also been reported on #org-mode by the (new) CIA-26 > bot, which will report any commit from now on. > > Thanks to Jason for setting this up! Cool! I'll add it to my twitter feed :)
[O] [patch][babel] `org-babel-result-end' bug fix and regression tests
`org-babel-result-end' bug fix and `org-babel-remove-result' regression tests. * lisp/ob.el: The code block below will currently act as though :results prepend is set. This is due to `org-babel-result-end' being unable to find the correct end of a raw result. This patch fixes that. #+begin_src emacs-lisp :results raw "a line" #+end_src #+results: a line a line * testing/lisp/test-ob.el: Several regression tests that test the correct (multiple) execution of code blocks in the various results formats. The tests also test that 'org-babel-remove-result' correctly removes the result. Best, Martyn >From 5a3148fb1e3de288e5e3534ceb06eb64c20697aa Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Fri, 6 Jan 2012 17:10:00 + Subject: [PATCH] `org-babel-result-end' bug fix and `org-babel-remove-result' regression tests. * lisp/ob.el: The code block below will currently act as though :results prepend is set. This is due to `org-babel-result-end' being unable to find the correct end of a raw result. This patch fixes that. "a line" * testing/lisp/test-ob.el: Several regression tests that test the correct (multiple) execution of code blocks in the various results formats. The tests also test that 'org-babel-remove-result' correctly removes the result. --- lisp/ob.el |2 +- testing/lisp/test-ob.el | 218 +-- 2 files changed, 212 insertions(+), 8 deletions(-) diff --git a/lisp/ob.el b/lisp/ob.el index 0288eb3..26792ea 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -1810,7 +1810,7 @@ code the results are extracted in the syntax of the source (if (looking-at (concat "[ \t]*#\\+begin_" blocks-re)) (progn (re-search-forward (concat "[ \t]*#\\+end_" blocks-re) nil t) (forward-char 1)) - (while (looking-at "[ \t]*\\(: \\|\\[\\[\\)") + (while (not (looking-at "^\s*$")) (forward-line 1 (point) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index dac6866..f616776 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -137,13 +137,7 @@ #+name: i-have-a-name #+begin_src emacs-lisp 42 -#+end_src - -#+name: -: 42 - -#+name: i-have-a-name -: 42" +#+end_src" (progn (org-babel-next-src-block 1) @@ -671,6 +665,216 @@ on two lines (org-babel-balanced-split ":a 1 :b [2 3] :c (4 :d (5 6))" '((32 9) . 58) +(ert-deftest test-ob/commented-last-block-line-no-var () + (org-test-with-temp-text-in-file " +#+begin_src emacs-lisp +;; +#+end_src" +(progn + (org-babel-next-src-block) + (org-ctrl-c-ctrl-c) + (should (re-search-forward "\\#\\+results:" nil t)) + (forward-line) + (should + (string= + "" + (buffer-substring-no-properties (point-at-bol) (point-at-eol)) + (org-test-with-temp-text-in-file " +#+begin_src emacs-lisp +\"some text\";; +#+end_src" + +(progn + (org-babel-next-src-block) + (org-ctrl-c-ctrl-c) + (should (re-search-forward "\\#\\+results:" nil t)) + (forward-line) + (should + (string= + ": some text" + (buffer-substring-no-properties (point-at-bol) (point-at-eol))) + +(ert-deftest test-ob/commented-last-block-line-with-var () + (org-test-with-temp-text-in-file " +#+begin_src emacs-lisp :var a=1 +;; +#+end_src" +(progn + (org-babel-next-src-block) + (org-ctrl-c-ctrl-c) + (re-search-forward "\\#\\+results:" nil t) + (forward-line) + (should (string= + "" + (buffer-substring-no-properties (point-at-bol) (point-at-eol)) + (org-test-with-temp-text-in-file " +#+begin_src emacs-lisp :var a=2 +2;; +#+end_src" +(progn + (org-babel-next-src-block) + (org-ctrl-c-ctrl-c) + (re-search-forward "\\#\\+results:" nil t) + (forward-line) + (should (string= + ": 2" + (buffer-substring-no-properties (point-at-bol) (point-at-eol))) + +(defun test-ob-verify-result-and-removed-result (result buffer-text) + "Test helper function to test `org-babel-remove-result'. +A temp buffer is populated with BUFFER-TEXT, the first block is executed, +and the result of execution is verified against RESULT. + +The block is actually executed /twice/ to ensure result +replacement happens correctly." + (org-test-with-temp-text + buffer-text +(progn + (org-babel-next-src-block) (org-ctrl-c-ctrl-c) (org-ctrl-c-ctrl-c) + (should (re-search-forward "\\#\\+results:" nil t)) + (forward-line) + (should (string= result + (buffer-substring-no-properties + (point-at-bol) + (- (point-max) 16 + (org-babel-previous-src-block) (org-babel-remove-result) + (should (string=
Re: [O] [patch][test] Avoid writes to non-temp test-example files
Achim Gratz writes: > Achim Gratz writes: >> It may still have to >> do with the environment — I start NTemacs from Cygwin to be able to use >> Cygwin's make and this combination is somewhat fragile. > > ... and that seems indeed to be the culprit, running NTemacs from the > Cygwin shell somehow causes Emacs to assume C:\ for the temporary > directory, while it would correctly pick up the default location when > started from the shortcut. Again, setting TEMP to some sane value fixes > the problem and since it is environment related there's nothing to fix > in org mode. > Thanks for the head's up - I invariably end up on windows machines when doing embedded work so such information could be personally useful. Best, Martyn > > Regards, > Achim.
[O] [patch][babel] Fix latest block export tests to suit Emacs 22
What appears to be a subtle difference in html export detail between
Emacs 22 and Emacs 23+ breaks these latest tests on Emacs 22.
The attached patch fixes them (and the subtle difference is not relevant
to these tests).
Best, Martyn
>From b67f2c34fb2bea791b847c3dbb7dc26e313f779f Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Fri, 6 Jan 2012 08:08:21 +
Subject: [PATCH] Changes to latest block export tests to suit Emacs 22.
* testing/lisp/test-ob-exp.el:
Changes to latest block export tests to suit Emacs 22.
---
testing/lisp/test-ob-exp.el | 40 ++--
1 files changed, 14 insertions(+), 26 deletions(-)
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index 85af683..8ef27dd 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -73,7 +73,7 @@
(org-test-at-id "eb1f6498-5bd9-45e0-9c56-50717053e7b7"
(org-narrow-to-subtree)
(let ((exported-html
- (org-export-as-html nil nil nil 'string))
+ (org-export-as-html nil nil nil 'string 'body-only))
(test-point 0))
(org-test-with-temp-text-in-file
@@ -86,9 +86,7 @@
x
nil t)))
(setq test-point (point)))
- '("" "" ""
- ":noweb header argument expansion"
- ":noweb header argument expansion"
+ '(":noweb header argument expansion"
"message" "expanded1"
"message" "expanded2"
"noweb-1-yes-start"
@@ -99,8 +97,7 @@
"message" "expanded2"
"noweb-tangle-start"
"<<noweb-example1>>"
- "<<noweb-example2>>"
- ""))
+ "<<noweb-example2>>"))
(ert-deftest ob-exp/noweb-on-export-with-exports-results ()
"Noweb header arguments export correctly using :exports results.
@@ -110,7 +107,7 @@
(org-test-at-id "8701beb4-13d9-468c-997a-8e63e8b66f8d"
(org-narrow-to-subtree)
(let ((exported-html
- (org-export-as-html nil nil nil 'string))
+ (org-export-as-html nil nil nil 'string 'body-only))
(test-point 0))
(org-test-with-temp-text-in-file
@@ -123,9 +120,7 @@
x
nil t)))
(setq test-point (point)))
- '("" "" ""
- ":noweb header argument expansion using :exports results"
- ":noweb header argument expansion using :exports results"
+ '(":noweb header argument expansion using :exports results"
"expanded1"
"expanded2"
"expanded1"
@@ -133,8 +128,7 @@
"<<noweb-example1>>"
"expanded2"
"<<noweb-example1>>"
- "<<noweb-example2>>"
- ""))
+ "<<noweb-example2>>"))
(ert-deftest ob-exp/exports-both ()
"Test the :exports both header argument.
@@ -143,9 +137,8 @@ elements in the final html."
(org-test-at-id "92518f2a-a46a-4205-a3ab-bcce1008a4bb"
(org-narrow-to-subtree)
(let ((exported-html
- (org-export-as-html nil nil nil 'string))
+ (org-export-as-html nil nil nil 'string 'body-only))
(test-point 0))
-
(org-test-with-temp-text-in-file
exported-html
@@ -156,9 +149,7 @@ elements in the final html."
x
nil t)))
(setq test-point (point)))
- '("" "" ""
- "Pascal's Triangle – exports both test"
- "Pascal's Triangle – exports both test"
+ '( "Pascal's Triangle – exports both test"
""">1<"">3<"">3<"">1<"""
""">1<"">4<"">6<"">4<"">1<"""
""">1<"">5<"">10<"">10<"">5<"">1<"""
- """"
- ""))
+ """"))
(ert-deftest ob-exp/mixed-blocks-with-exports-both ()
(org-test-at-id "5daa4d03-e3ea-46b7-b093-62c1b7632df3"
(org-narrow-to-subtree)
(let ((exported-html
- (org-export-as-html nil nil nil 'string))
+ (org-export-as-html nil nil nil 'string 'body-only))
(test-point 0))
(org-test-with-temp-text-in-file
exported-html
@@ -192,9 +182,7 @@ elements in the final html."
x
nil t)))
(setq test-point (point)))
- '("" "" ""
- "mixed blocks with exports both"
- "mixed blocks with exports both"
+ '("mixed blocks with exports both"
""
"""a"""
"""b"""
@@ -205,9 +193,9 @@ elements in the final html."
""
""
"code block results"
- ""
- ""))
-
+ ""))
+
(provide 'test-ob-exp)
;;; test-ob-exp.el ends here
+
--
1.7.3.4
Re: [O] [patch][babel] test fix - was: Add test-run capability to Makefile
Martyn Jago writes: [...] > > However before you test it could you consider applying the following > patch. It is a fix to a relative character position offset change of 2 > caused by the trailing whitespace cleanup (my bad for leaving dirty test > data)! > [...] This patch seems to have been overlooked, and is still failing - my bad for tagging it to the end of this thread. Here it is again just in case. Best, Martyn >From 2327ec34fa8f29ea2aa03194a99ee535fefc3c94 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Wed, 4 Jan 2012 21:09:46 + Subject: [PATCH] Fix to test-org-babel/org-babel-get-inline-src-block-matches. * testing/lisp/test-ob.el: Character position offset -=2 to account for removal of trailing spaces --- testing/lisp/test-ob.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index 5f42dbb..dac6866 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -247,7 +247,7 @@ this is simple" (let ((test-point (point))) (should (fboundp 'org-babel-get-inline-src-block-matches)) (should (re-search-forward "src_" nil t)) ;; 1 - (should (= (+ test-point 140) (match-end 0))) + (should (= (+ test-point 138) (match-end 0))) (should (org-babel-get-inline-src-block-matches)) (should (re-search-forward "}" nil (point-at-bol))) ;; 1 (should-not (org-babel-get-inline-src-block-matches)) -- 1.7.3.4
Re: [O] [patch][test] Avoid writes to non-temp test-example files
Achim Gratz writes: > Martyn Jago writes: >> Attached is a patch to modify all tests that currently write to non-temp >> test-example files such as `testing/babel.org'. Instead, the tests now >> write to temp files, which are thrown away at the conclusion of the >> test. > > With NTemacs24 on Win7, if neither TMP nor TEMP environment variables > are set, it choses C:\ as the temp directory, which isn't writable for > normal users. This makes all tests fail that write to temporary files. > I'm not sure how exactly it ends up with C:\, but this should either be > fixed or we need to make sure that TEMP or TMP is set from Makefile > before running tests. > > > Regards, > Achim. Wow! Strictly speaking I guess that's an NTemacs24 bug, but we do have the option of over-riding the default Emacs tmp location, which may incur some extra house-keeping by the test-runners. I will leave that decision to a maintainer. I guess the makefile could issue a message on windows if an env var is not set? Best, Martyn
[O] [patch][babel] Fix for bug in ob-emacs-lisp.el
A block with a comment on the final line of a source block currently
errors in an emacs-lisp block.
This reduces down to the following at it's simplest:
#+begin_src emacs-lisp
#
#+end_src
Attached is a fix and regression tests
Best, Martyn
>From 4962f73a139566c8f796467a8a0423afbc9c911e Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Thu, 5 Jan 2012 18:00:12 +
Subject: [PATCH] Bug fix in ob-emacs-lisp.el.
* lisp/ob-emacs-lisp.el: A comment on the last line of an emacs-lisp
code block would cause an error when the block is was executed. This
fix cures this behaviour.
* testing/lisp/test-ob-emacs-lisp.el: Regression tests for the above
fix.
---
lisp/ob-emacs-lisp.el | 14 +++---
testing/lisp/test-ob-emacs-lisp.el | 82
2 files changed, 89 insertions(+), 7 deletions(-)
create mode 100644 testing/lisp/test-ob-emacs-lisp.el
diff --git a/lisp/ob-emacs-lisp.el b/lisp/ob-emacs-lisp.el
index afbc20d..c8af606 100644
--- a/lisp/ob-emacs-lisp.el
+++ b/lisp/ob-emacs-lisp.el
@@ -41,13 +41,13 @@
(result-params (cdr (assoc :result-params params)))
(print-level nil) (print-length nil)
(body (if (> (length vars) 0)
- (concat "(let ("
- (mapconcat
- (lambda (var)
- (format "%S" (print `(,(car var) ',(cdr var)
- vars "\n ")
- ")\n" body ")")
- body)))
+ (concat "(let ("
+ (mapconcat
+ (lambda (var)
+ (format "%S" (print `(,(car var) ',(cdr var)
+ vars "\n ")
+ ")\n" body "\n)")
+ (concat body "\n"
(if (or (member "code" result-params)
(member "pp" result-params))
(concat "(pp " body ")") body)))
diff --git a/testing/lisp/test-ob-emacs-lisp.el b/testing/lisp/test-ob-emacs-lisp.el
new file mode 100644
index 000..a83e8e9
--- /dev/null
+++ b/testing/lisp/test-ob-emacs-lisp.el
@@ -0,0 +1,82 @@
+;;; test-ob-emacs-lisp.el
+
+;; Copyright (c) 2012 Free Software Foundation, Inc.
+;; Authors: Eric Schulte, Martyn Jago
+
+;; Released under the GNU General Public License version 3
+;; see: http://www.gnu.org/licenses/gpl-3.0.html
+
+ Comments:
+
+;; Org-mode tests for ob-emacs-lisp.el live here
+
+
+;;; Code:
+
+(let ((load-path (cons (expand-file-name
+ ".." (file-name-directory
+ (or load-file-name buffer-file-name)))
+ load-path)))
+ (require 'org-test)
+ (require 'org-test-ob-consts))
+
+
+;;; Tests
+
+(ert-deftest ob-emacs-lisp/commented-last-block-line-no-var ()
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp
+;;
+#+end_src"
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (should (re-search-forward "results:" nil t))
+ (forward-line)
+ (should
+ (string=
+ ""
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol))
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp
+\"some text\";;
+#+end_src"
+
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (should (re-search-forward "results:" nil t))
+ (forward-line)
+ (should
+ (string=
+ ": some text"
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
+
+(ert-deftest ob-emacs-lisp/commented-last-block-line-with-var ()
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp :var a=1
+;;
+#+end_src"
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (re-search-forward "results" nil t)
+ (forward-line)
+ (should (string=
+ ""
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol))
+ (org-test-with-temp-text-in-file "
+#+begin_src emacs-lisp :var a=2
+2;;
+#+end_src"
+(progn
+ (org-babel-next-src-block)
+ (org-ctrl-c-ctrl-c)
+ (re-search-forward "results" nil t)
+ (forward-line)
+ (should (string=
+ ": 2"
+ (buffer-substring-no-properties (point-at-bol) (point-at-eol)))
+(provide 'test-ob-emacs-lisp)
+
+ ;;; test-ob-emacs-lisp.el ends here
--
1.7.3.4
[O] [patch][test] Fix and suplement pending tests in test-ob-exp.el
Fix pending tests in test-ob-exp.el related to exporting blocks with
various header arguments.
Best, Martyn
>From e71a64c531969876e9bba0659db2308a97806e5d Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Thu, 5 Jan 2012 15:49:16 +
Subject: [PATCH] Fixed and suplemented pending tests in `test-ob-exp.el'.
* testing/examples/babel.org: examples altered and added to
* testing/lisp/test-ob-exp.el: tests fixed and added to
---
testing/examples/babel.org | 76 +++
testing/lisp/test-ob-exp.el | 180 ++-
2 files changed, 204 insertions(+), 52 deletions(-)
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index bcb7e57..6c0825f 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -7,26 +7,69 @@
:END:
#+name: noweb-example
-#+begin_src emacs-lisp
- (message "expanded")
+#+begin_src emacs-lisp :results silent :exports code
+ (message "expanded1")
#+end_src
-#+begin_src emacs-lisp :noweb yes
- ;; noweb-yes-start
- <>
- ;; noweb-yes-end
+#+name: noweb-example2
+#+begin_src emacs-lisp :results silent
+ (message "expanded2")
#+end_src
-#+begin_src emacs-lisp :noweb no
- ;; noweb-no-start
+#+begin_src emacs-lisp :noweb yes :results silent
+;; noweb-1-yes-start
<>
- ;; noweb-no-end
#+end_src
-#+begin_src emacs-lisp :noweb tangle
+#+begin_src emacs-lisp :noweb no :results silent
+;; noweb-no-start
+ <>
+#+end_src
+
+#+begin_src emacs-lisp :noweb yes :results silent
+;; noweb-2-yes-start
+ <>
+#+end_src
+
+#+begin_src emacs-lisp :noweb tangle :results silent
;; noweb-tangle-start
+ <>
+ <>
+#+end_src
+
+* =:noweb= header argument expansion using :exports results
+ :PROPERTIES:
+ :ID: 8701beb4-13d9-468c-997a-8e63e8b66f8d
+ :END:
+
+#+name: noweb-example
+#+begin_src emacs-lisp :exports results
+ (message "expanded1")
+#+end_src
+
+#+name: noweb-example2
+#+begin_src emacs-lisp :exports results
+ (message "expanded2")
+#+end_src
+
+#+begin_src emacs-lisp :noweb yes :exports results
+;; noweb-1-yes-start
<>
- ;; noweb-tangle-end
+#+end_src
+
+#+begin_src emacs-lisp :noweb no :exports code
+;; noweb-no-start
+ <>
+#+end_src
+
+#+begin_src emacs-lisp :noweb yes :exports results
+;; noweb-2-yes-start
+ <>
+#+end_src
+
+#+begin_src emacs-lisp :noweb tangle :exports code
+ <>
+ <>
#+end_src
* excessive id links on tangling
@@ -62,7 +105,7 @@
#+name: i-have-a-name
: 42
-* Pascal's Triangle -- export test
+* Pascal's Triangle -- exports both test
:PROPERTIES:
:ID: 92518f2a-a46a-4205-a3ab-bcce1008a4bb
:END:
@@ -153,21 +196,24 @@ Here is one in the middle src_sh{echo 1} of a line.
Here is one at the end of a line. src_sh{echo 2}
src_sh{echo 3} Here is one at the beginning of a line.
-* conflicting blocks on export
+* mixed blocks with exports both
:PROPERTIES:
:ID: 5daa4d03-e3ea-46b7-b093-62c1b7632df3
:END:
+
#+name: a-list
- a
- b
- c
-#+begin_src emacs-lisp :results wrap :exports both
+#+begin_src emacs-lisp :exports both
"code block results"
#+end_src
-#+begin_src emacs-lisp :var lst=a-list :results list
+
+#+begin_src emacs-lisp :var lst=a-list :results list :exports both
(reverse lst)
#+end_src
+
* using the =:noweb-ref= header argument
:PROPERTIES:
:ID: 54d68d4b-1544-4745-85ab-4f03b3cbd8a0
diff --git a/testing/lisp/test-ob-exp.el b/testing/lisp/test-ob-exp.el
index b9bec99..c303c5d 100644
--- a/testing/lisp/test-ob-exp.el
+++ b/testing/lisp/test-ob-exp.el
@@ -65,44 +65,150 @@
(should-not (file-exists-p (concat org-test-link-in-heading-file "::")))
(when (file-exists-p html-file) (delete-file html-file
-;; TODO
-;; (ert-deftest ob-exp/noweb-on-export ()
-;; "Noweb header arguments export correctly.
-;; - yes expand on both export and tangle
-;; - no expand on neither export or tangle
-;; - tangle expand on only tangle not export"
-;; (let (html)
-;; (org-test-at-id "eb1f6498-5bd9-45e0-9c56-50717053e7b7"
-;; (org-narrow-to-subtree)
-;; (let ((arg nil)
-;; )
-;; (mapcar (lambda (x)
-;; (should (equal ""
-;; (org-export-as-html nil
-;; nil
-;; nil
-;; 'string
-;; '("yes" "no" "tangle"))
-
-
-;; TODO Test broken (args-out-of-range 1927 3462)
-;; (ert-deftest ob-exp/exports-both ()
-;; "Test the :exports both header argument.
-;; The code block should create both and
-;; elements in the final html."
-;; (let (html)
-;; (org-test-at-id "92518f2a-a46a-4205-a3ab-bcce1008a4bb"
-;; (org-narrow-to-subtree)
-;; (setq html (org-export-as-html nil nil nil 'string))
-;; (should (string-match "[^\000]*" html))
-;;
Re: [O] [patch][test] Avoid writes to non-temp test-example files
Nick Dokos writes: > Martyn Jago wrote: > >> >> Attached is a patch to modify all tests that currently write to non-temp >> test-example files such as `testing/babel.org'. Instead, the tests now >> write to temp files, which are thrown away at the conclusion of the >> test. >> > > Are the temp files kept if the test fails? IME, that's a useful debugging aid. > > Nick > >> All tests still pass. >> >> HTH >> >> Best, Martyn >> If a test fails (or breaks in some way) and the temp-file has been created, it remains in the `temporary-file-directory' (the test system uses the standard Emacs make-temp-file mechanism). The file is referenced in the ert failure backtrace, and may be viewed in Emacs (press `b' on the failure in ert), although there is usually enough information in the backtrace / test-case to point to the failure. Emacs takes care of removing the old tmp files over time. Best, Martyn
Re: [O] [patch] Add test-run capability to Makefile
Bastien writes: > Martyn Jago writes: > >> Since the Makefile is currently getting a refresh I thought it would be >> very useful to allow running of the regression test suite directly from >> make using `make test'. > > Nice -- I will test this through Achim's branch. > > Thanks! Thanks! However before you test it could you consider applying the following patch. It is a fix to a relative character position offset change of 2 caused by the trailing whitespace cleanup (my bad for leaving dirty test data)! I may re-consider cleaning trailing whitespace in the post-save hook, which is something I used to do, but which could generate a lot of commit /noise/ where trailing whitespace removal isn't de-rigueur. Best, Martyn >From 2327ec34fa8f29ea2aa03194a99ee535fefc3c94 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Wed, 4 Jan 2012 21:09:46 + Subject: [PATCH] Fix to test-org-babel/org-babel-get-inline-src-block-matches. * testing/lisp/test-ob.el: Character position offset -=2 to account for removal of trailing spaces --- testing/lisp/test-ob.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index 5f42dbb..dac6866 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -247,7 +247,7 @@ this is simple" (let ((test-point (point))) (should (fboundp 'org-babel-get-inline-src-block-matches)) (should (re-search-forward "src_" nil t)) ;; 1 - (should (= (+ test-point 140) (match-end 0))) + (should (= (+ test-point 138) (match-end 0))) (should (org-babel-get-inline-src-block-matches)) (should (re-search-forward "}" nil (point-at-bol))) ;; 1 (should-not (org-babel-get-inline-src-block-matches)) -- 1.7.3.4
[O] [patch][test] Avoid writes to non-temp test-example files
Attached is a patch to modify all tests that currently write to non-temp
test-example files such as `testing/babel.org'. Instead, the tests now
write to temp files, which are thrown away at the conclusion of the
test.
All tests still pass.
HTH
Best, Martyn
>From c56d5101de63bda4a0df7bf0800761f51624194b Mon Sep 17 00:00:00 2001
From: Martyn Jago
Date: Wed, 4 Jan 2012 17:44:09 +
Subject: [PATCH] Modify tests to avoid writing to non-temp test-example files.
* testing/examples/babel.org:
* testing/examples/table.org:
* testing/lisp/test-ob.el:
* testing/lisp/test-org-table.el:
Tests that used to write to a test-example file (ie testing/babel.org)
have been modified to write to temp files instead.
This avoids leaving open and /modified/ tests in Emacs when tests are
run by `org-test-run-all-tests'.
---
testing/examples/babel.org | 76 ---
testing/examples/table.org | 19 -
testing/lisp/test-ob.el| 162 ++--
testing/lisp/test-org-table.el | 28 ++--
4 files changed, 144 insertions(+), 141 deletions(-)
delete mode 100644 testing/examples/table.org
diff --git a/testing/examples/babel.org b/testing/examples/babel.org
index bb9cab9..ba7c3e3 100644
--- a/testing/examples/babel.org
+++ b/testing/examples/babel.org
@@ -29,19 +29,6 @@
;; noweb-tangle-end
#+end_src
-* elisp forms in header arguments
- :PROPERTIES:
- :ID: 22d67284-bf14-4cdc-8319-f4bd876829d7
- :var: prop=(+ 2 2)
- :END:
-
-#+begin_src emacs-lisp
- prop
-#+end_src
-
-#+name:
-: 4
-
* excessive id links on tangling
:PROPERTIES:
:ID: ef06fd7f-012b-4fde-87a2-2ae91504ea7e
@@ -59,42 +46,6 @@
#+begin_src emacs-lisp :tangle no
(message "for tangling")
#+end_src
-* simple variable resolution
- :PROPERTIES:
- :ID: f68821bc-7f49-4389-85b5-914791ee3718
- :END:
-
-#+name: four
-#+begin_src emacs-lisp
- (list 1 2 3 4)
-#+end_src
-
-#+begin_src emacs-lisp :var four=four
- (length four)
-#+end_src
-
-#+name:
-: 4
-
-* multi-line header arguments
- :PROPERTIES:
- :ID: b77c8857-6c76-4ea9-8a61-ddc2648d96c4
- :END:
-
-#+headers: :var letters='(a b c d e f g)
-#+begin_src emacs-lisp :var numbers='(1 2 3 4 5 6 7)
- (map 'list #'list numbers letters)
-#+end_src
-
-#+name:
-| 1 | a |
-| 2 | b |
-| 3 | c |
-| 4 | d |
-| 5 | e |
-| 6 | f |
-| 7 | g |
-
* simple named code block
:PROPERTIES:
:ID: 0d82b52d-1bb9-4916-816b-2c67c8108dbb
@@ -202,14 +153,6 @@ Here is one in the middle src_sh{echo 1} of a line.
Here is one at the end of a line. src_sh{echo 2}
src_sh{echo 3} Here is one at the beginning of a line.
-* parsing header arguments
- :PROPERTIES:
- :ID: 7eb0dc6e-1c53-4275-88b3-b22f3113b9c3
- :END:
-
-#+begin_src example-lang :session :results output :var num=9
- the body
-#+end_src
* conflicting blocks on export
:PROPERTIES:
:ID: 5daa4d03-e3ea-46b7-b093-62c1b7632df3
@@ -289,22 +232,3 @@ src_sh{echo "One"} block at start of line
One spaced block in src_sh{ echo "middle" } of line
src_sh{echo 2} blocks on the src_emacs-lisp{"same"} line
Inline block with src_sh[:results silent]{ echo "parameters" }.
-* returning file names -- interpreted as lists
- :PROPERTIES:
- :ID: a73a2ab6-b8b2-4c0e-ae7f-23ad14eab7bc
- :END:
-
-#+begin_src sh :results scalar
- echo "[[file:./cv.cls]]"
-#+end_src
-
-#+name:
-: [[file:./cv.cls]]
-
-#+begin_src sh :results raw scalar
- echo "[[file:./cv.cls]]"
-#+end_src
-
-#+name:
-[[file:./cv.cls]]
-
diff --git a/testing/examples/table.org b/testing/examples/table.org
deleted file mode 100644
index 3c6caed..000
--- a/testing/examples/table.org
+++ /dev/null
@@ -1,19 +0,0 @@
-#+TITLE: example file with tables
-#+OPTIONS: num:nil ^:nil
-
-This is an example file for use by the Org-mode tests defined in
-file:../lisp/test-org-table.el.
-
-* simple formula
- :PROPERTIES:
- :ID: 563523f7-3f3e-49c9-9622-9216cc9a5d95
- :END:
-
-#+tblname: simple-formula
-| 1 |
-| 2 |
-| 3 |
-| 4 |
-||
-| 10 |
- #+TBLFM: $1=vsum(@1..@-1)
diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el
index ee4f298..4b57f21 100644
--- a/testing/lisp/test-ob.el
+++ b/testing/lisp/test-ob.el
@@ -114,51 +114,121 @@
(ert-deftest test-org-babel/elisp-in-header-arguments ()
"Test execution of elisp forms in header arguments."
- ;; at the babel.org:elisp-forms-in-header-arguments header
- (org-test-at-id "22d67284-bf14-4cdc-8319-f4bd876829d7"
-(org-babel-next-src-block)
-(let ((info (org-babel-get-src-block-info)))
- (should (= 4 (org-babel-execute-src-block))
+ (org-test-with-temp-text-in-file "
+
+* elisp forms in header arguments
+ :PROPERTIES:
+ :var: prop = (* 7 6)
+ :END:
+#+begin_src emacs-lisp
+ prop
+#+end_src"
+
+(progn
+ (goto-char (point-min))
+ (org-babel-ne
[O] [patch] Add test-run capability to Makefile
Since the Makefile is currently getting a refresh I thought it would be very useful to allow running of the regression test suite directly from make using `make test'. The following patch achieves this and allows a user to run the regression test suite on the their system following installation. This makes it super-easy for a user to validate their latest org-mode installation. HTH Best, Martyn >From f025591e918d8921eaea0188da0b0da806c8b6f6 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Wed, 4 Jan 2012 14:24:27 + Subject: [PATCH] Add test command to Makefile * Makefile: This patch enables `make test' to run the regression tests on the user's system following installation. This makes it super-easy for a user to validate their system. --- Makefile |6 ++ 1 files changed, 6 insertions(+), 0 deletions(-) diff --git a/Makefile b/Makefile index 520b0fd..491d761 100644 --- a/Makefile +++ b/Makefile @@ -36,6 +36,9 @@ infodir = $(prefix)/share/info BATCH=$(EMACS) -batch -q -no-site-file -eval \ "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"$(lispdir)\" load-path)))" $(BATCH_EXTRA) +BATCHTEST=$(EMACS) -Q -batch -l testing/org-test.el \ + -eval "(setq org-confirm-babel-evaluate nil)" -f org-test-run-batch-tests + # Specify the byte-compiler for compiling org-mode files ELC= $(BATCH) -f batch-byte-compile @@ -496,6 +499,9 @@ pushreleasetag: git tag -m "Adding release tag" -a release_$(TAG) git push orgm...@orgmode.org:org-mode.git release_$(TAG) +test: + $(BATCHTEST) + # Dependencies lisp/org.elc: lisp/org-macs.el lisp/org-compat.el lisp/org-faces.el -- 1.7.3.4
[O] [babel][patch] org-test-with-temp-text-in-file works in Emacs 22
Attached is a patch to fix macro `org-test-with-temp-text-in-file' on Emacs 22. In Emacs 22 the (kill-buffer) argument is NOT optional. This change reflects this and allows the macro `org-test-with-temp-text-in-file' to work in Emacs 22 for org compatibility. This fixes the test `test-ob-lob/do-not-eval-lob-lines-in-example-blocks-on-export' on Emacs 22. This fixes the remaining unexpected test failure on Emacs 22.1.1 Best, Martyn >From 5622523ccc9995ff6a0c804c4de8c414ca5e6181 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Wed, 4 Jan 2012 13:37:07 + Subject: [PATCH] Modify macro `org-test-with-temp-text-in-file' to work on emacs 22. * testing/org-test.el: In Emacs 22 the `kill-buffer' argument is NOT optional. This change reflects this and allows the macro `org-test-with-temp-text-in-file' to work in Emacs 22 for org compatibility. This fixes the test `test-ob-lob/do-not-eval-lob-lines-in-example-blocks-on-export' --- testing/org-test.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/testing/org-test.el b/testing/org-test.el index de8f3a5..a9e3706 100644 --- a/testing/org-test.el +++ b/testing/org-test.el @@ -211,7 +211,7 @@ otherwise place the point at the beginning of the inserted text." (find-file ,file) (org-mode) (setq ,results ,@body) - (save-buffer) (kill-buffer) + (save-buffer) (kill-buffer (current-buffer)) (delete-file ,file) ,results))) (def-edebug-spec org-test-with-temp-text-in-file (form body)) -- 1.7.3.4
Re: [O] [babel][bug] org-babel-balanced-split (with Emacs-22)
Eric Schulte writes:
> Martyn Jago writes:
>
>> Martyn Jago writes:
>>
>> [...]
>>
>> The problem appears to be associated with the way `member' works:
>>
>> - on Emacs 23+ the following doesn't generate an error
>> - on Emacs 22 it generates "Wrong type argument: listp, 58"
>>
>> #+begin_src emacs-lisp
>>
>> (member 116 58)
>>
>> #+end_src
>>
>> `org-babel-balanced-split' appears to rely on not generating an error
>> when the `member' LIST parameter is actually a number.
>>
>
> Ah, I see where this comes in, does the included alternative definition
> of this function fix the issue on Emacs22? If so I'll apply this change
> to the repository.
>
> Thanks,
>
> (defun org-babel-balanced-split (string alts)
> "Split STRING on instances of ALTS.
> ALTS is a cons of two character options where each option may be
> either the numeric code of a single character or a list of
> character alternatives. For example to split on balanced
> instances of \"[ \t]:\" set ALTS to '((32 9) . 58)."
> (flet ((matches (ch spec) (or (and (numberp spec) (= spec ch))
> (not (numberp spec) (member ch spec
[...]
Hi Eric
I fixed a typo on your fix, and added a regression test, and it now
works on Emacs 22. Thanks!
Best, Martyn
--8<---cut here---start->8---
(defun org-babel-balanced-split (string alts)
"Split STRING on instances of ALTS.
ALTS is a cons of two character options where each option may be
either the numeric code of a single character or a list of
character alternatives. For example to split on balanced
instances of \"[ \t]:\" set ALTS to '((32 9) . 58)."
(flet ((matches (ch spec) (or (and (numberp spec) (= spec ch))
(and (not (numberp spec))
(member ch spec
(matched (ch last)
(if (consp alts)
(and (matches ch (cdr alts))
(matches last (car alts)))
(matches ch alts
(let ((balance 0) (quote nil) (partial nil) (lst nil) (last 0))
(mapc (lambda (ch) ; split on [], (), "" balanced instances of [ \t]:
(setq balance (+ balance
(cond ((or (equal 91 ch) (equal 40 ch)) 1)
((or (equal 93 ch) (equal 41 ch)) -1)
(t 0
(when (and (equal 34 ch) (not (equal 92 last)))
(setq quote (not quote)))
(setq partial (cons ch partial))
(when (and (= balance 0) (not quote) (matched ch last))
(setq lst (cons (apply #'string (nreverse
(if (consp alts)
(cddr partial)
(cdr partial
lst))
(setq partial nil))
(setq last ch))
(string-to-list string))
(nreverse (cons (apply #'string (nreverse partial)) lst)
--8<---cut here---end--->8---
--8<---cut here---start->8---
(ert-deftest test-ob/org-babel-balanced-split ()
(should (equal
'(":a 1" "b [2 3]" "c (4 :d (5 6))")
(org-babel-balanced-split ":a 1 :b [2 3] :c (4 :d (5 6))" '((32 9) .
58)
--8<---cut here---end--->8---
Re: [O] [babel][bug] org-babel-balanced-split (with Emacs-22)
Martyn Jago writes: > There is a bug running babel on Emacs 22.1.1 with a minimal init file. > [...] > > The following fails: > > * Test fails > > #+begin_src emacs-lisp :results silent > > "hello there" > > #+end_src > [...] The problem appears to be associated with the way `member' works: - on Emacs 23+ the following doesn't generate an error - on Emacs 22 it generates "Wrong type argument: listp, 58" #+begin_src emacs-lisp (member 116 58) #+end_src `org-babel-balanced-split' appears to rely on not generating an error when the `member' LIST parameter is actually a number. Best, Martyn
[O] [babel][bug]
There is a bug running babel on Emacs 22.1.1 with a minimal init file. The following code works: --8<---cut here---start->8--- * Test passes #+begin_src emacs-lisp "hello there" #+end_src #+results: : hello there --8<---cut here---end--->8--- The following fails: --8<---cut here---start->8--- * Test fails #+begin_src emacs-lisp :results silent "hello there" #+end_src --8<---cut here---end--->8--- The problem appears to be associated with the :results parsing. The backtrace is as follows: --8<---cut here---start->8--- Debugger entered--Lisp error: (wrong-type-argument listp 58) matches(114 58) matched(114 58) #[(ch) "
Re: [O] Happy new year!
Bastien writes: > Dear all, > > time to wrap-up for today and to celebrate. > This has been a *great* year of development! > May all your TODOs belong to your %s_archive. > > Happy new year :) Indeed! Bonne année et bonne santé! It's time to get the glad rags on and C-c C-c :)
Re: [O] ca47d10e commit broke the build
Hi Jambunathan Jambunathan K writes: > Martyn > > The probelmatic commit could actually be this: > commit - 07f006e4fd9a7b66643cd7b404c8994665ba8300 > which touches the Makefile. The problem was indeed related to the Makefile - the thing that changed (I'm guessing) is the use of the EMACS variable during `make install' (re-compilation of org-odt)? The solution was to change the test-build scripts from: --8<---cut here---start->8--- make clean && make EMACS=/Applications/Emacs-2x.app/Contents/MacOS/Emacs && make install && make doc && /Applications/Emacs-2x.app/Contents/MacOS/Emacs -Q -batch -l /Users/martyn/.cruise/projects/Org-mode_on_Emacs_24/work/testing/org-test.el -eval "(setq org-confirm-babel-evaluate nil)" -f org-test-run-batch-tests --8<---cut here---end--->8--- ...to: --8<---cut here---start->8--- make clean && make EMACS=/Applications/Emacs-2x.app/Contents/MacOS/Emacs && make install EMACS=/Applications/Emacs-2x.app/Contents/MacOS/Emacs && make doc EMACS=/Applications/Emacs-2x.app/Contents/MacOS/Emacs && /Applications/Emacs-2x.app/Contents/MacOS/Emacs -Q -batch -l /Users/martyn/.cruise/projects/Org-mode_on_Emacs_24/work/testing/org-test.el -eval "(setq org-confirm-babel-evaluate nil)" -f org-test-run-batch-tests --8<---cut here---end--->8--- ...since the compile version was detected to be incompatible (EMACS was defaulting to v22.1.1 during make install). This fixes my v24 and v23 test builds. There is a broken test under v22 which I will look at in the near future. Best, Martyn [...]
[O] ca47d10e commit broke the build
Frankly I'm not sure why, but my build is broken against emacs 22,23,24 Ref: http://martynjago.co.uk:/builds/Org-mode_on_Emacs_24/ca47d10e1f0070f5c6461ff763486b693ff77209 Best, Martyn
Re: [O] Refresh of http://orgmode.org
Bastien writes: > Dear all, > > I made a small refresh of the website. > > http://orgmode.org > > - random quote (taken from worg/org-quotes.org) > - random screenshot > - twitter feed > - g+/flattr/fb buttons > - french translation (http://orgmode.org/fr/) > > If you want to help with the translation in your language, > please send your public key and I will give you push access. > This is just a bunch of .org files, only 1 hour needed to > translate the whole website. > > Hope you like it! I personally really like the new look (on a 19" Wide-screen Safari browser under OSX). It looks really clean, organized, and professional. I tended to think the original page held just too much information, as a landing page - i.e. for a potentially new Org-user who is making there first steps into researching Org-mode. Incidentally, it also looks really good on the Ipad (safari), where the left-hand column links work just fine. Best, Martyn
Re: [O] Worg migration complete
Hi Jason Achim Gratz writes: > Nick Dokos writes: >> ... but then you'll encounter problems when you try to push, right? > > Yes. It's sorted now, thanks to Jason. First there was some bogus > newlines in the authentication file of the server, so some keys were not > recognized. The remote to push to must be > > w...@orgmode.org:worg.git > > Alternatively, in URL syntax that is > > git+ssh://w...@orgmode.org/~/worg.git > > The crucial part is the "~", otherwise it'd search the repository in the > root directory. Since I pull via the public interface to avoid the > overhead of an encrypted connection unless it is really needed, I've put > > [url "git+ssh://w...@orgmode.org/~/"] > pushInsteadOf = git://orgmode.org/ > > in my global .gitconfig; you could also have that in the repository > config or configure separate pull and push URL for the remote. > > > Regards, > Achim. The relocation of Worg has proved to be very painless for me, and I really like the new `instant publishing' feature, which works great! Thanks for your time and effort on these changes. Best, Martyn
Re: [O] Bastiens talk
Hi Bastien writes: > Rustom Mody writes: > >> I'll try and flesh out the rest and post it here > > http://orgmode.org/worg/org-tutorials/org-screencasts/ghm2011-demo.html > > Next step is to have worg-links to the main concepts presented here. > > Thanks! I think this is a great screencast for whetting the appetite of prospective Org-mode users - it is up-to-date, practical, and includes features in the pipeline. I hope you don't mind Bastien, but I took the liberty of adding a link to Worg under the heading *General Introduction to Org-mode* on the *Org tutorials* page [1]. http://orgmode.org/worg/org-tutorials/index.html Best, Martyn
Re: [O] [bug] Commit 6f8ea8e breaks the build
Hi Jambunathan Jambunathan K writes: > Martyn Jago writes: > >> Commit 6f8ea8e breaks the build. > >>> make clean >>> make >> >> ...returns the error: >> >> >> emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name >> \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))" -f >> batch-byte-compile lisp/org-odt.el >> >> In toplevel form: >> lisp/org-odt.el:31:13:Error: Cannot open load file: htmlfontify >> make: *** [lisp/org-odt.elc] Error 1 > > I am using Windows/Cygwin and Emacs-24 pretest builds. org-odt.el > compiles just fine. > The problem appears to be that htmlfontify.el was not present in Emacs-23 and Emacs-22 releases. This is a problem since Org-mode is supposed to build with releases back to Emacs-22. Since my build builds all versions to ensure against regression, the build failed. Best, Martyn > In toplevel form: > org-mouse.el:320:1:Warning: global/dynamic var `rest' lacks a prefix > org-mouse.el:1024:1:Warning: global/dynamic var `_cmd' lacks a prefix > Wrote c:/Documents and Settings/kjambunathan/My Documents/My > Data/src/org-mode/lisp/org-mouse.elc > emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name > \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))" -f > batch-byte-compile lisp/org-odt.el > Wrote c:/Documents and Settings/kjambunathan/My Documents/My > Data/src/org-mode/lisp/org-odt.elc > > Don't you have htmlfontify.el in your version of Emacs? I thought it is > part of regular Emacs. Could you please check why this is so? May be > some adjustment of load path is required or htmlfontify.el has to be > installed. > >> >> Best, Martyn >> >> --- >> Org-mode version 7.7 (release_7.7.674.gc609) >> GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) >> of 2011-08-21 on virtualmac.porkrind.org >> >> >>
[O] [bug] Commit 6f8ea8e breaks the build
Commit 6f8ea8e breaks the build. > make clean > make ...returns the error: --8<---cut here---start->8--- emacs -batch -q -no-site-file -eval "(setq load-path (cons (expand-file-name \"./lisp/\") (cons \"/usr/local/share/emacs/site-lisp\" load-path)))" -f batch-byte-compile lisp/org-odt.el In toplevel form: lisp/org-odt.el:31:13:Error: Cannot open load file: htmlfontify make: *** [lisp/org-odt.elc] Error 1 --8<---cut here---end--->8--- Best, Martyn --- Org-mode version 7.7 (release_7.7.674.gc609) GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of 2011-08-21 on virtualmac.porkrind.org
Re: [O] [PATCH] Lilypond: added PDF output
Hi Torsten
Torsten Anders writes:
> Dear all,
>
> The current implementation how org-babel calls Lilypond hard-wires the
> supported output file formats to EPS and PNG. Attached is a very
> simple patch that adds support for PDF as well, so that resulting PDF
> files can be directly integrated in the PDF files generated by Latex
> and Latex Beamer support.
>
> Thanks!
>
> Best wishes,
> Torsten
Doesn't :cmdline " --pdf " work for you?
--8<---cut here---start->8---
#+begin_src lilypond :file ionian.pdf :noweb yes :cmdline " --pdf "
<>
\relative c' {
c d e f g a b c b a g f e d c d
e f g a b c b a g f e d c1
}
#+end_src
--8<---cut here---end--->8---
If you have an example of how you are exporting we could maybe add it to the
examples in
Worg? It is not a use-case I have considered.
Best, Martyn
Re: [O] [BUG] org-table: time difference delivers wrong results
Martyn Jago writes: Apologies I had a typo - please ignore the previous mail. So this looks more sensible: > Daniel Bausch writes: > >> Anyone? It might be a duplicate of what Gustav Wiktröm reported on 1st of >> September, but his problem was not resolved, either. >> >> Daniel >> >> Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch: >>> Hello list, >>> >>> consider the following example: >>> |A | B | C | >>> | >>> |--+---+---| >>> | >>> | 07:11:00 | -08:00:00 | -01:11:00 | >>> >>> #+TBLFM: $3=$1+$2;T > > [...] | Data 1 | Data 2 | Total | |--+--+---| | 00:00:00 | 00:00:00 | 00:00:00 | | 00:00:00 | 00:00:01 | -01:59:59 | | 00:00:00 | 00:00:02 | -01:59:58 | | 00:00:00 | 00:00:03 | -01:59:57 | | 00:00:00 | 00:00:04 | -01:59:56 | | 00:00:00 | 00:00:05 | -01:59:55 | | 00:00:00 | 00:00:06 | -01:59:54 | | 00:00:00 | 00:00:07 | -01:59:53 | | 00:00:00 | 00:00:08 | -01:59:52 | | 00:00:00 | 00:00:09 | -01:59:51 | | 00:00:00 | 00:00:10 | -01:59:50 | | 00:00:00 | 00:00:11 | -01:59:49 | | 00:00:00 | 00:00:12 | -01:59:48 | | 00:00:00 | 00:00:13 | -01:59:47 | | 00:00:00 | 00:00:14 | -01:59:46 | | 00:00:00 | 00:00:15 | -01:59:45 | #+TBLFM: @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T | Data 1 | Data 2 | Total | |--+--+---| | 00:00:00 | 00:00:16 | -01:59:44 | | 00:00:00 | 00:00:17 | -01:59:43 | | 00:00:00 | 00:00:18 | -01:59:42 | | 00:00:00 | 00:00:19 | -01:59:41 | | 00:00:00 | 00:00:20 | -01:59:40 | | 00:00:00 | 00:00:21 | -01:59:39 | | 00:00:00 | 00:00:22 | -01:59:38 | | 00:00:00 | 00:00:23 | -01:59:37 | | 00:00:00 | 00:00:24 | -01:59:36 | | 00:00:00 | 00:00:25 | -01:59:35 | | 00:00:00 | 00:00:26 | -01:59:34 | | 00:00:00 | 00:00:27 | -01:59:33 | | 00:00:00 | 00:00:28 | -01:59:32 | | 00:00:00 | 00:00:29 | -01:59:31 | | 00:00:00 | 00:00:30 | -01:59:30 | | 00:00:00 | 00:00:31 | -01:59:29 | #+TBLFM: @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T | Data 1 | Data 2 | Total | |--+--+---| | 00:00:00 | 00:00:59 | -01:59:01 | | 00:00:00 | 00:01:00 | -01:59:00 | | 00:00:00 | 00:01:01 | -01:58:59 | | 00:00:00 | 00:01:02 | -01:58:58 | | 00:00:00 | 00:01:03 | -01:58:57 | | 00:00:00 | 00:01:04 | -01:58:56 | | 00:00:00 | 00:01:05 | -01:58:55 | | 00:00:00 | 00:01:06 | -01:58:54 | | 00:00:00 | 00:01:07 | -01:58:53 | | 00:00:00 | 00:01:08 | -01:58:52 | | 00:00:00 | 00:01:09 | -01:58:51 | | 00:00:00 | 00:01:10 | -01:58:50 | | 00:00:00 | 00:01:11 | -01:58:49 | | 00:00:00 | 00:01:12 | -01:58:48 | | 00:00:00 | 00:01:13 | -01:58:47 | | 00:00:00 | 00:01:14 | -01:58:46 | #+TBLFM: @2$3=$1-$2;T::@3$3=$1-$2;T::@4$3=$1-$2;T::@5$3=$1-$2;T::@6$3=$1-$2;T::@7$3=$1-$2;T::@8$3=$1-$2;T::@9$3=$1-$2;T::@10$3=$1-$2;T::@11$3=$1-$2;T::@12$3=$1-$2;T::@13$3=$1-$2;T::@14$3=$1-$2;T::@15$3=$1-$2;T::@16$3=$1-$2;T::@17$3=$1-$2;T Best, Martyn -- I _will_ engage brain before posting to the ML :(
Re: [O] [BUG] org-table: time difference delivers wrong results
Daniel Bausch writes: > Anyone? It might be a duplicate of what Gustav Wiktröm reported on 1st of > September, but his problem was not resolved, either. > > Daniel > > Am Dienstag 15. November 2011, 22:12:45 schrieb Daniel Bausch: >> Hello list, >> >> consider the following example: >> |A | B | C | >> | >> |--+---+---| >> | >> | 07:11:00 | -08:00:00 | -01:11:00 | >> >> #+TBLFM: $3=$1+$2;T [...] At first I wondered if Calc was treating these numbers as angles (degrees, minutes, seconds) but I really can't explain these results: | Data 1 | Data 2 | Total | |--+--+---| | 00:00:00 | 00:00:00 | 00:00:00 | | 00:00:00 | 00:00:01 | -01:59:59 | | 00:00:00 | 00:00:02 | -01:58:58 | | 00:00:00 | 00:00:03 | -01:59:57 | | 00:00:00 | 00:00:04 | 00:00:00 | | 00:00:00 | 00:00:05 | -01:59:55 | | 00:00:00 | 00:00:06 | -01:58:58 | | 00:00:00 | 00:00:07 | -01:59:53 | | 00:00:00 | 00:00:08 | 00:00:00 | | 00:00:00 | 00:00:09 | -01:59:51 | | 00:00:00 | 00:00:10 | -01:58:58 | | 00:00:00 | 00:00:11 | -01:59:49 | | 00:00:00 | 00:00:12 | 00:00:00 | | 00:00:00 | 00:00:13 | -01:59:47 | | 00:00:00 | 00:00:14 | -01:58:58 | | 00:00:00 | 00:00:15 | -01:59:45 | #+TBLFM: @2$3=$1-$2;T::@3$3=$1-$2;T;@4$3=$1-$2;T::@5$3=$1-$2;T;@6$3=$1-$2;T::@7$3=$1-$2;T;@8$3=$1-$2;T::@9$3=$1-$2;T;@10$3=$1-$2;T::@11$3=$1-$2;T;@12$3=$1-$2;T::@13$3=$1-$2;T;@14$3=$1-$2;T::@15$3=$1-$2;T;@16$3=$1-$2;T::@17$3=$1-$2;T | Data 1 | Data 2 | Total | |--+--+---| | 00:00:00 | 00:00:16 | -01:59:44 | | 00:00:00 | 00:00:17 | -01:59:43 | | 00:00:00 | 00:00:18 | -01:58:58 | | 00:00:00 | 00:00:19 | -01:59:41 | | 00:00:00 | 00:00:20 | 00:00:00 | | 00:00:00 | 00:00:21 | -01:59:39 | | 00:00:00 | 00:00:22 | -01:58:58 | | 00:00:00 | 00:00:23 | -01:59:37 | | 00:00:00 | 00:00:24 | 00:00:00 | | 00:00:00 | 00:00:25 | -01:59:35 | | 00:00:00 | 00:00:26 | -01:58:58 | | 00:00:00 | 00:00:27 | -01:59:33 | | 00:00:00 | 00:00:28 | 00:00:00 | | 00:00:00 | 00:00:29 | -01:59:31 | | 00:00:00 | 00:00:30 | -01:58:58 | | 00:00:00 | 00:00:31 | -01:59:29 | #+TBLFM: @2$3=$1-$2;T::@3$3=$1-$2;T;@4$3=$1-$2;T::@5$3=$1-$2;T;@6$3=$1-$2;T::@7$3=$1-$2;T;@8$3=$1-$2;T::@9$3=$1-$2;T;@10$3=$1-$2;T::@11$3=$1-$2;T;@12$3=$1-$2;T::@13$3=$1-$2;T;@14$3=$1-$2;T::@15$3=$1-$2;T;@16$3=$1-$2;T::@17$3=$1-$2;T | Data 1 | Data 2 | Total | |--+--+---| | 00:00:00 | 00:00:59 | -01:59:01 | | 00:00:00 | 00:01:00 | -01:59:00 | | 00:00:00 | 00:01:01 | -01:58:58 | | 00:00:00 | 00:01:02 | -01:58:58 | | 00:00:00 | 00:01:03 | 00:00:00 | | 00:00:00 | 00:01:04 | -01:58:56 | | 00:00:00 | 00:01:05 | -01:58:58 | | 00:00:00 | 00:01:06 | -01:58:54 | | 00:00:00 | 00:01:07 | 00:00:00 | | 00:00:00 | 00:01:08 | -01:58:52 | | 00:00:00 | 00:01:09 | -01:58:58 | | 00:00:00 | 00:01:10 | -01:58:50 | | 00:00:00 | 00:01:11 | 00:00:00 | | 00:00:00 | 00:01:12 | -01:58:48 | | 00:00:00 | 00:01:13 | -01:58:58 | | 00:00:00 | 00:01:14 | -01:58:46 | #+TBLFM: @2$3=$1-$2;T::@3$3=$1-$2;T;@4$3=$1-$2;T::@5$3=$1-$2;T;@6$3=$1-$2;T::@7$3=$1-$2;T;@8$3=$1-$2;T::@9$3=$1-$2;T;@10$3=$1-$2;T::@11$3=$1-$2;T;@12$3=$1-$2;T::@13$3=$1-$2;T;@14$3=$1-$2;T::@15$3=$1-$2;T;@16$3=$1-$2;T::@17$3=$1-$2;T Best, Martyn
[O] Updating Worg re standard source block syntax
Hi There are literally hundreds of uses of #+srcname and #+source within Worg - should I be updating these to #+name ? In other words, does Worg reflect the last official release (the Emacs release), or the bleeding edge (I tend to assume the latter because of the Org community spirit of Worg), but I fail to find any specific notice regarding this. Advice would be appreciated since I've found myself appreciating, and adding to Worg more and more - and it seems to me it is a real quality of Org that Worg can exist in the first place. Best, Martyn
Re: [O] Bugs in lisp/ob-lilypond.el
Martyn Jago writes: Hi Torsten > Hi Torston > > Torsten Anders 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. (Apologies for miss-spelling your name previously). I'm not seeing this. I've updated my examples to embrace the standard source block syntax, and everything seems to be working for me - which probably means I haven't considered your use-case. I've also moved my ob-lilypond documentation to Worg (but appear to have broken the Worg build mechanism, so that is little help here), but it would be useful to know if the examples at http://github.com/mjago/ob-lilypond/examples work for you. Some more detail would be useful - could you provide: - a broken sample - Emacs version - Lilypond version? Also are you using arrange-mode (C-h v ly-arrange-mode . Nil is no). Regarding the `standard source block syntax', ensure that any #+srcname or #+source commands are replaced with #+name, and update to the very latest Org if you leave space in a `:var something = something-else' assignment as I tend to do. Best, Martyn >>> >>> 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] [ANN] Org Elements in contrib
Nicolas Goaziou writes: Hi Nicolas > Hello, > > > I've added org-element.el in contrib directory. It is a complete parser > and interpreter for Org syntax. > > While it was written to be extensible, it is also an attempt to > normalize current syntax and provide guidance for its evolution. > > Org syntax can be divided into three categories: "Greater elements", > "Elements" and "Objects". > > An object can be defined anywhere on a line. It may span over more than > a line but never contains a blank one. Objects belong to the following > types: `emphasis', `entity', `export-snippet', `footnote-reference', > `inline-babel-call', `inline-src-block', `latex-fragment', `line-break', > `link', `macro', `radio-target', `statistics-cookie', `subscript', > `superscript', `target', `time-stamp' and `verbatim'. > > An element always starts and ends at the beginning of a line. The only > element's type containing objects is called a `paragraph'. Other types > are: `comment', `comment-block', `example-block', `export-block', > `fixed-width', `horizontal-rule', `keyword', `latex-environment', > `babel-call', `property-drawer', `quote-section', `src-block', `table' > and `verse-block'. > > Elements containing paragraphs are called greater elements. Concerned > types are: `center-block', `drawer', `dynamic-block', > `footnote-definition', `headline', `inlinetask', `item', `plain-list', > `quote-block' and `special-block'. > > Greater elements (excepted `headline' and `item' types) and elements > (excepted `keyword', `babel-call', and `property-drawer' types) can have > a fixed set of keywords as attributes. Those are called "affiliated > keywords", to distinguish them from others keywords, which are > full-fledged elements. In particular, the "name" affiliated keyword > allows to label almost any element in an Org buffer. > > Notwithstanding affiliated keywords, each greater element, element and > object has a fixed set of properties attached to it. Among them, three > are shared by all types: `:begin' and `:end', which refer to the > beginning and ending buffer positions of the considered element or > object, and `:post-blank', which holds the number of blank lines, or > white spaces, at its end. > > Some elements also have special properties whose value can hold objects > themselves (i.e. an item tag, an headline name, a table cell). Such > values are called "secondary strings". > > Lisp-wise, an element or an object can be represented as a list. It > follows the pattern (TYPE PROPERTIES CONTENTS), where: TYPE is a symbol > describing the Org element or object. PROPERTIES is the property list > attached to it. See docstring of appropriate parsing function to get an > exhaustive list. CONTENTS is a list of elements, objects or raw strings > contained in the current element or object, when applicable. > > An Org buffer is a nested list of such elements and objects, whose type > is `org-data' and properties is nil. > > The first part of this file implements a parser and an interpreter for > each type of Org syntax. > > The next two parts introduce two accessors and a function retrieving the > smallest element containing point (respectively > `org-element-get-property', `org-element-get-contents' and > `org-element-at-point'). > > The following part creates a fully recursive buffer parser. It also > provides a tool to map a function to elements or objects matching some > criteria in the parse tree. Functions of interest are > `org-element-parse-buffer', `org-element-map' and, to a lesser extent, > `org-element-parse-secondary-string'. > > The penultimate part is the cradle of an interpreter for the obtained > parse tree: `org-element-interpret-data' (and its relative, > `org-element-interpret-secondary'). > > The library ends by furnishing a set of interactive tools for element's > navigation and manipulation. > > More specifically, that last part includes some tools like > `org-element-forward', `org-element-backward', > `org-element-drag-forward', `org-element-drag-backward', > `org-element-mark-element', `org-element-up', > `org-element-unindent-buffer'... > > For the impatient (well, not quite as you're still reading this), you > can evaluate the following examples in an Org buffer : > >(org-element-parse-buffer) > (org-element-parse-buffer 'headline) >(org-element-parse-buffer 'headline 'visible-only) > > Also, the following code will parse the buffer, interpret the parsed > tree, and create a canonical copy of it (no indentation, lowercased > blocks, standard keywords): > > #+begin_src org > (let ((out (org-element-interpret-data (org-element-parse-buffer > (switch-to-buffer (get-buffer-create "*Bijectivep*")) > (erase-buffer) > (insert out) > (goto-char (point-min)) > (org-mode)) > #+end_src > > Beside allowing to add keywords like "#+name:", "#+caption:" or > "#+attr_latex:" to almost any Org element, it also introduces two less > noticable chang
Re: [O] [babel] :var assignment no longer tolerant of whitespace
Eric Schulte writes: Hi Eric > Hi Martyn, > > Tom mentioned this regression earlier and I treated it as a new > restriction on variable specifications, but if multiple people are > running into this issue I suppose spaces around equals should be > supported. > > I have just pushed up a change and a test case ensuring that examples > like yours below will work. > Many thanks Best, Martyn > Cheers -- Eric >
[O] [babel] :var assignment no longer tolerant of whitespace
Martyn Jago writes: (Fixed typos in heading) Hi It used to be the case that you could assign a variable and any whitespace would be chomped: #+begin_src emacs-lisp :var a = 1 :var b = 2 (+ a b) #+end_src However it is now required to remove the whitespace: #+begin_src emacs-lisp :var a=1 :var b=2 (+ a b) #+end_src I haven't noticed any announcement of a change in terms of whitespace use, so I'm mentioning it in case it is actually a regression, or is it by design? If the change has been announced, then I apologize in advance for the noise. Best, Martyn
[O] [babe] :var assignment no longer of tolerant of whitespace
Hi It used to be the case that you could assign a variable and any whitespace would be chomped: --8<---cut here---start->8--- #+begin_src emacs-lisp :var a = 1 :var b = 2 (+ a b) #+end_src --8<---cut here---end--->8--- However it is now required to remove the whitespace: --8<---cut here---start->8--- #+begin_src emacs-lisp :var a=1 :var b=2 (+ a b) #+end_src --8<---cut here---end--->8--- I haven't noticed any announcement of a change in terms of whitespace use, so I'm mentioning it in case it is actually a regression, or is it by design? If the change has been announced, then I apologize in advance for the noise. Best, Martyn
Re: [O] Bugs in lisp/ob-lilypond.el
Hi Torston Torsten Anders 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 >> >> >> >> >> >> >>
Re: [O] Export #+call: within example block
Eric Schulte writes: Thanks Eric - sorted my script. Best, Martyn > Hi Martyn, > > Thanks for pointing out this bug. I've just pushed up a fix and a test > case. > > Cheers -- Eric > > Martyn Jago writes: > >> Hi >> >> Is there a way to export the following, is this a bug, or is there a >> work-around (to HTML)? >> >> >> >> #+begin_example >> >> #+call: rubbish() >> >> #+end_example >> >> >> For instance this exports fine... >> >> >> #+begin_example >> >> #+begin_src emacs-lisp >> >> (some rubbish) >> >> #+end_src >> >> #+end_example >> >> >> Best, Martyn >> >> --- >> Org-mode version 7.7 (release_7.7.571.g0dc50.dirty) >> GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) >> of 2011-08-21 on virtualmac.porkrind.org >> >>
[O] Export #+call: within example block
Hi Is there a way to export the following, is this a bug, or is there a work-around (to HTML)? --8<---cut here---start->8--- #+begin_example #+call: rubbish() #+end_example --8<---cut here---end--->8--- For instance this exports fine... --8<---cut here---start->8--- #+begin_example #+begin_src emacs-lisp (some rubbish) #+end_src #+end_example --8<---cut here---end--->8--- Best, Martyn --- Org-mode version 7.7 (release_7.7.571.g0dc50.dirty) GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of 2011-08-21 on virtualmac.porkrind.org
Re: [O] [bug][babel] #+call: execution broken
Eric Schulte writes: > Martyn Jago writes: > >> Hi >> >> C-c C-c on a #+call: block() statement no longer causes the block to >> execute. >> >> This regression occurred on Nov 8th: >> >> commit a4273cbe0e0480bd02c59464cafb985951b1c5a2 >> Author: Eric Schulte >> Date: Tue Nov 8 19:42:59 2011 -0700 >> call lines are more careful about being in example or verbatim blocks >> >> I've supplied a patch which provides a couple of failing tests which >> highlight the problem. >> > > Hi Martyn, > > The reason that your tests are failing is because they use the old > "#+srcname:" rather than the new "#+name:" syntax for naming a code > block. > > After making this change both tests pass. > Doh! Clearly I need to keep up with the times. Best, Martyn
[O] [bug][babel] #+call: execution broken
Hi C-c C-c on a #+call: block() statement no longer causes the block to execute. This regression occurred on Nov 8th: commit a4273cbe0e0480bd02c59464cafb985951b1c5a2 Author: Eric Schulte Date: Tue Nov 8 19:42:59 2011 -0700 call lines are more careful about being in example or verbatim blocks I've supplied a patch which provides a couple of failing tests which highlight the problem. Best, Martyn >From 68a64d29222548eff3f414b8881f583f50ea4a96 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Thu, 17 Nov 2011 12:33:08 + Subject: [PATCH] Tests for testing basic `#+call: block-name()' actually cause block execution * testing/lisp/test-ob.el: --- testing/lisp/test-ob.el | 38 ++ 1 files changed, 38 insertions(+), 0 deletions(-) diff --git a/testing/lisp/test-ob.el b/testing/lisp/test-ob.el index d145f4e..3fefe91 100644 --- a/testing/lisp/test-ob.el +++ b/testing/lisp/test-ob.el @@ -499,4 +499,42 @@ on two lines (provide 'test-ob) +(ert-deftest test-org-babel/basic-call-execution-bol() +"Test that executing #+call: with point on # executes the block" + (org-test-with-temp-text + " +#+call: my-test() +#+srcname: my-test +#+begin_src emacs-lisp + (+ 2 3) +#+end_src " + + (should (search-forward "#+call:")) + (beginning-of-line) + (org-ctrl-c-ctrl-c) + (should (search-forward "#+results: my-test()")) + (forward-line) + (should (string= ": 5" + (buffer-substring-no-properties + (point-at-bol) (point-at-eol)) + +(ert-deftest test-org-babel/basic-call-execution-eol() +"Test that executing #+call: with point at eol executes the block" + (org-test-with-temp-text + " +#+call: my-test() +#+srcname: my-test +#+begin_src emacs-lisp + (* 2 3) +#+end_src " + + (should (search-forward "#+call:")) + (end-of-line) + (org-ctrl-c-ctrl-c) + (should (search-forward "#+results: my-test()")) + (forward-line) + (should (string= ": 6" + (buffer-substring-no-properties + (point-at-bol) (point-at-eol)) + ;;; test-ob ends here -- 1.7.3.4
Re: [O] [bug] regression tests broken
Hi Eric Eric Schulte writes: [...] > This sounds like a very nice setup. It would be great if you can work > with me and Jason to see if we can set this up on the Org-mode server. No problem. If it is a Linux server, I can work on setting up a fresh instance on Linux prior the actual deployment (currently on OSX). Best, Martyn > Thanks -- Eric > >> >> Best Martyn >> >>> Thanks -- Eric >>> >>> Martyn Jago writes: >>> >>>> Hi >>>> >>>> All automated regression tests broken since 7720786 commit >>>> >>>> http://martynjago.com: >>>> >>>> Best, Martyn >>>> >>>> >> >>
Re: [O] [bug] regression tests broken
Hi Eric Oops, the patch was broken - this one fixes the problem... [...] > Currently `org-test-load' will happily attempt to load an interlocking > symbolic link (such as .#test-ob-exp.el -> > martyn@88-96-171-138.59787). This results in a failure to run any tests, > and is particularly annoying during test development. Below is a patch > that fixes this problem for me. > >From b868e208dd3ece7c10818ed73f2cf0dc86dac94b Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Sun, 13 Nov 2011 16:03:51 + Subject: [PATCH] Fix don't load symlinks (Emacs interlocking files) * testing/org-test.el: During test development various interlocking files may be present in testing/lisp directory (since they are being edited by emacs). Currently org-test-load will attempt to load these --- testing/org-test.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/testing/org-test.el b/testing/org-test.el index ea8cae4..7d2f7e7 100644 --- a/testing/org-test.el +++ b/testing/org-test.el @@ -276,8 +276,9 @@ otherwise place the point at the beginning of the inserted text." (if (file-directory-p path) (rld path) (catch 'missing-test-dependency - (when (string-match "^[A-Za-z].*\\.el$" path) - load-file path + (when (string-match "^[A-Za-z].*\\.el$" + (file-name-nondirectory path)) + (load-file path) (directory-files base 'full "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*\\.el$" (rld (expand-file-name "lisp" org-test-dir)) -- 1.7.3.4 Best, Martyn [...]
Re: [O] [bug] regression tests broken
Martyn Jago writes: Hi Eric [...] Further to the problem of tests failing under sandboxed conditions unexpectedly, I've made a few observations which I want to pass on. * ID Currently the ID searching command `org-id-find' has global scope to find ID's all over the host system. Since developers frequently have > 1 Orgs on their system, this can lead to confusion. For instance, the test `ob-C/table' in in test-ob-C.el appears to contain an orphan ID, which fails, but may well pass on the devs system, since the ID probably exists somewhere (does this test also require to be called test-ob-C/table)?. Unfortunately `org-id-find' seems to be heavily dependent on org-mode.el forms, and I suspect it would require a lot of time for me to attempt to restrict it's scope to `the current Org system in use, so I will leave it to someone with more experience. Another by-product is that sandboxed test systems are not guaranteed to pick up the _correct_ file containing the search ID (this plagued me this-morning). * `org-test-load' attempts to load symlinks (Emacs interlocking files). Currently `org-test-load' will happily attempt to load an interlocking symbolic link (such as .#test-ob-exp.el -> martyn@88-96-171-138.59787). This results in a failure to run any tests, and is particularly annoying during test development. Below is a patch that fixes this problem for me. >From 04dd7358295caef0d42a3fe93f4979ccd3b5c630 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Sun, 13 Nov 2011 14:43:34 + Subject: [PATCH] Avoid loading (and failing) symbolic links (interlocking files) * testing/org-test.el: During test development various interlocking files may be present in testing/lisp directory (since they are being edited by emacs). Currently org-test-load will attempt to load these and fail. --- testing/org-test.el |5 +++-- 1 files changed, 3 insertions(+), 2 deletions(-) diff --git a/testing/org-test.el b/testing/org-test.el index 57b7252..ea8cae4 100644 --- a/testing/org-test.el +++ b/testing/org-test.el @@ -274,9 +274,10 @@ otherwise place the point at the beginning of the inserted text." (mapc (lambda (path) (if (file-directory-p path) - (rld path) + (rld path) (catch 'missing-test-dependency - (load-file path + (when (string-match "^[A-Za-z].*\\.el$" path) + load-file path (directory-files base 'full "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*\\.el$" (rld (expand-file-name "lisp" org-test-dir)) -- 1.7.3.4 I'm still looking at a potential variable passing problem during html export by inline calls, and will submit something as soon as I can. Best, Martyn
Re: [O] [bug] regression tests broken
Hi Eric Eric Schulte writes: > Hi Martyn, > > I have all tests passing in a branch in the Org-mode git repo (which I > plan to merge into master soon). Could you try a run of this on the > standard-code-block-syntax branch? I've added the standard-code-block-syntax branch to my test server, and have configured notification so that you will be informed via email on failure. Unfortunately, the branch is currently failing, as are all other builds including my test-branch. I will try to take a look tomorrow on why three tests are failing. > As a side note, how automated is your crusecontrol.rb setup? Would you > recommend this as a way to run automated tests on the Org-mode server > after every git commit? It is completely autonomous, git-pulling, cleaning, building, building docs, and running tests within 10 minutes or so of a fresh commit to the Org repository. Builds are serialized. I would certainly recommend it as an easy way of setting up a test server, since everything you need is built-in, such as email notification (notifying the list is of course a possibility), RSS, and rapid backtrace investigation etc. I have come across other gnu projects that use cruisecontrolrb. Your server would need Ruby installed (I use v1.9.2), but installation should be straight-forward since I have already written the scripts, which is fairly simple anyway. Hope that helps Best Martyn > Thanks -- Eric > > Martyn Jago writes: > >> Hi >> >> All automated regression tests broken since 7720786 commit >> >> http://martynjago.com: >> >> Best, Martyn >> >>
[O] [bug] regression tests broken
Hi All automated regression tests broken since 7720786 commit http://martynjago.com: Best, Martyn
Re: [O] [test] Failure on GNU Emacs 22.3.2 (i686-pc-linux-gnu) of 2011-05-28 on x60s
David Maus writes: > Running the test suit on > > GNU Emacs 22.3.2 (i686-pc-linux-gnu) of 2011-05-28 on x60s > > currently fails with the backtrace below. > > Somehwere/somehow Babel ends up calling `member' with the second > argument not being a list. In Emacs22 this triggers an error, but not > so in Emacs23 and upwards. > > Devs don't consider this a bug: > > http://debbugs.gnu.org/cgi/bugreport.cgi?bug=264 > > Best, > -- David > [...] Hi David I don't actually see this on my continuous test server, although I did see regression on 29th October which appeared to be fixed the same day ( see http://martynjago.co.uk:/builds/org-mode_Emacs_22 ). Personally I've pretty much given up even monitoring such things since there seems to be such little appetite by most of the maintainers to test anything, or even to run tests, or monitor test results. From my experience, threads like this tend to go unanswered. Best, Martyn
Re: [O] FYI: Org mode testing framework, Emacs 23 and 22
Hi Brian Wightman writes: > On Mon, Oct 24, 2011 at 7:12 AM, Sebastien Vauban > wrote: >> For my information, why do you need to test that 2 suites don't run at the >> same time? They only write to temp buffers, no? Can they conflict? > > If they do conflict and only one set of tests should run at a time, > shouldn't the second set of tests be queued up so it runs when the > first is complete? If this isn't done, I could see a situation where > at least one commit remains untested until the next commit. > > my $0.02; > Brian I would think it would make sense to ensure the newly committed code also builds correctly (including info), and why not test back to Emacs 22 also (since that is how this thread came about)? I have set up something similar, and doing all this takes less than 1 minute on my machine. Incidentally, I added info on running tests on Emacs 22 and 23 to Worg at http://orgmode.org/worg/org-tests/index.html Best, Martyn
Re: [O] [RFC] Standardized code block keywords
Nick Dokos writes: > Eric Schulte wrote: > >> Surprisingly (to me) srcname is the winner here, but luckily I haven't >> yet voted, and although I would have though #+source: would have been >> the winner I like the simplicity of using #+name: for named code blocks >> as well as named data. So I'll vote for #+name: here making it a tie, >> and I'll also take tie-breaking powers upon myself giving #+name: the >> win. >> > > This is going to cost you, Schulte! It's not going to go down that easily. > I'll call the FTC, the FCC, the SCOTUS, the POTUS, the NYT, the BDFL, the > NFL and the MLB: an outrage I tell you! An affront to the democratic rules > some of us cherish! We'll fight to the death! Who's with me? +1 #+name mj
Re: [O] GNU Emacs crashing on large Orgmode files
Hi Karl Karl Voit writes: > * Marcelo de Moraes Serpa wrote: >> >> Hi list, > > Hi individual! > >> I love org and I think there's nothing like it out there, > > Ack! > >> but I'm considering using Evernote for reference notes, because my >> reference.orgfile has grown too big (4234k + lines). This makes >> the rendering of the file way too slow, and 2 times out of 10 >> emacs crashes because of that. > > Not exactly the topic you mentioned but as a side mark to crashes on > Mac OS X I want to add: > > I am trying to implement life-logging [1] with Org-mode and GNU > Emacs. Therefore I created [2]. Even in this early stage, it ends up > with >150.000 lines in approx. 30 Org-mode files. Most of them are > in «*.org_archive» files though. (Further performance information: > [3]) > > On my notebook I am using GNU Linux (Ubuntu 11.04) with GNU Emacs > 23.2.1 (i686-pc-linux-gnu, GTK+ Version 2.24.4). At home I've got > Mac OS X 10.5 with http://emacsformacosx.com/ (sorry, no detailed > version number since I am currently sitting in my office *g*). > > I never noticed *any* crash of Emacs using Org-mode on my Linux > machine. But on my OS X box, I notice crashes many times. Mostly > when navigating (vertically or horizontally) in the Agenda view. > > Maybe there is an (hidden?) issue with GNU Emacs on OS X (too). > Just for your information I use emacsformacosx port on Mac OS X 10.6.8, currently GNU Emacs 24.0.50.1 with 2GB RAM and 2.4GHz. On larger org files (over 13000 lines) navigation slows considerably, but I have never had Emacs crash, despite fairly heavy usage. However, I tend to maintain fairly compact files, through archiving. > 1. http://en.wikipedia.org/wiki/Lifelogging > 2. https://github.com/novoid/Memacs > 3. https://github.com/novoid/Memacs/blob/master/FAQs_and_Best_Practices.org mj --- Org-mode version 7.7 (release_7.7.359.g18e67) GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of 2011-08-21 on virtualmac.porkrind.org
[O] [patch][babel] Patch to fix regression (commit 53573d6)
Hi Patch to fix regression caused by commit 53573d6 (lisp/ob-shen.el causes isolated tests to fail). See http://martynjago.com:/ Best, Martyn >From 18e67dae6ac7c9ec8bfee9d53358e379b0e1ece1 Mon Sep 17 00:00:00 2001 From: Martyn Jago Date: Fri, 7 Oct 2011 15:37:02 +0100 Subject: [PATCH] Fix regression caused by commit 53573d6 * lisp/ob-shen.el: autoload `inf-shen' --- lisp/ob-shen.el |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lisp/ob-shen.el b/lisp/ob-shen.el index 123e39e..6131b8e 100644 --- a/lisp/ob-shen.el +++ b/lisp/ob-shen.el @@ -34,7 +34,7 @@ ;;; Code: (require 'ob) -(require 'inf-shen) +(autoload 'inf-shen "inf-shen.el") (defvar org-babel-default-header-args:shen '() "Default header arguments for shen code blocks.") -- 1.7.3.4 --- Org-mode version 7.7 (release_7.7.359.g18e67) GNU Emacs 24.0.50.1 (x86_64-apple-darwin, NS apple-appkit-1038.35) of 2011-08-21 on virtualmac.porkrind.org
Re: [O] Registration for Worg commit access
Hi Jason Jason Dunsmore writes: > Martyn Jago writes: > >> Hi >> >> Would it be possible for someone to provide we with commit access to >> Worg? > > Hi Martyn, > > Here are the instructions for contributing to Worg: > http://orgmode.org/worg/worg-git.html#contribute-to-worg > > Did you email Matt? > > Regards, > Jason This is now sorted - may thanks Matt. Best, Martyn
[O] Registration for Worg commit access
Hi Would it be possible for someone to provide we with commit access to Worg? I'm adding and updating documentation for various testing activities. I've registered with repo.org.cz and added my key user name: mjago Best, Martyn
Re: [O] [babel] BUG in :session
Hi Sebastien "Sebastien Vauban" writes: > Hi Martyn and Eric, > > Martyn Jago wrote: >> Eric Schulte writes: >>> Martyn Jago writes: >>>> Eric Schulte writes: >>>>> I've just pushed up what will hopefully be a more general solution. >>>>> Basically, language-specific test files can now signal errors if they >>>>> have unmet dependencies. These are then intercepted by `org-test-load' >>>>> and the file is not added to the test suite. Hopefully this will allow >>>>> language-specific tests to be written without breaking the config-less >>>>> test suite. >>>>> >>>>> See the top of test-ob-R.el for an example usage. >>>>> >>>>> Cheers -- Eric >>>> >>>> Unfortunately this is still broken for me. Given the exe exists but the >>>> feature doesn't (ie no personal config), the following line causes the >>>> error `peculiar error' ! >>>> >>>>(signal 'org-test-lib-not-found "ess")) > > FYI, same for me, with the "batch tests", on a git update'd copy done 2 mins > ago. > > #+begin_src sh > emacs -Q --batch -l "/cygdrive/c/Program > Files/Emacs-24.0/lisp/emacs-lisp/ert.el" -l "/cygdrive/c/Program > Files/Emacs-24.0/lisp/emacs-lisp/ert-x.el" -l > ~/src/org-mode/testing/org-test.el --eval "(setq org-confirm-babel-evaluate > nil)" -f org-test-run-batch-tests > #+end_src > > #+results: > OVERVIEW > Loading vc-git... > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > OVERVIEW > Loading /cygdrive/c/home/sva/src/org-mode/testing/lisp/test-ob-R.el > (source)... > peculiar error > > This is on Windows XP SP3, with a Cygwin Emacs (when run from terminal; > otherwise, it is a Win32 binary from the FSF). > Its really great to hear you are running the tests on Windows. At some point I hope to test with the EmacsW32 port. Best, Martyn
Re: [O] [babel] BUG in :session
Hi Eric Eric Schulte writes: > Martyn Jago writes: > >> Hi Eric >> >> Eric Schulte writes: >> >>> Martyn Jago writes: >>> >>>> Hi Eric >>>> >>>> Eric Schulte writes: >>>> >>>>> Hi Martyn, >>>>> >>>>> I've just pushed up what will hopefully be a more general solution. >>>>> Basically, language-specific test files can now signal errors if they >>>>> have unmet dependencies. These are then intercepted by `org-test-load' >>>>> and the file is not added to the test suite. Hopefully this will allow >>>>> language-specific tests to be written without breaking the config-less >>>>> test suite. >>>>> >>>>> See the top of test-ob-R.el for an example usage. >>>>> >>>>> Cheers -- Eric >>>> >>>> Unfortunately this is still broken for me. Given the exe exists but the >>>> feature doesn't (ie no personal config), the following line causes the >>>> error `peculiar error' ! >>>> >>>>(signal 'org-test-lib-not-found "ess")) >>>> >>> >>> Oh, >>> >>> I forgot to update the types of errors that I am catching after adding a >>> new error type for missing libraries (e.g., ess). This should now be >>> fixed. >>> >> >> There still seems to be a problem with test-ob-R - same error "peculiar >> error". >> > > OK, I see this error as well. I've switched from using errors to signal > a missing dependency to using catch/throw blocks. This seems to > actually work, hopefully the test suite should now run w/o error. > This now works great for me. >> >>> >>> Is there a way to see the output of the test run, all I can find is the >>> command which is executed. >> >> Yes - just click on the org-mode_Emacs_24 (title) link and then on the >> build log link. There isn't much of a log on the failing tests since >> the entire test run is broken by the signal. >> >> You can checkout the build log for my-org-mode-dev to see what you >> should get. >> > > Great, doing this I can see that everything is now running successfully > http://martynjago.com:/builds/org-mode_Emacs_24/4446e50/build.log > > Very nice system, I wonder if we could run something like this on the > Org-mode server. It should be fairly easy to set up a similar system on the Org-mode server, and very useful I would have thought. I agree it is a very useful system and have used it several times on other projects. Best, Martyn
Re: [O] [PATCH] Modifications to enable test script to run with emacs-23 and emacs-22
Hi David David Maus writes: > Hi Eric, > Hi Martyn, > > At Tue, 20 Sep 2011 09:03:27 -0600, > Eric Schulte wrote: >> >> Applied, Thanks! -- Eric > > I noticed that newlines in the commit messages of patches by Martyn > are somehow messed up: > > , > | Modifications to enable test script to run with emacs-23 and > emacs-22 * testing/org-test.el: enable test script to run with > emacs-23 and emacs-22 * testing/lisp/test-org-exp.el: added org-ascii > requirement > ` I too have noticed this - I generate the commit message in magit and generate the patch with git format-patch, and at that point newlines still appear to be honoured here. I then attach the patch inline to gnus. Any solutions welcome. Best, Martyn
Re: [O] [babel] BUG in :session
Hi Eric Eric Schulte writes: > Martyn Jago writes: > >> Hi Eric >> >> Eric Schulte writes: >> >>> Hi Martyn, >>> >>> I've just pushed up what will hopefully be a more general solution. >>> Basically, language-specific test files can now signal errors if they >>> have unmet dependencies. These are then intercepted by `org-test-load' >>> and the file is not added to the test suite. Hopefully this will allow >>> language-specific tests to be written without breaking the config-less >>> test suite. >>> >>> See the top of test-ob-R.el for an example usage. >>> >>> Cheers -- Eric >> >> Unfortunately this is still broken for me. Given the exe exists but the >> feature doesn't (ie no personal config), the following line causes the >> error `peculiar error' ! >> >>(signal 'org-test-lib-not-found "ess")) >> > > Oh, > > I forgot to update the types of errors that I am catching after adding a > new error type for missing libraries (e.g., ess). This should now be > fixed. > There still seems to be a problem with test-ob-R - same error "peculiar error". >> >> I've published the output of my test server so you can see the >> backtrace. It is at http://martynjago.com: >> > > Very cool, > > Does this page refresh after every git commit? Yes - the repository is polled once per minute and a git pull + make clean / install etc + run tests is performed, so the test server now reflects your latest commit. > > Is there a way to see the output of the test run, all I can find is the > command which is executed. Yes - just click on the org-mode_Emacs_24 (title) link and then on the build log link. There isn't much of a log on the failing tests since the entire test run is broken by the signal. You can checkout the build log for my-org-mode-dev to see what you should get. Best, Martyn > > Cheers -- Eric > >> >> Best, Martyn >> >> >> [...] >> >> >>
