[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 martyn.j...@btinternet.com 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))) - '(head /head body - code:noweb/code header argument expansion - code:noweb/code header argument expansion + '(code:noweb/code header argument expansion message expanded1 message expanded2 noweb-1-yes-start @@ -99,8 +97,7 @@ message expanded2 noweb-tangle-start lt;lt;noweb-example1gt;gt; - lt;lt;noweb-example2gt;gt; - /body)) + lt;lt;noweb-example2gt;gt;)) (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))) - '(head /head body - code:noweb/code header argument expansion using :exports results - code:noweb/code header argument expansion using :exports results + '(code:noweb/code header argument expansion using :exports results expanded1 expanded2 expanded1 @@ -133,8 +128,7 @@ lt;lt;noweb-example1gt;gt; expanded2 lt;lt;noweb-example1gt;gt; - lt;lt;noweb-example2gt;gt; - /body)) + lt;lt;noweb-example2gt;gt;)) (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))) - '(head /head body - Pascal's Triangle ndash; exports both test - Pascal's Triangle ndash; exports both test + '( Pascal's Triangle ndash; exports both test pre defun pascals-triangle iflistlistlet*prev-triangle @@ -173,14 +164,13 @@ elements in the final html. tr1331/tr tr14641/tr tr15101051/tr - /tbody/table - /body)) + /tbody/table)) (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))) - '(head /head body - mixed blocks with exports both - mixed blocks with exports both + '(mixed blocks with exports both ul lia/li lib/li @@ -205,9 +193,9 @@ elements in the final html. /pre pre class=\example\ code block results - /pre - /body)) - + /pre)) + (provide 'test-ob-exp) ;;; test-ob-exp.el ends here + -- 1.7.3.4
Re: [O] capture problem
Hi Thomas, Thomas S. Dye wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com writes: Thomas S. Dye wrote: I'm sometimes running into this error message when I capture: condition-case: Capture abort: (quit pasteboard doesn't contain valid data) Unfortunately, this doesn't mean anything to me. The problem arises after I've been working for a while, but I haven't an idea why it starts, or any clue to what might trigger it. I realize this isn't much to go on, and a long way from an ECM, but I don't know what to do. Any ideas on how to track this down will be appreciated. I'm using Org-mode version 7.8.02 (release_7.8.02.13.g0c09a.dirty). Yesterday, with yesterday's update, I've as well have had something similar: capture refused to work, after well having worked previously -- in the same Emacs instance --, and launched me a cryptic reason. Though, the reason was not the same as yours. Maybe because I'm on Windows? Anyway, I should have noted down the message. I just restarted Emacs then, and did not experience any other problem with the capture process. I'll keep you posted otherwise. I'm still running into this error. I've found that I don't have to stop emacs and restart. All I have to do is copy a bit of text and then run capture. This seems to work every time. Presumably, the text copy causes the pasteboard to contain valid data. I still don't know how the pasteboard gets invalid data in the first place. FYI, I never got that problem again... and I'm still capture, not particularly less or more than before. I don't know what that means... The fact is that I'm updating Org every day or so. Could it have been fixed in the meanwhile? Do you update that often as well? Best regards, Seb -- Sebastien Vauban
Re: [O] [patch][babel] Fix latest block export tests to suit Emacs 22
Martyn Jago martyn.j...@btinternet.com 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! -- Bastien
Re: [O] protect slash - suppress markup
Thanks a lot! Lasse Am 05.01.2012 um 16:49 schrieb Bernt Hansen: Carson Chittom car...@wistly.net writes: Bernt Hansen be...@norang.ca writes: Lasse Bombien la...@phonetik.uni-muenchen.de writes: Hi, first of all: thanks for org-mode. I'm still new to it but love it already. Now, I need to find a way to produce sentences like The phonemes /l/ and /n/ … in my exported documents. However, org-mode of course transforms strings enclosed in slashes to emphasized text. This is usually great, but in my area slashes are used as brackets for phonological transcripts. Is there a way to locally suppress slashes from being interpreted as markup characters (I tried backslashing and double slashes…) or an entirely different way to accomplish this (I tried: #+MACRO: phonem /$1/ …)? I looked in the manual and the list archive but could find anything. If I missed something, I apologize. During export you can turn this off #+OPTIONS: *:nil But wouldn't that turn off, for example, *bolding* also? Yes it would. See Nick's answer about org-emphasis-alist. Regards, Bernt
Re: [O] Agenda buffer and relative links
Nick Dokos nicholas.do...@hp.com writes: François Pinard pin...@iro.umontreal.ca wrote: When Org mode defines a link for me, it sometimes changes it so it becomes relative. [...] This is OK in general, but not always. [...] I have feeling that there is something deeper which might likely affect many Org mode users, and for which I have no general solution to offer. Check (info (org) Handling links) in the manual, particularly the doc for C-u C-c C-l. Hi, Nick, and gang. Yes, I knew about prefixes to C-c C-l, which may be used to force links to be absolute. Systematic use of C-u C-u C-c C-l instead of C-c C-l would be tedious, that's why I think there is a deeper problem about the current defaults. There is a virtue in relative links which I recognize. So having an option to force all links to be absolute might not be a solution. Having all links relative just cannot work. Letting the user properly manage is quite error-prone, and fairly annoying at least. If you put a gun on my head and say suggest something, without much time to think, I would go something that way: * cutting part of a buffer containing links, links should be turned absolute before going in the clipboard or kill ring, * pasting text containing links, links should be turned relative whenever it makes sense to do so. What is making sense, above? * if a file receiving the link is not part of the agenda files, the current algorithm is OK, * if a file receiving the link is part of the agenda files, and that agenda file is directly under org-directory, the current algorithm is OK, * if a file receiving the link is part of the agenda files, and that agenda file is not directly under org-directory, make the link absolute, This would have consequences: * the agenda buffer should automatically be cd'ed to org-directory, * adding (removing) a file to (from) the list of agenda-files becomes a complex operation, requiring all links to be adjusted. All of the above is surely very debatable, and other people may likely devise other approaches. That's why I say it may require deeper thought. I would only like to stress that there is a problem. François P.S. I have lot of links, and I often move contents around in files. Adjusting links while doing so has been a bit painful all along. So far, I used mixes of Python scripts, editionswith Vim, or sometimes editions with Emacs in fundamental mode. And I wrote a cross-checking and diagnosis tool which I run at least daily, at backup time.
Re: [O] Agenda buffer and relative links
Hi François, François Pinard wrote: Nick Dokos nicholas.do...@hp.com writes: François Pinard pin...@iro.umontreal.ca wrote: When Org mode defines a link for me, it sometimes changes it so it becomes relative. [...] This is OK in general, but not always. [...] I have feeling that there is something deeper which might likely affect many Org mode users, and for which I have no general solution to offer. Check (info (org) Handling links) in the manual, particularly the doc for C-u C-c C-l. Hi, Nick, and gang. Yes, I knew about prefixes to C-c C-l, which may be used to force links to be absolute. Systematic use of C-u C-u C-c C-l instead of C-c C-l would be tedious, that's why I think there is a deeper problem about the current defaults. There is a virtue in relative links which I recognize. So having an option to force all links to be absolute might not be a solution. Having all links relative just cannot work. Letting the user properly manage is quite error-prone, and fairly annoying at least. Would this help you? ┏ ┃ org-link-file-path-type is a variable defined in `org.el'. ┃ Its value is adaptive ┃ ┃ Documentation: ┃ How the path name in file links should be stored. ┃ Valid values are: ┃ ┃ relative Relative to the current directory, i.e. the directory of the file ┃ into which the link is being inserted. ┃ absolute Absolute path, if possible with ~ for home directory. ┃ noabbrev Absolute path, no abbreviation of home directory. ┃ adaptive Use relative path for files in the current directory and sub- ┃ directories of it. For other files, use an absolute path. ┗ Best regards, Seb -- Sebastien Vauban
Re: [O] [bug] Invalid face when exporting code block to HTML
Hi Nick, Nick Dokos wrote: Sebastien Vauban wxhgmqzgw...@spammotel.com wrote: Quite simple: the following block generates an Invalid face error when exported to HTML. #+begin_src sh svn checkout http://svn/trunk/dev/ mydev #+end_src This worked yesterday. Does it ring a bell to someone? Could some recent commit be responsible of this? Can't reproduce it either with a slightly earlier version of org (.19) or latest (.44 - note that I'm ahead of origin/master by 3 commits). Try evaluating this expression which is the one that gave you the error: (htmlize-face-size 'default) I get 113 in my setup, so this looks like an htmlize error. Indeed: #+begin_src emacs-lisp Debugger entered--Lisp error: (void-function htmlize-face-size) (htmlize-face-size (quote default)) eval((htmlize-face-size (quote default)) nil) eval-last-sexp-1(nil) eval-last-sexp(nil) call-interactively(eval-last-sexp nil nil) #+end_src I don't understand where the nil face (which is indeed invalid) comes from. Also htmlize-face-size wraps the face-attribute call inside an (ignore-errors ...) form, so it should *not* blow up. I don't understand, as I did not do any Emacs changes lately in that area. Are you using some old outdated htmlize code by any chance? Library is file `~/Downloads/emacs/site-lisp/htmlize.el', where I have all independent package files downloaded from the Web. Wait... That should be `~/src/org-mode/contrib/lisp/htmlize.el', right? So, I have 2 `htmlize' files, and the Org-compliant one is only located in the second best place. I have -- still! -- absolutely no idea why the original `htmlize' file worked for me so far, and why it suddenly stopped working yesterday (I did no change of load-paths, neither did I save that file there... it must be a very old reminiscence). I still have found out that -- with the original (non-Org) `htmlize' file --, I need to have a declaration like this: #+begin_src emacs-lisp (default ((t (nil #+end_src in my color theme. With the Org flavor of `htmlize', that line is not needed. For sure, yesterday, I played with that line, *after* things had gone wrong, as I wondered whether such a line, with `nil', was good or not to have. Now, there are 2 ways to solve my problem for sure: - putting the original `htmlize' after the Org paths, - removing it. The first solution does not feel natural to me: I need having the proper load-paths set up for Org in my stub .emacs (calling my tangled, huge file full of Emacs customizations). It's because ~/Downloads/emacs/site-lisp/ is added to the load-path in that huge .emacs file that it's finally in front of Org git directories, as the append is done upfront -- no prepend. Now, I really don't need to have conflicting versions of `htmlize', so I simply deleted that file -- whose I ignored the existence up to now --, and all is so far so good. Thanks (a lot) for putting me right on track! Best regards, Seb -- Sebastien Vauban
Re: [O] About headlines, checkboxes and heritage
Hello, Ab Cd nati_...@yahoo.fr writes: Please consider the following file : * TODO working ** TODO 1st part of the work CLOCK: [2012-01-05 jeu. 17:18] ** TODO second part of the work [0/3] - [ ] Task 1 - [ ] Subtask 1 - [ ] Subtask 2 - [ ] Subtask 3 - [ ] Task 2 - [ ] Task 3 But why shoudln't a TODO headline containing only checkbox that are all completed ([3/3] in this case) be switched to done? Because lists and headlines are mostly unrelated. There's no particular reason that completing all tasks from the list should end the second part of the work. There might be some things left to be done, like writing a report... many things that Org can't guess. It's up to the user to tell when it is appropriate to close the task. Now, if the automatic closing of tasks fits your needs, you can make it possible with an appropriate value for `org-checkbox-statistics-hook'. Also, why can't I toggle Task 1 ? Let's assume I was away from my computer when completing some or all of the subtasks. I would really like to check Task 1 and have all the Subtasks checked automatically. Mark region between Task 1 and Subtask 3, then use C-c C-x C-b One last thing. I also think I would be nice that, if I switch second part of the work to DONE, the counter would be set to [3/3] and all the tasks and subtasks be checked as done. You want to treat lists as lesser headlines, which they are not. At least by default. Though, you can use `org-after-todo-state-change-hook' to call, each time a state change to a done-like keyword, `org-toggle-checkbox' on the headline (provided the first check-box in the section is unchecked). Regards, -- Nicolas Goaziou
Re: [O] org-jira.el
Hi Jonathan, Jonathan Arkell jonath...@criticalmass.com writes: Wow Bao! I am just checking out your org-jira2 project right now... Your thing was what my thing (contrib/lisp/org-jira.el) was going to become when I got the time... Then I got put on a project that didn't use Jira, and abandoned it (as mentioned earlier). So yea, Bastien, Bao, and anyone else for that matter, go ahead and do what you like with that trivial piece of code. Rename it, delete it, fold it into the new library. I have merged it. Now the jira link type will be opened by org-jira-mode, jumping (retieving first if not done already) to the org heading tracking the issue specified in the link. By the way, do you mind if I keep using the name org-jira.el? org-jira2 is not a good name just as jira2 is not. Thanks. -- All the best Bao Haojun
Re: [O] org-jira.el
Hi, OSiUX OSiUX xu...@osiux.com.ar writes: El lun, 02 ene 2012, Bao Haojun decía: Hi, all I have implemented org-jira.el, bringing org-mode and Jira system together. Wrote a Wiki page for it on emacswiki: http://www.emacswiki.org/emacs/OrgJiraMode Hope somebody find it useful, if he/she is also using Jira and loves org-mode. after running Mx jira2-login, I get the following error: Symbol's function definition is void: auth-source-search howto configure login? I have fixed it. The auth-source-search is a new API from emacs24. With the new code, you will be prompted for username and password if you are using a lower version of EMACS. BTW, I have also renamed jira2 to jiralib, so after you check out the new code, you need change your .emacs accordingly: #+begin_src emacs-lisp (setq jiralib-url http://jira-host;) (require 'org-jira) ;jiralib is not explicitly required, since org-jira will load it #+end_src Thanks. -- All the best Bao Haojun
[O] org-jira.el updated
Hi, all I have updated the org-jira.el as suggested by Bastien and Richard Riley: - Renamed jira2 to jiralib, to avoid confusion with the '2' and add the note that it is a library (I looked to merge with jira.el, but backed off as I myself do not use jira-mode). - Fixed a bug for emacs version 23 when login. - Merged the jira link type by Jonathan Arkell. As a result, a minor change to installation in .emacs (emacswiki updated): #+begin_src emacs-lisp (setq jiralib-url http://jira-host;) (require 'org-jira) ;jiralib is not explicitly required, since org-jira will load it #+end_src -- All the best Bao Haojun
[O] How to force redisplay?
Hi, Org people. There is a little problem I often observed, about bad vertical alignment of text in Org mode buffers. Let me try to illustrate by mimicking from an example right out from the window I currently see ;-). Ellipses [...] have been added to make the example shorter. - [...] * TODO Obstacles technologiques... * Approche /Modèle Vue Contrôleur/ L'outil utilise une approche /Modèle Vue Contrôleur/, dans [...] combler le manque d'appariement d'impédance. * Identification du Modèle La traduction automatique des processus [...] éléments de disposition. En toute première analyse, il avait donc été déterminé [...] trouver autre chose. Nous avons finalement retenu l'approche suivante. [...] qui servent de données. * Détermination des Vues [...] - You see, paragraphs La traduction et En toute première analyse are not indented enough, they should be two columns more to the right. While this happens to me fairly regularly, I did not identify yet a recipe for reproducing it at will. I presume I'm not the only one having this problem at times, am I? So, my real question : is there a quick way to correct the indentation? Currently, I go up one level, shift right (org-shiftmetaright) then shift left (org-shiftmetaleft), and that does it. But I find these operations a bit disrupting. Is there a faster, simpler way? François
Re: [O] org-jira.el updated
Bao Haojun baohaojun at gmail.com writes: I have updated the org-jira.el as suggested by Bastien and Richard Riley: Amazing. Just 120 seconds ago I got out of a meeting where we talked about using Jira more widely in our company, and I worried that I'd duplicate too much between my org-mode journals and the Jira tracker. Then I go look at the org-mode list and this is the first message I see. =) I'm going to need to upgrade to org-mode 7.8 and try this out. -Ken
Re: [O] [patch][test] Avoid writes to non-temp test-example files
Achim Gratz strom...@nexgo.de 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. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ SD adaptation for Waldorf Blofeld V1.15B11: http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
Re: [O] Gnuplot/babel issue with export to eps
On Thu, Jan 5, 2012 at 9:01 PM, John Hendy jw.he...@gmail.com wrote: On Thu, Jan 5, 2012 at 6:03 PM, Chris Malone chris.m.mal...@gmail.comwrote: Hi John, I'm not sure what Org mode is doing behind the scenes, but I suspect something is getting muddled because you specify both the src block file header /and/ the output terminal in the gnu plot code. Perhaps a simpler solution - if you indeed want Postscript images - would be to remove the =:file …= header argument and specify the =set output= within the gnuplot script itself? That should still generate the .eps file. I may give this a try at work tomorrow... just tried the same file on my Mac at home (running the same linux setup) and it's working, though I still get a filename.eps and a filename-eps-converted-to.pdf output. It's just that the .eps on this computer is valid and viewable. I'll have to dig into this some more; perhaps comparing org versions and .emacs config files. I'm pulling from the org git repo and doing a make now on this computer as we speak. If it still works, I'll do the same at work tomorrow and see if that helps. Fresh org pull, same file... no viable output. The =set output test.eps= command with no :file header does not work. I get code block produced no output in the minibuffer. Here's some things of interest... -- Removing =set terminal...= and exporting via =:file test.png= works -- Using =set terminal postscript= and =:file test.ps= works -- Using =set terminal postscript eps enhanced= and =:file test.eps= does *not* work What package provides the eps ability? Perhaps I removed something from my system that I didn't intend to! Any suggestions on how to see what's going on? Thanks, John Thanks for the input, John Chris On Jan 5, 2012, at 3:54 PM, John Hendy wrote: I have the following gnuplot/babel block and for some reason the resultant .eps file comes up broken but a corresponding version of it gets converted to pdf somehow... what's going on? I stole an example just to check and make sure it wasn't my gnuplot code: http://t16web.lanl.gov/Kawano/gnuplot/intro/plotfunc-e.html - #+begin_src gnuplot :file export.eps :exports results reset set terminal postscript eps color enhanced 20 a=0.25 b=0.02 c=0.05 d=0.1 f(x)=c/((x-a)*(x-a)+b)+d/sqrt(x) set xrange [0:1] set yrange [0:4] plot f(x) #+end_src - I get a file export.eps which is broken and unreadable by geeqie. I get a corresponding file called export-eps-converted-to.pdf that opens fine and looks like it should. What am I doing incorrectly? Thanks, John - Chris Malone (mal...@ucolick.org) Dept. of Astronomy and Astrophysics UC Santa Cruz 1156 High Street Santa Cruz, CA 95064-1077 phone: 831-459-3809 -
Re: [O] Gnuplot/babel issue with export to eps
On Fri, Jan 6, 2012 at 10:59 AM, John Hendy jw.he...@gmail.com wrote: On Thu, Jan 5, 2012 at 9:01 PM, John Hendy jw.he...@gmail.com wrote: On Thu, Jan 5, 2012 at 6:03 PM, Chris Malone chris.m.mal...@gmail.comwrote: Hi John, I'm not sure what Org mode is doing behind the scenes, but I suspect something is getting muddled because you specify both the src block file header /and/ the output terminal in the gnu plot code. Perhaps a simpler solution - if you indeed want Postscript images - would be to remove the =:file …= header argument and specify the =set output= within the gnuplot script itself? That should still generate the .eps file. I may give this a try at work tomorrow... just tried the same file on my Mac at home (running the same linux setup) and it's working, though I still get a filename.eps and a filename-eps-converted-to.pdf output. It's just that the .eps on this computer is valid and viewable. I'll have to dig into this some more; perhaps comparing org versions and .emacs config files. I'm pulling from the org git repo and doing a make now on this computer as we speak. If it still works, I'll do the same at work tomorrow and see if that helps. Fresh org pull, same file... no viable output. The =set output test.eps= command with no :file header does not work. I get code block produced no output in the minibuffer. Here's some things of interest... -- Removing =set terminal...= and exporting via =:file test.png= works -- Using =set terminal postscript= and =:file test.ps= works -- Using =set terminal postscript eps enhanced= and =:file test.eps= does *not* work What package provides the eps ability? Perhaps I removed something from my system that I didn't intend to! Any suggestions on how to see what's going on? Shoot. It's geeqie. On a hunch, I opened the eps in gimp and it views fine. Something's wrong with my image viewer... False alarm; org/babel/gnuplot are working fine. John Thanks, John Thanks for the input, John Chris On Jan 5, 2012, at 3:54 PM, John Hendy wrote: I have the following gnuplot/babel block and for some reason the resultant .eps file comes up broken but a corresponding version of it gets converted to pdf somehow... what's going on? I stole an example just to check and make sure it wasn't my gnuplot code: http://t16web.lanl.gov/Kawano/gnuplot/intro/plotfunc-e.html - #+begin_src gnuplot :file export.eps :exports results reset set terminal postscript eps color enhanced 20 a=0.25 b=0.02 c=0.05 d=0.1 f(x)=c/((x-a)*(x-a)+b)+d/sqrt(x) set xrange [0:1] set yrange [0:4] plot f(x) #+end_src - I get a file export.eps which is broken and unreadable by geeqie. I get a corresponding file called export-eps-converted-to.pdf that opens fine and looks like it should. What am I doing incorrectly? Thanks, John - Chris Malone (mal...@ucolick.org) Dept. of Astronomy and Astrophysics UC Santa Cruz 1156 High Street Santa Cruz, CA 95064-1077 phone: 831-459-3809 -
Re: [O] About the use of PROPERTY meta lines...
Torsten Wagner torsten.wag...@gmail.com writes: Hmm... but this point is really interesting at least worse to write down in the manual. From my understanding a #+PROPERTY: var bar=2 sets bar globally to 2 somewhere and many lines and headers later #+PROPERTY: var bar=5 would change this value to 5 for either the rest of the file or until a new assignment is given... I think the behavior is trickier than that. This file: , | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | #+property: var+ bar=20 | | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src ` Yields '30' after each block upon C-c C-e A, suggesting it is the last #+property setting the global property. But this one: , | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src ` Yields '3' after each block. So the global behavior of the second 'var foo' line depends on there baing a subsequent 'var+' line. Is this really the expected behavior? (Org-mode version 7.8.03) Chuck in that way a property line would be an tree-independent global variable in contrast, a property-block is only valid of the given tree (and subtrees?). This brings up the question if there is a need for #+PROPERTY: const bar=2 which would behave exactly the same like var but issue an error message if someone tries to set it again somewhere in the file. Torsten On 01/06/2012 04:28 PM, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: Hi Eric and all, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: #+TITLE: Properties #+AUTHOR:Seb Vauban #+PROPERTY: var foo=1 #+PROPERTY: var+ bar=2 * Abstract IIUC, properties are set in this way: - on a file basis, before any heading, through the =PROPERTY= keyword, - on a subtree basis, through the =PROPERTIES= block. My comprehension is that the =PROPERTY= keyword may not be used inside trees, and should be ignored if that would happen. While it is not normal usage, I think that it is legal for #+PROPERTY: lines (or #+Option: lines etc...) to appear inside of subtrees. I realize this is not especially a Babel question, but more a Org core question... Thanks for your answer -- which generates a new one, though: what is then the expected *semantics* of such a construct? There are at least 3 different views on such a construct: putting a PROPERTY line inside a subtree... - ... resets some values from that point up to the end of the subtree - ... resets some values from that point up to the end of the buffer - ... defines some values which can have already been by the subtree I agree this is murky and whatever behavior we want should be clearly thought out and documented in the manual. I would argue that you missed another possible semantics, the simple semantics which are currently implemented in which a property line *anywhere* in a buffer sets a global property. Cheers, Best regards, Seb The following example shows that either: - I'm wrong to think so, - there is a bug. What is the right assumption here? * Subtree Being located in a subtree, the following lines are ill-placed IMHO: #+PROPERTY: var foo=Hello #+PROPERTY: var+ world Though, they're well taken into account: #+begin_src emacs-lisp foo #+end_src #+results: : Hello world These lines have even wiped the definition of =bar= (because of the use of =var= without any =+=): #+begin_src emacs-lisp (+ foo bar) #+end_src returns the error Symbol's value as variable is void: bar.
Re: [O] [patch][test] Avoid writes to non-temp test-example files
Achim Gratz strom...@nexgo.de writes: Achim Gratz strom...@nexgo.de 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.
Re: [O] org-jira.el updated
Ken Williams kena...@gmail.com writes: Bao Haojun baohaojun at gmail.com writes: I have updated the org-jira.el as suggested by Bastien and Richard Riley: Amazing. Just 120 seconds ago I got out of a meeting where we talked about using Jira more widely in our company, and I worried that I'd duplicate too much between my org-mode journals and the Jira tracker. Then I go look at the org-mode list and this is the first message I see. =) I'm going to need to upgrade to org-mode 7.8 and try this out. I would love to see a video of jira being used in conjunction with org-mode. Anyone have one?
[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 martyn.j...@btinternet.com 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= 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 +*
Re: [O] [patch][babel] `org-babel-result-end' bug fix and regression tests
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. If removable raw results are desired then the :results wrap option may be used. I believe this is mentioned in the manual (if not it should be). I think this patch should not be applied (although maybe some of the test cases could still be useful). Thanks, Martyn Jago martyn.j...@btinternet.com writes: `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 -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [patch][babel] Fix latest block export tests to suit Emacs 22
Bastien b...@altern.org writes: Martyn Jago martyn.j...@btinternet.com 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 :)
Re: [O] About the use of PROPERTY meta lines...
Torsten Wagner torsten.wag...@gmail.com writes: Hmm... but this point is really interesting at least worse to write down in the manual. From my understanding a #+PROPERTY: var bar=2 sets bar globally to 2 somewhere and many lines and headers later #+PROPERTY: var bar=5 would change this value to 5 for either the rest of the file or until a new assignment is given... in that way a property line would be an tree-independent global variable Two points here. 1) currently #+property: lines are global and affect the entire file regardless of where they are located in the file, there is no notion of different values before or after a particular #+property: line. So in the case above I would expect the var property to have the value bar=5 as the later line will most likely overwrite the former line. 2) there is nothing special about the var property which could make it behave differently than other properties. in contrast, a property-block is only valid of the given tree (and subtrees?). true This brings up the question if there is a need for #+PROPERTY: const bar=2 which would behave exactly the same like var but issue an error message if someone tries to set it again somewhere in the file. No, currently *all* properties are set in the same way regardless of their name, and I think this is a simplification worth keeping. Best, Torsten On 01/06/2012 04:28 PM, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: Hi Eric and all, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: #+TITLE: Properties #+AUTHOR:Seb Vauban #+PROPERTY: var foo=1 #+PROPERTY: var+ bar=2 * Abstract IIUC, properties are set in this way: - on a file basis, before any heading, through the =PROPERTY= keyword, - on a subtree basis, through the =PROPERTIES= block. My comprehension is that the =PROPERTY= keyword may not be used inside trees, and should be ignored if that would happen. While it is not normal usage, I think that it is legal for #+PROPERTY: lines (or #+Option: lines etc...) to appear inside of subtrees. I realize this is not especially a Babel question, but more a Org core question... Thanks for your answer -- which generates a new one, though: what is then the expected *semantics* of such a construct? There are at least 3 different views on such a construct: putting a PROPERTY line inside a subtree... - ... resets some values from that point up to the end of the subtree - ... resets some values from that point up to the end of the buffer - ... defines some values which can have already been by the subtree I agree this is murky and whatever behavior we want should be clearly thought out and documented in the manual. I would argue that you missed another possible semantics, the simple semantics which are currently implemented in which a property line *anywhere* in a buffer sets a global property. Cheers, Best regards, Seb The following example shows that either: - I'm wrong to think so, - there is a bug. What is the right assumption here? * Subtree Being located in a subtree, the following lines are ill-placed IMHO: #+PROPERTY: var foo=Hello #+PROPERTY: var+ world Though, they're well taken into account: #+begin_src emacs-lisp foo #+end_src #+results: : Hello world These lines have even wiped the definition of =bar= (because of the use of =var= without any =+=): #+begin_src emacs-lisp (+ foo bar) #+end_src returns the error Symbol's value as variable is void: bar. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] About the use of PROPERTY meta lines...
cbe...@tajo.ucsd.edu writes: Torsten Wagner torsten.wag...@gmail.com writes: Hmm... but this point is really interesting at least worse to write down in the manual. From my understanding a #+PROPERTY: var bar=2 sets bar globally to 2 somewhere and many lines and headers later #+PROPERTY: var bar=5 would change this value to 5 for either the rest of the file or until a new assignment is given... I think the behavior is trickier than that. This file: , | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | #+property: var+ bar=20 | | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src ` Yields '30' after each block upon C-c C-e A, suggesting it is the last #+property setting the global property. This makes sense But this one: , | #+property: var foo=1 | #+property: var+ bar=2 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src | | #+property: var foo=10 | | #+begin_src emacs-lisp :results value :exports both | (+ foo bar) | #+end_src ` Yields '3' after each block. So the global behavior of the second 'var foo' line depends on there baing a subsequent 'var+' line. Is this really the expected behavior? No, the above behavior is not expected. I've just pushed up a patch which results in the following behavior, in which the last specification of a property overwrites any previous specifications. #+property: something foo=1 #+property: something+ bar=2 #+property: something foo=10 #+begin_src emacs-lisp org-file-properties #+end_src #+results: | (something . foo=10) | Best, (Org-mode version 7.8.03) Chuck in that way a property line would be an tree-independent global variable in contrast, a property-block is only valid of the given tree (and subtrees?). This brings up the question if there is a need for #+PROPERTY: const bar=2 which would behave exactly the same like var but issue an error message if someone tries to set it again somewhere in the file. Torsten On 01/06/2012 04:28 PM, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: Hi Eric and all, Eric Schulte wrote: Sebastien Vaubanwxhgmqzgw...@spammotel.com writes: #+TITLE: Properties #+AUTHOR:Seb Vauban #+PROPERTY: var foo=1 #+PROPERTY: var+ bar=2 * Abstract IIUC, properties are set in this way: - on a file basis, before any heading, through the =PROPERTY= keyword, - on a subtree basis, through the =PROPERTIES= block. My comprehension is that the =PROPERTY= keyword may not be used inside trees, and should be ignored if that would happen. While it is not normal usage, I think that it is legal for #+PROPERTY: lines (or #+Option: lines etc...) to appear inside of subtrees. I realize this is not especially a Babel question, but more a Org core question... Thanks for your answer -- which generates a new one, though: what is then the expected *semantics* of such a construct? There are at least 3 different views on such a construct: putting a PROPERTY line inside a subtree... - ... resets some values from that point up to the end of the subtree - ... resets some values from that point up to the end of the buffer - ... defines some values which can have already been by the subtree I agree this is murky and whatever behavior we want should be clearly thought out and documented in the manual. I would argue that you missed another possible semantics, the simple semantics which are currently implemented in which a property line *anywhere* in a buffer sets a global property. Cheers, Best regards, Seb The following example shows that either: - I'm wrong to think so, - there is a bug. What is the right assumption here? * Subtree Being located in a subtree, the following lines are ill-placed IMHO: #+PROPERTY: var foo=Hello #+PROPERTY: var+ world Though, they're well taken into account: #+begin_src emacs-lisp foo #+end_src #+results: : Hello world These lines have even wiped the definition of =bar= (because of the use of =var= without any =+=): #+begin_src emacs-lisp (+ foo bar) #+end_src returns the error Symbol's value as variable is void: bar. -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [patch][babel] `org-babel-result-end' bug fix and regression tests
Eric Schulte eric.schu...@gmx.com 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] How to force redisplay?
Hello, pin...@iro.umontreal.ca (François Pinard) writes: There is a little problem I often observed, about bad vertical alignment of text in Org mode buffers. How do you indent your text in the first place? Do you use C-j at the end of line? Do you use `org-indent-mode'? Also, what Org version do you use? Anyway, unless you're using `org-indent-mode', pressing TAB on any line should indent it correctly. You can also mark section and call `indent-region'. Regards, -- Nicolas Goaziou
Re: [O] [patch][babel] `org-babel-result-end' bug fix and regression tests
Martyn Jago martyn.j...@btinternet.com writes: Eric Schulte eric.schu...@gmx.com 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? Yes, this should be fixed. These newline-append issues are tricky as it can be difficult to fix for one type of result without accidentally breaking for other types of results. 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. 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. Thanks, Best, Martyn -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [patch][babel] `org-babel-result-end' bug fix and regression tests
Hi Eric Eric Schulte eric.schu...@gmx.com 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 martyn.j...@btinternet.com 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 +;;: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. + (test-ob-verify-result-and-removed-result + #+BEGIN_ORG +* heading +**
Re: [O] How to force redisplay?
Nicolas Goaziou n.goaz...@gmail.com writes: There is a little problem I often observed, about bad vertical alignment of text in Org mode buffers. How do you indent your text in the first place? I do not, at least so far that I know. Usually, I use a variable number of stars before a headline, and write text flushed left afterwards, and Org mode usually does exactly what I expect. Do you use C-j at the end of line? No, merely Enter at the end of each paragraph. Each paragraph is a single line. I also managed so M-q (`fill-paragraph') collapse a set of adjacent lines into a single one. There is usually no extra space at the beginning of a line (or paragraph). Yet, I noticed that If I add some, the whole paragraph is nicely shifted right on the screen, which is quite nice. Do you use `org-indent-mode'? Yes. Also, what Org version do you use? A fairly recent one, from Git. Likely one or two days old. Anyway, unless you're using `org-indent-mode', pressing TAB on any line should indent it correctly. You can also mark section and call `indent-region'. I do not remember TAB has any indenting effect, but has you say, it might not be relevant when using `org-indent-mode'. François
Re: [O] [patch][babel] `org-babel-result-end' bug fix and regression tests
Applied, Thanks, Martyn Jago martyn.j...@btinternet.com writes: Hi Eric Eric Schulte eric.schu...@gmx.com 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 -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Org-drill doesn't work...
JK == Joost Kremers joostkrem...@fastmail.fm writes: JK but org-drill isn't picking up the new entries. i've added a JK bunch of new entries to the file and they've all been given an JK :ID: property, but they are not being drilled. i'm sure i'm JK doing something wrong here, but i can't figure out what... It may happen if there is some problem with the contents of the entries (unrecognized items are silently skipped). I was hit by a similar problem but once I realized what's wrong, org-drill started to work perfectly for me. If you've successfully learned some entries previously, make sure the new entries are of the same format. If you're not successful, post some of the ignored entries here.
Re: [O] How to force redisplay?
pin...@iro.umontreal.ca (François Pinard) writes: I do not remember TAB has any indenting effect, but has you say, it might not be relevant when using `org-indent-mode'. I take that back! :-) TAB removes prefixing spaces if I happen to have any! Nice. The problem I observed is that the indentation is more to the left than the lefter it may be. So it has to be a display problem somehow, I guess. I wondered if there was some simple command to force the display to be recomputed or adjusted (something like recomputing text properties in a synchronous way, at least for the visible part of the window). François
Re: [O] Org-drill doesn't work...
On Fri, Jan 06, 2012 at 09:27:53PM +0100, Milan Zamazal wrote: It may happen if there is some problem with the contents of the entries (unrecognized items are silently skipped). I was hit by a similar problem but once I realized what's wrong, org-drill started to work perfectly for me. thanks for you reply. it prompted me to look a bit closer at the ignored items and i've now figured out what was wrong with them... it turns out that it is absolutely necessary that there is some text after the header of a drill item, before the first subheader. most of my items lacked this, however. my items looked like this: #+BEGIN_EXAMPLE ** Verb:drill: :PROPERTIES: :DRILL_CARD_TYPE: twosided :END: *** Deutsch some German verb *** Russisch Russian translation #+END_EXAMPLE however, they need to look like this: #+BEGIN_EXAMPLE ** Verb:drill: :PROPERTIES: :DRILL_CARD_TYPE: twosided :END: some text here = absolutely essential! *** Deutsch some German verb *** Russisch Russian translation #+END_EXAMPLE what is inconsistent about the way org-drill handles these is that even though it doesn't use these faulty entries for drilling, it *does* provide them with a unique :ID: property. so initially it doesn't look like there's anything wrong with them... i also didn't find an explicit mention of this in the docs, so perhaps i should send an email to paul sexton... but yes, now that i've figured out what i was doing wrong, org-drill works great! -- Joost Kremers Life has its moments
Re: [O] How to force redisplay?
pin...@iro.umontreal.ca (François Pinard) writes: There is a little problem I often observed, about bad vertical alignment of text in Org mode buffers. [...] So, my real question : is there a quick way to correct the indentation? I just got the problem again. OK, it seems a solution may be: (defun fp-org-adjust-visual-margins () Recompute visual left margins, for when they seem incorrect. (interactive) (org-indent-add-properties (point-min) (point-max))) François
[O] [solved] Re: Org-class: recurring appointments not being displayed
* Class 7:00pm-9:00pm %% (org-class 2011 1 10 2011 4 10 2 8) Just figured out the problem. I was using 2011 and looking for the results in agenda for 2012 (now). Classic start of a new year mistake. Doh!
