[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-ann
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 ] > > > 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 wrote: > Hi Dave, > > At Fri, 17 Feb 2012 22:48:13 -1000, > Dave Abrahams wrote: >> >> [1 ] >> >> >> 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 wrote: > > > Hi Dave, > > > > At Fri, 17 Feb 2012 22:48:13 -1000, > > Dave Abrahams wrote: > >> > >> [1 ] > >> > >> > >> 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 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 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 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 wrote: > >> Leo Alekseyev 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 #", >> > 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 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 < 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 - 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 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 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 fil
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 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 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 writes: > Hi Eric, > > Eric Schulte wrote: > >> Viktor Rosenfeld 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 wrote: > on Sat Feb 25 2012, David Maus wrote: > >> Hi Dave, >> >> At Fri, 17 Feb 2012 22:48:13 -1000, >> Dave Abrahams wrote: >>> >>> [1 ] >>> >>> >>> 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 wrote: > Jambunathan K 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 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 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 | orgnt
