[O] [BUG?] subtle sequencing error when setting org-bbdb-old in org-bbdb.el
I was bitten by this and it took me a while to figure out what was going on, so maybe I can save somebody some time by recording the problem here. I'm using bbdb 2.36devo (i.e. an old bbdb version - see below for my 3.0 troubles), and although org-bbdb-anniversaries was working fine, bbdb links did not: C-c l on a bbdb entry would raise an error about void function bbdb-record-get-field. Now org-bbdb-store-link contains the following code (if org-bbdb-old (bbdb-record-getprop rec 'company) (car (bbdb-record-get-field rec 'organization)) so clearly org-bbdb-old was nil - but why? It seemed to me that it should be t since my bbdb was old. It turns out that org-bbdb.el contains a line that sets org-bbdb-old thus: (defvar org-bbdb-old (fboundp 'bbdb-record-get-field-internal)) Check whether an old bbdb function is present and if so, set org-bbdb-old to t. Basically, the variable tells the rest of org-bbdb.el whether one's bbdb is old ( 3.0) or not, so that it can use the proper compatibility layer. This was not working in my case : the variable resolutely held the value nil, no matter what requires/load-library/ etc tricks I threw at it. The problem was that org-bbdb is part of org-modules by default and that was loading org-bbdb way too early, certainly before bbdb itself was loaded. That would set the value to nil and nothing I would do could change it (short of whacking it with a setq). My solution was to change the customization of org-modules to get rid of org-bbdb there. I do things in the proper sequence in my initialization files in any case, so there is no need to have it in org-modules. But maybe there's a better solution? Re: the bbdb 3.0 troubles. I have tried switching to bbdb 3.0 (specifically BBDB version 3.02 ($Date: 2012/01/02 10:08:06 $)) but I've been stymied so far with org-bbdb-anniversaries blowing up (a far worse scenario than the link problem above - that's why I'm still using 2.36devo and went after the link fix first). The error I get is Debugger entered--Lisp error: (void-function bbdb-record-getprop) in org-bbdb-anniv-hash (see backtrace below), but I haven't chased down that problem yet. But it seems there are people using bbdb 3.0 so I'm wondering what's wrong with my setup. Nick --- Debugger entered--Lisp error: (void-function bbdb-record-getprop) (bbdb-record-getprop rec org-bbdb-anniversary-field) (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (if (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (progn (setq annivs (bbdb-split annivs \n)) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y (bbdb-record-name rec) (cadr split)) tmp) org-bbdb-anniv-hash) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs \n)) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y (bbdb-record-name rec) (cadr split)) tmp) org-bbdb-anniv-hash (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs \n)) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y (bbdb-record-name rec) (cadr split)) tmp) org-bbdb-anniv-hash (setq --cl-dolist-temp-- (cdr --cl-dolist-temp--))) (let ((--cl-dolist-temp-- (bbdb-records)) rec) (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs \n)) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun (car split))) (setq tmp (gethash (list m d) org-bbdb-anniv-hash)) (puthash (list m d) (cons (list y ... ...) tmp) org-bbdb-anniv-hash (setq --cl-dolist-temp-- (cdr --cl-dolist-temp-- (catch (quote --cl-block-nil--) (let ((--cl-dolist-temp-- (bbdb-records)) rec) (while --cl-dolist-temp-- (setq rec (car --cl-dolist-temp--)) (when (setq annivs (bbdb-record-getprop rec org-bbdb-anniversary-field)) (setq annivs (bbdb-split annivs \n)) (while annivs (setq split (org-bbdb-anniv-split (pop annivs))) (multiple-value-bind (m d y) (values-list (funcall org-bbdb-extract-date-fun ...)) (setq tmp (gethash ... org-bbdb-anniv-hash))
Re: [O] Bug: [patch] Fixes behavior of org-agenda-tree-to-indirect-buffer [7.8.02 (release_7.7.796.gc512)]
Hi Dave, At Fri, 17 Feb 2012 22:48:13 -1000, Dave Abrahams wrote: [1 text/plain (7bit)] Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. This function was misbehaving in a number of ways. The enclosed patch represents the changes necessary to make it work properly, accumulated over several weeks of testing. Sorry if the description is a bit vague. Thanks for the patch. I implemented the first to modifications (handle org-last-indirect-buffer being nil and window-live-p indirect-window). These were indeed bugs or glitches. The third modification (set visibility according to property) is a new feature. Currently org-tree-to-indirect buffer does not use the VISIBILITY property but it makes sense to me to do so. I'll check this out and see to implement this. Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpMkODf3Ofje.pgp Description: PGP signature
Re: [O] odt-export fails
The backtrace is along the expected lines. The zip command is failing for some reason. Did you look at the *Messages* buffer? It is likely to give some clue on why the zip command is failing. Btw, if you have cvd-modeling-proposal.odt already open in an external application like LibreOffice, you may want to close the file first, before exporting. Closing the file will ensure that the file is not locked and available for re-writing. Hello: This is on Windows 7 Emacs 23.3.1, org-version 7.8.03. (I installed org-mode inside cygwin's shell). Here is the backtrace: Debugger entered--Lisp error: (error Unable to create odt file (12)) signal(error (Unable to create odt file (12))) error(Unable to create odt file (%S) 12) (or (zerop exitcode) (ignore (message %s err-string)) (error Unable to create odt file (%S) exitcode)) (lambda (cmd) ... stuff deleted org-odt-save-as-outfile(c:/Users/977315/Documents/projects/low-pressure-flow/workbooks/shh+cvd-design-tool-proposal/cvd-modeling-proposal.odt ... more stuff deleted ... org-do-lparse(nil nil nil nil nil nil) org-lparse(odt odt nil nil nil nil nil nil) org-export-as-odt(nil) call-interactively(org-export-as-odt) org-export(nil) call-interactively(org-export nil nil) The backtrace refers to a a non-existent odt file (see call to org-odt-save-as-outfile). Does the call stack look ok to you? Thanks, Mirko --
Re: [O] Bug: [patch] Fixes behavior of org-agenda-tree-to-indirect-buffer [7.8.02 (release_7.7.796.gc512)]
on Sat Feb 25 2012, David Maus dmaus-AT-ictsoc.de wrote: Hi Dave, At Fri, 17 Feb 2012 22:48:13 -1000, Dave Abrahams wrote: [1 text/plain (7bit)] Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. This function was misbehaving in a number of ways. The enclosed patch represents the changes necessary to make it work properly, accumulated over several weeks of testing. Sorry if the description is a bit vague. Thanks for the patch. I implemented the first to modifications (handle org-last-indirect-buffer being nil and window-live-p indirect-window). Sorry, I can't parse that last sentence, and as a result I'm having trouble understanding the rest of the message. These were indeed bugs or glitches. The third modification (set visibility according to property) is a new feature. Currently org-tree-to-indirect buffer does not use the VISIBILITY property but it makes sense to me to do so. I'll check this out and see to implement this. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Re: [O] Bug: [patch] Fixes behavior of org-agenda-tree-to-indirect-buffer [7.8.02 (release_7.7.796.gc512)]
At Sat, 25 Feb 2012 08:34:22 -0500, Dave Abrahams wrote: on Sat Feb 25 2012, David Maus dmaus-AT-ictsoc.de wrote: Hi Dave, At Fri, 17 Feb 2012 22:48:13 -1000, Dave Abrahams wrote: [1 text/plain (7bit)] Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. This function was misbehaving in a number of ways. The enclosed patch represents the changes necessary to make it work properly, accumulated over several weeks of testing. Sorry if the description is a bit vague. Thanks for the patch. I implemented the first to modifications (handle org-last-indirect-buffer being nil and window-live-p indirect-window). Your patch contained three modifications to `org-agenda-tree-to-indirect-buffer': 1. handle the case where there was no indirect buffer yet, i.e. (eq org-last-indirect-buffer nil) = applied 2. handle the case where the window of the last indirect buffer is no longer live = applied 3. set the subtree visibility according to the VISIBILITY property after the indirect buffer was created = no applied The third modification does not fix a bug, but is a useful feature. This should be implemented in `org-tree-to-indirect-buffer' and I'm going to do exactly this. Better? Best, -- David -- OpenPGP... 0x99ADB83B5A4478E6 Jabber dmj...@jabber.org Email. dm...@ictsoc.de pgpaTpSXyx0Ga.pgp Description: PGP signature
Re: [O] odt-export fails
Hello Jambunathan, I do not have the odt document open. From the *Message* buffer, it seems that zip is looking for the odt file in c:\Users\...\AppData\Temp\..., but the file is not present In the org-odt-save-as-outfile let* block from which the error is thrown (let* ((target-name) (target ...) ...) zip-commands) zip-commands are looking for the *.odt file to zip together with the mimetype file. But the *.odt file is not there. The only thing that is there is the content.xml, that contains the the *.org file's text. In fact, in the code, I don't see anything being done with the xml files. They are created, and then killed. I am including the trace from the *Messages* buffer. Trace begin Export buffer: Exporting to ODT using org-lparse... Using vacuous schema LaTeX to MathML converter not available. Using dvipng instead. Exporting... Using vacuous schema ODT export done, pushed to kill ring and clipboard Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/meta.xml Using vacuous schema Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/mimetype Using vacuous schema Switching to directory c:/Users/977315/AppData/Local/Temp/odt-7628lrW/ Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml (No changes need to be saved) Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml Using vacuous schema (No changes need to be saved) Creating odt file... Running zip -mX0 org-odt-export.odt mimetype zip warning: name not matched: mimetype zip error: Nothing to do! (org-odt-export.odt) Entering debugger... Back to top level. Trace end Mirko On Sat, Feb 25, 2012 at 8:28 AM, Jambunathan K kjambunat...@gmail.com wrote: The backtrace is along the expected lines. The zip command is failing for some reason. Did you look at the *Messages* buffer? It is likely to give some clue on why the zip command is failing. Btw, if you have cvd-modeling-proposal.odt already open in an external application like LibreOffice, you may want to close the file first, before exporting. Closing the file will ensure that the file is not locked and available for re-writing. Hello: This is on Windows 7 Emacs 23.3.1, org-version 7.8.03. (I installed org-mode inside cygwin's shell). Here is the backtrace: Debugger entered--Lisp error: (error Unable to create odt file (12)) signal(error (Unable to create odt file (12))) error(Unable to create odt file (%S) 12) (or (zerop exitcode) (ignore (message %s err-string)) (error Unable to create odt file (%S) exitcode)) (lambda (cmd) ... stuff deleted org-odt-save-as-outfile(c:/Users/977315/Documents/projects/low-pressure-flow/workbooks/shh+cvd-design-tool-proposal/cvd-modeling-proposal.odt ... more stuff deleted ... org-do-lparse(nil nil nil nil nil nil) org-lparse(odt odt nil nil nil nil nil nil) org-export-as-odt(nil) call-interactively(org-export-as-odt) org-export(nil) call-interactively(org-export nil nil) The backtrace refers to a a non-existent odt file (see call to org-odt-save-as-outfile). Does the call stack look ok to you? Thanks, Mirko --
Re: [O] [babel] [PATCH] enhanced org-babel-goto-named-src-block
Applied, Thanks! Andreas Leha andreas.l...@med.uni-goettingen.de writes: Hi all, attached is a patch that enhances org-babel-goto-named-src-block (bound to C-c C-v g by default). Included are two enhancements: 1. the point is pushed to the org-mark-ring, such that returning with C-c becomes possible 2. the target src block is guessed from a) noweb-reference b) #+call: c) #+results: d) symbol-at-point if one of these is found (in that order) - Andreas diff --git a/lisp/ob.el b/lisp/ob.el index f021943..9962817 100644 --- a/lisp/ob.el +++ b/lisp/ob.el @@ -1457,13 +1457,35 @@ If the point is not on a source block then return nil. (defun org-babel-goto-named-src-block (name) Go to a named source-code block. (interactive - (let ((completion-ignore-case t)) + (let ((completion-ignore-case t) + (under-point (thing-at-point 'line))) (list (org-icompleting-read source-block name: - (org-babel-src-block-names) nil t + (org-babel-src-block-names) + nil + t + (cond + ;; noweb + ((string-match (org-babel-noweb-wrap) under-point) +(let ((block-name (match-string 1 under-point))) + (string-match [^(]* block-name) + (match-string 0 block-name))) + ;; #+call: + ((string-match org-babel-lob-one-liner-regexp under-point) +(let ((source-info (car (org-babel-lob-get-info + (if (string-match ^\\([^\\[]+?\\)\\(\\[.*\\]\\)?( source-info) + (let ((source-name (match-string 1 source-info))) +source-name + ;; #+results: + ((string-match (concat #\\+ org-babel-results-keyword \\:\s+\\([^\\(]*\\)) under-point) +(match-string 1 under-point)) + ;; symbol-at-point + ((and (thing-at-point 'symbol) )(org-babel-find-named-block (thing-at-point 'symbol)) +(thing-at-point 'symbol)) + ()) (let ((point (org-babel-find-named-block name))) (if point ;; taken from `org-open-at-point' -(progn (goto-char point) (org-show-context)) +(progn (org-mark-ring-push) (goto-char point) (org-show-context)) (message source-code block '%s' not found in this buffer name (defun org-babel-find-named-block (name) -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Using org-babel with Scheme
Kyle Andrews kcand...@mtu.edu writes: I am having both of these issues on Emacs 24. Emacs crashes sometimes on geiser and babel won't evaluate scheme code as Racket code despite setting 'scheme-program-name and 'org-babel-scheme-cmd to racket. However, Guile will work if both of those variables hold guile. Any new developments? I haven't had time to look into this. I imagine the first issue is a problem with Geiser. As for the second issue, note that the value of the 'org-babel-scheme-cmd variable is only used when external execution is requested (e.g., when session is set to none), otherwise session evaluation is used (likely using Geiser if Geiser is installed). Sorry I do not have more time to look into this at the moment. I you feel like looking to the code, a good starting place would be to run the command `edebug-eval-top-level-form' within the definition of `org-babel-execute:scheme' in ob-scheme.el, then running a code block and stepping through its evaluation. Best, On Wed, Feb 15, 2012 at 9:33 AM, Eric Schulte eric.schu...@gmx.com wrote: Leo Alekseyev dnqu...@gmail.com writes: Is anyone on the list using a recent org-babel with Scheme? I recently started working through SICP, and I'm running into issues evaluating scheme src blocks. Org-babel error buffer pops up with ERROR: Wrong number of arguments to #primitive-generic display, and the minibuffer prompts me for a lisp expression. Is there anything I need to configure beyond (org-babel-do-load-languages 'org-babel-load-languages '((scheme . t)))? (Running latest org from git in Emacs 24; have Chicken scheme and guile installed). I loaded the ob-scheme.el directly (which should be the same as loading it with org-babel-do-load-languages as above) and the following works for me. #+begin_src scheme (+ 1 1 1) #+end_src #+RESULTS: : 3 I have guile installed and I have the `scheme-program-name' variable set to guile elsewhere in my .emacs init. I imagine setting the above variable should enable scheme evaluation. Best, while looking into this I did notice that when launching Geiser (a nice slime-like scheme evaluator) I would sometimes crash my entire Emacs process by pressing C-g when Geiser prompts for a scheme executable. I imagine this is unrelated to your problem, but was certainly surprising. --Leo -- Eric Schulte http://cs.unm.edu/~eschulte/ -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] [babel] [PATCH] Add support for MonetDB for SQL blocks
Applied, Thanks!
Viktor Rosenfeld listuse...@googlemail.com writes:
Hi,
the attached patch adds support for evaluating SQL blocks on MonetDB.
The MonetDB client normally requires the password to be inputted on the
console. To get around this, you have to use a dotfile ~/.monetdb with
authentification data. Note that this file is ignored if you specify a
user on the cmdline. See
http://www.monetdb.org/Documentation/mclient-man-page for details.
A usage example follows.
Setup MonetDB test database and authentification data
#+BEGIN_SRC sh :results output verbatim
MONETDB_DIR=$HOME/unix/var/monetdb/demodb
monetdbd create $MONETDB_DIR
monetdbd start $MONETDB_DIR
monetdb create demodb
monetdb release demodb
cat ~/.monetdb EOF
user=monetdb
password=monetdb
EOF
#+END_SRC
#+RESULTS:
: created database in maintenance mode: demodb
: taken database out of maintenance mode: demodb
Data is returned without column names (the default return format
cannot be parsed by Babel).
#+BEGIN_SRC sql :engine monetdb :cmdline demodb
CREATE TABLE foo ( bar INTEGER );
SELECT 'Table count', count(*) FROM foo;
#+END_SRC
#+RESULTS:
| Table count | 0 |
The parameter -i is required on the command line in order to use
special client commands. Also note that a newline is required at the
end if the last line contains a special client command.
#+BEGIN_SRC sql :engine monetdb :cmdline demodb -i :results output
verbatim
\d
\?
#+END_SRC
#+RESULTS:
#+begin_example
TABLE sys.foo
\? - show this message
\file - read input from file
\file - save response in file, or stdout if no file is given
\|cmd - pipe result to process, or stop when no command is given
\h - show the readline history
\D table- dumps the table, or the complete database if none given.
\d[Stvsfn]+ [obj] - list database objects, or describe if obj given
\A - enable auto commit
\a - disable auto commit
\e - echo the query in sql formatting mode
\f - format using a built-in renderer {csv,tab,raw,sql,xml}
\w# - set maximal page width (-1=unlimited, 0=terminal width,
0=limit to num)
\r# - set maximum rows per page (-1=raw)
\L file - save client/server interaction
\X - trace mclient code
\q - terminate session
#+end_example
Have fun!
Viktor
diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el
index 68bd95a..20fbad3 100644
--- a/lisp/ob-sql.el
+++ b/lisp/ob-sql.el
@@ -70,6 +70,10 @@ This function is called by `org-babel-execute-src-block'.
(org-babel-temp-file sql-out-)))
(header-delim )
(command (case (intern engine)
+('monetdb (format mclient -f tab %s %s %s
+ (or cmdline )
+ (org-babel-process-file-name in-file)
+ (org-babel-process-file-name
out-file)))
('msosql (format osql %s -s \\t\ -i %s -o %s
(or cmdline )
(org-babel-process-file-name in-file)
--
Eric Schulte
http://cs.unm.edu/~eschulte/
Re: [O] [babel] FYI: documentation for picolisp added to worg
Hi Thorsten, This page looks great, thanks for contributing! Hopefully this will lower the barrier of entry for both Org-mode code blocks and Picolisp. Chers, Thorsten quintf...@googlemail.com writes: Hi List, I added the documentation page for the org babel language picolisp to worg. You can find it here: http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-picolisp.html -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] odt-export fails
Hello Jambunathan, I do not have the odt document open. Ok. From the *Message* buffer, it seems that zip is looking for the odt file in c:\Users\...\AppData\Temp\..., but the file is not present , | Creating odt file... | Running zip -mX0 org-odt-export.odt mimetype | zip warning: name not matched: mimetype | | zip error: Nothing to do! (org-odt-export.odt) | ` No. Zip is trying to create an ODT file. It starts with putting the mimetype file in the org-odt-export.odt. That is what the command above does. Unfortunately it is not able to find the mimetype file. See the warning message above. That is why you get an error. , | Switching to directory c:/Users/977315/AppData/Local/Temp/odt-7628lrW/ ` This is the directory (it is a temporary directory) where the mimetype file and various files are created. , | Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/meta.xml | Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml | Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/mimetype | | Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml | Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml | Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml ` The above messages show that the mimetype file and all the XML files are indeed created. I suggest you do this: 1. Export with C-c C-e O and let the error happen 2. M-x shell RET and in the shell prompt, do the following steps. 3. Switch to the temporary directory using cd 4. Check what files are in that directory with ls 5. Make sure that you are able to see all the above files. You may want to check that the mimetype file is also there. 6. Run the following command, $ zip -mX0 org-odt-export.odt mimetype If the mimetype file is there, the above command should succeed and will create org-odt-export.odt file for you. 7. If you don't see the mimetype file in step 5, it is possible that someone (the OS) is removing the temporary files very quickly. In that case, you can try using your own temporary directory with the following command (setq temporary-file-directory ~/tmp/) and try exporting it again. This is a strange issue and I am making the best possible guess based on the information that you have provided. ps: What version of Windows are you using? Does the OS or any app on your desktop aggressively remove temporary files? In the org-odt-save-as-outfile let* block from which the error is thrown (let* ((target-name) (target ...) ...) zip-commands) zip-commands are looking for the *.odt file to zip together with the mimetype file. But the *.odt file is not there. The only thing that is there is the content.xml, that contains the the *.org file's text. In fact, in the code, I don't see anything being done with the xml files. They are created, and then killed. I am including the trace from the *Messages* buffer. Trace begin Export buffer: Exporting to ODT using org-lparse... Using vacuous schema LaTeX to MathML converter not available. Using dvipng instead. Exporting... Using vacuous schema ODT export done, pushed to kill ring and clipboard Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/meta.xml Using vacuous schema Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/mimetype Using vacuous schema Switching to directory c:/Users/977315/AppData/Local/Temp/odt-7628lrW/ Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/styles.xml (No changes need to be saved) Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/META-INF/manifest.xml Saving file c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml... Wrote c:/Users/977315/AppData/Local/Temp/odt-7628lrW/content.xml Using vacuous schema (No changes need to be saved) Creating odt file... Running zip -mX0 org-odt-export.odt mimetype zip warning: name not matched: mimetype zip error: Nothing to do! (org-odt-export.odt) Entering debugger... Back to top level. Trace end Mirko On Sat, Feb 25, 2012 at 8:28 AM, Jambunathan K kjambunat...@gmail.com wrote: The backtrace is along the expected lines. The zip command is failing for some reason. Did you look at the *Messages* buffer? It is likely to give some clue on why the zip command is failing. Btw, if you have cvd-modeling-proposal.odt already open in an external application like LibreOffice, you may want to close the file first, before exporting. Closing the file will ensure that the file is not locked and available for re-writing. Hello: This is on Windows 7
Re: [O] Tangle only code block body
Hi Ista, Use the :no-expand header argument. See http://orgmode.org/manual/no_002dexpand.html Best, Ista Zahn istaz...@gmail.com writes: Hi all, Is there a way to tangle just the body of code blocks, without any header argurments? For example when I tangle this file # begin example # * test #+name: testplot #+begin_src R :results output graphics :file tmp.png :tangle tmp.R plot(1:10) #+end_src # end example # I get png(filename=tmp.png) plot(1:10) dev.off() but I want just plot(1:10) I've tried removing the %flag setting in org-babel-exp-code-template but it didn't seem to have any effect. Thanks for any pointers, Ista -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] odt-export fails
Jambunathan K kjambunat...@gmail.com writes: (setq temporary-file-directory ~/tmp/) You can see how it is set on my Windows XP machine. Basically it some directory under my My Documents path. I never had any problems with this setup. ,[ C-h v temporary-file-directory RET ] | temporary-file-directory is a variable defined in `C source code'. | Its value is ~/tmp/ | Original value was | c:/DOCUME~1/KJAMBU~1/LOCALS~1/Temp/ | | Documentation: | The directory for writing temporary files. | | You can customize this variable. | | [back] ` #+begin_src emacs-lisp (expand-file-name ~/tmp) #+end_src #+RESULTS: : c:/Documents and Settings/kjambunathan/My Documents/My Data/tmp --
[O] [Bug] Regression w/ insert into tables in overwrite-mode
Commit 00040e7 by David Maus has introduced a regression when inserting into org tables while overwrite mode is on. For each character inserted into a table cell, the cell (and the whole table row) gets shortened by one character. If the change can not be reverted, the deletion must not happen when overwrite mode is on, maybe through something like this: (if (not overwrite-mode) (delete-char -1)) Emacs24 actually does not have the doc string that admonishes not to use the function delete-backward-char in non-interactive mode, so the point of the commit may actually be moot (although neither the doc string of delete-char nor delete-backward char make much mention of overwrite mode). Interestingly, even though I am inside the table, org-self-insert-command gets called and not orgtbl-self-insert-command, so I can't really say if both changes would need to be fixed in the same way. Additionally, it appears that the implementation and the doc string for orgtbl-self-insert-command don't match, there doesn't seem to be any use of overwrite mode in its implementation. Regards, Achim. -- +[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+ Samples for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [O] Setting multiple variables for code blocks in one property drawer
Hi, Viktor Rosenfeld listuse...@googlemail.com writes: Hi Eric, Eric Schulte wrote: Viktor Rosenfeld listuse...@googlemail.com writes: Hi Eric, thanks for your input. I just pulled the latest code from git and while my original example works, the following does not: :PROPERTIES: :var: foo=1 :var+: bar=2 :var+: baz=3 :END: #+BEGIN_SRC sh echo foo: $foo echo bar: $bar echo baz: $baz #+END_SRC Thanks for reporting, I've just pushed up a fix for this bug. Thanks for your fix. The above example now works for me. However, I've noticed a problem with inheriting var properties. They are inherited in a child task only if the child task itself has no var property. Is this the intended behavior? See the example below. Yes, The example below is the intended behavior. The property mechanism is not tailored to variable setting, but is rather a general mechanism for the concatenation of property strings. Any property specification unless it is postfixed with a + will /reset/ the value of that property to its current value. However try replacing :var: foo=a with :var+: foo=a which is valid and should work for your use case below. There are still some lingering issues with inheritance and Org-mode properties which I may try to address one of these days. Cheers, Cheers, Viktor * Parent task :PROPERTIES: :var: foo=1 :var+: bar=2 :END: ** Child task without own properties #+BEGIN_SRC sh echo foo: $foo echo bar: $bar #+END_SRC #+RESULTS: | foo: | 1 | | bar: | 2 | ** Child task with own properties :PROPERTIES: :var: foo=a :END: #+BEGIN_SRC sh echo foo: $foo echo bar: $bar #+END_SRC #+RESULTS: | foo: | a | | bar: | | -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] Bug: [patch] Fixes behavior of org-agenda-tree-to-indirect-buffer [7.8.02 (release_7.7.796.gc512)]
on Sat Feb 25 2012, Dave Abrahams dave-AT-boostpro.com wrote: on Sat Feb 25 2012, David Maus dmaus-AT-ictsoc.de wrote: Hi Dave, At Fri, 17 Feb 2012 22:48:13 -1000, Dave Abrahams wrote: [1 text/plain (7bit)] Remember to cover the basics, that is, what you expected to happen and what in fact did happen. You don't know how to make a good report? See http://orgmode.org/manual/Feedback.html#Feedback Your bug report will be posted to the Org-mode mailing list. This function was misbehaving in a number of ways. The enclosed patch represents the changes necessary to make it work properly, accumulated over several weeks of testing. Sorry if the description is a bit vague. Thanks for the patch. I implemented the first to modifications (handle org-last-indirect-buffer being nil and window-live-p indirect-window). Sorry, I can't parse that last sentence, and as a result I'm having trouble understanding the rest of the message. These were indeed bugs or glitches. The third modification (set visibility according to property) is a new feature. Currently org-tree-to-indirect buffer does not use the VISIBILITY property but it makes sense to me to do so. Well, new feature or not, org-tree-to-indirect-buffer stopped behaving correctly for me when it was added, and I had to make adjustments. I'll check this out and see to implement this. Thanks. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Re: [O] odt-export fails
The problem was fixed by changing temporary-file-directory from c:\Users\...\AppData\Local\Temp to ~/temp/ I am running windows 7. The environment variables TEMP TMP both point to c:\Users\...\AppData\Local\Temp. I guess that zip/unzip were running in the ~/temp directory, while the files were stored in the ...\AppData\Local\Temp one. Thanks for your help. Mirko On Sat, Feb 25, 2012 at 12:35 PM, Jambunathan K kjambunat...@gmail.com wrote: Jambunathan K kjambunat...@gmail.com writes: (setq temporary-file-directory ~/tmp/) You can see how it is set on my Windows XP machine. Basically it some directory under my My Documents path. I never had any problems with this setup. ,[ C-h v temporary-file-directory RET ] | temporary-file-directory is a variable defined in `C source code'. | Its value is ~/tmp/ | Original value was | c:/DOCUME~1/KJAMBU~1/LOCALS~1/Temp/ | | Documentation: | The directory for writing temporary files. | | You can customize this variable. | | [back] ` #+begin_src emacs-lisp (expand-file-name ~/tmp) #+end_src #+RESULTS: : c:/Documents and Settings/kjambunathan/My Documents/My Data/tmp --
Re: [O] notifications for todo items
On Sat, Feb 25 2012, Nick Dokos wrote: A quick first impression: orgntf-process seems expensive. It seems to take 100% of one core (I've got a quad-core processor) for three or four seconds every fifty seconds. Unfortunately, the core is the same one that's running emacs, so emacs stops responding for those three or four seconds. I have disabled org-notify for now. How many lines do you have in your org-files? (I've about 200 and execution time is about 100ms.) I call now (org-element-parse-buffer 'heading), I hope it's faster for you. Is it faster, when the file is byte-compiled? Other ideas: - I could divide orgntf-process into several tasks, so that things run more smoothly. - You could call (org-notify-start -60), so the process will be called, when idle for one minute. The file has a new home: https://github.com/p-m/org-notify There is now `orgntf-verbose' to see execution time of `orgntf-todo-list'. Thanks for testing! -- Peter
[O] Refile: refile to any open file.
It occurs from time to time that I wish to refile to an open file, that is not one of my org-refile-targets. It doesn't make sense to use org-agenda-files for refile targets since I might have other files open for various reasons. So I thought, why not either declare that any open file is a refile target, or else write a function that will execture org-refile with org-refile-targets set to include all open files. In truth, it would be even better to include org-agenda-files in the set of target files. I have been using the function oog in org-occur-goto.el to search any open file, so somewhere in that file is a way to find open files. What remains is to use some condition from this file to declare org-refile-targets. I understand that a function can be used as a value of this variable. I could spend all night working on this, or, ask on this list. Can anyone point to a good way to declare that BOTH all open buffers/files AND org-agenda-files as org-refile-targets? A hint would help. Alan Davis
[O] Weight of headers
Hello, all Org friends. Here is a need I have once in a while, but for which I do not even have realistic suggestions to offer (at least, so I feel). Maybe someone would offer more precise ideas. :-) When I have a big Org file which I want to re-organize, one of the criteria I use is to manage the overall plan, always keeping a logical organization of things of course, and move things around so top-level headers become of comparable weights. By weight, I mean the amount of contents, which is a fuzzy concept (it could be measured as the number of sub-headers or sub-items, the depth of structure, or even the raw number or lines or characters). It may look strange, but this is not so bizarre after all. When reading a book, it is unusual to have a chapter having one page next to a chapter having hundreds of page; we expect that the effort of reading a chapter is not widely different from the effort of reading another. In the same way, if I decide to tackle the topics under a header, I would expect that the energy needed somehow announces the energy that would be required to handle another level at the same level. Of course, there could be quite a variance, but nevertheless, I would like to keep that variance within bounds. And recursively! The same way I would like to work an weight equilibrium for top-level headers, I would like to do the same for the sub-headers of a given header. My need here is to get an estimate of the weight of displayed headers. I could of course expand the whole document and page through to get an idea, but at least in the document I'm currently handling, I'm just overwhelmed. (This is not the only document triggering this in me, I remember having felt that need many times when I was using WorkFlowy). I once thought that colors could encode the weight, but it just would not fit Org mode so far that I understand it. However, it seems that, here and there, Org uses some overly magic to display extra information -- for example, like with `C-c C-x C-d (`org-clock-display')'. Maybe that some similar machinery could be use to display header weights? Or maybe this would be overkill, because there are simpler ways which I just do not know? François
Re: [O] notifications for todo items
Peter Münster pmli...@free.fr wrote: On Sat, Feb 25 2012, Nick Dokos wrote: A quick first impression: orgntf-process seems expensive. It seems to take 100% of one core (I've got a quad-core processor) for three or four seconds every fifty seconds. Unfortunately, the core is the same one that's running emacs, so emacs stops responding for those three or four seconds. I have disabled org-notify for now. How many lines do you have in your org-files? (I've about 200 and execution time is about 100ms.) Roughly 7000 - I just added a task to clean things up, so it's now 7002 :-) I call now (org-element-parse-buffer 'heading), I hope it's faster for you. Is it faster, when the file is byte-compiled? Other ideas: - I could divide orgntf-process into several tasks, so that things run more smoothly. - You could call (org-notify-start -60), so the process will be called, when idle for one minute. This sounds promising - I'll try this out in the next iteration. The file has a new home: https://github.com/p-m/org-notify There is now `orgntf-verbose' to see execution time of `orgntf-todo-list'. OK - I'll try it out when I get a chance. Thanks, Nick
Re: [O] notifications for todo items
Peter Münster pmli...@free.fr wrote: On Sat, Feb 25 2012, Nick Dokos wrote: A quick first impression: orgntf-process seems expensive. It seems to take 100% of one core (I've got a quad-core processor) for three or four seconds every fifty seconds. Unfortunately, the core is the same one that's running emacs, so emacs stops responding for those three or four seconds. I have disabled org-notify for now. How many lines do you have in your org-files? (I've about 200 and execution time is about 100ms.) I call now (org-element-parse-buffer 'heading), I hope it's faster for you. Is it faster, when the file is byte-compiled? Other ideas: - I could divide orgntf-process into several tasks, so that things run more smoothly. - You could call (org-notify-start -60), so the process will be called, when idle for one minute. The file has a new home: https://github.com/p-m/org-notify There is now `orgntf-verbose' to see execution time of `orgntf-todo-list'. Thanks for testing! Profiling results after byte compiling both org-notify.el and org-element.el (the rest of org is uncompiled code): , | org-element-parse-elements891 3.846205 0.0043167295 | orgntf-process1 1.594772 1.594772 | orgntf-time-measure 1 1.594763 1.594763 | orgntf-todo-list 1 1.59444 1.59444 | org-element-parse-buffer 15 1.575525 0.1050350666 | org-element-current-element 876 1.512512 0.0017266118 | org-element-headline-parser 876 1.477510 0.0016866552 | org-entry-properties 1752 0.720182 0.0004110627 | org-element-parse-secondary-string876 0.468200 0.0005344748 | org-element-parse-objects 942 0.431715 0.0004582972 | org-element-get-next-object-candidates1151 0.404424 0.0003513683 | org-back-to-heading 3504 0.125123 3.570...e-05 | org-element-time-stamp-successor 969 0.120690 0.0001245521 | org-heading-components876 0.053240 6.077...e-05 | org-element-latex-or-entity-successor 1884 0.046981 2.493...e-05 | org-end-of-subtree876 0.036546 4.171...e-05 | org-match-string-no-properties4167 0.030249 7.259...e-06 | org-element-link-successor998 0.022016 2.206...e-05 | org-get-limited-outline-regexp1676 0.019910 1.187...e-05 | org-element-sub/superscript-successor 953 0.013222 1.387...e-05 | org-truely-invisible-p876 0.012717 1.451...e-05 | org-get-property-block876 0.011843 1.351...e-05 | org-element-map 15 0.010387 0.0006924666 | org-element-inline-src-block-successor942 0.006624 7.031...e-06 | org-element-text-markup-successor 942 0.006122 6.499...e-06 | org-at-heading-p 1767 0.005833 3.301...e-06 | org-element-macro-successor 876 0.005385 6.148...e-06 | org-get-category 1752 0.005148 2.938...e-06 | org-element-link-parser 63 0.004671 7.414...e-05 | org-element-inline-babel-call-successor 942 0.004548 4.829...e-06 | org-element-statistics-cookie-successor 922 0.003133 3.399...e-06 | org-refresh-category-properties 10 0.002967 0.0002967999 | org-element-property 5073 0.002889 5.694...e-07 | org-skip-whitespace 891 0.002762 3.101...e-06 | org-element-radio-target-successor876 0.002672 3.051...e-06 | org-outline-level 876 0.001801 2.055...e-06 | org-element-time-stamp-parser 93 0.001642 1.766...e-05 | orgntf-make-todo
