Re: [O] Bugs/features of accumulating property values when used with entries (concretely: in org-contacts)
Hi Christophe, Eric and Thomas, Eric Schulte wrote: Christoph LANGE ch.la...@jacobs-university.de writes: 2011-12-26 15:50 Sebastien Vauban: Christoph LANGEch.la...@jacobs-university.de writes: 2. accumulation doesn't work within the same entry; details follow: So when I changed the above contact entry to * Contact Name :PROPERTIES: :EMAIL:f...@bar.org :EMAIL+: b...@baz.org :END: I would have expected (org-entry-get (point) EMAIL t) to evaluate to, well, at least f...@bar.org b...@baz.org (and in some later version of org-mode maybe to a two-item list, for even easier automated processing). But I got the following unexpected results, which indicate that accumulation is not yet supported in this context (well, if it was ever _intended_…): See the attached file for an example of working property inheritance. [...] * Contact Name :PROPERTIES: :FOO:1 :FOO+: 2 :END: #+begin_src emacs-lisp (org-entry-get (point) FOO 'inherit) #+end_src #+results: : 1 While it is not possible to accumulate two properties from within the same block, property accumulation does successfully add to the inherited values of variables. I don't know if it should be possible to accumulate properties within the same property block. I would imagine so, in which case the behavior should be considered a bug. I would say so (that it's a bug), as doing it on a file-basis (within the same property block) is well supported: #+PROPERTY: FOO 1 #+PROPERTY: FOO+ 2 * Contact Name #+begin_src emacs-lisp (org-entry-get (point) FOO 'inherit) #+end_src #+results: : 1 2 … AFAIK the `+' is only supported at this stage for the `var' property: you can't take any property and add a `+' to FALSE, the var property is in no way special when it comes to property inheritance. All properties are treated equally. Sorry for insinuating it otherwise. And thanks for the correction! Best regards, Seb -- Sebastien Vauban
[O] About the use of PROPERTY meta lines...
#+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. 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. Best regards, Seb -- Sebastien Vauban
Re: [O] Location of OpenDocument style files should be configurable
Am 29.12.2011 12:24, schrieb Ulrich Mueller: Now org-odt.el currently defines org-odt-styles-dir in a defconst, and it searches only in ../etc/styles/, ./etc/styles/, and ./etc/org/ relative to lispdir. Obviously it cannot find the files in the Gentoo location. IMHO, an _installed_ org mode should never heuristically search any support files -- the location should either be recorded into org-install.el as a constant or made configurable as a defcustom, whichever is more appropriate. Now my question, could the defconst be changed to a defvar, so that we can specify the location in our site-start file? Or, preferably, could the etcdir specified in make command be honoured in the lisp code? Jambunathan will have to answer that, but a defvar seems the wrong solution to this problem. Also site-start should probably not be (mis-)used to configure the behaviour of packages that the user may not actually use. Making use of variables set in the Makefile is possible, but I would not recommend to do this in any other file except org-install.el. -- Achim. (on the road :-)
Re: [O] Location of OpenDocument style files should be configurable
On Thu, 29 Dec 2011, Achim Gratz wrote: IMHO, an _installed_ org mode should never heuristically search any support files -- the location should either be recorded into org-install.el as a constant or made configurable as a defcustom, whichever is more appropriate. Such heuristic searches are not uncommon in other elisp packages. But I agree that it's the wrong approach. If the location is known at build time, then it should be recorded somewhere in the lisp code. Now my question, could the defconst be changed to a defvar, so that we can specify the location in our site-start file? Or, preferably, could the etcdir specified in make command be honoured in the lisp code? Jambunathan will have to answer that, but a defvar seems the wrong solution to this problem. Also site-start should probably not be (mis-)used to configure the behaviour of packages that the user may not actually use. Well, we don't configure the behaviour, but just fix a wrong path. Also Gentoo's site-start file requires org-install if org-mode is installed on the user's system. So, for the user there won't be a visible difference if the path is defined in org-install or in site-start. Of course, it is preferred if the upstream package gets things right, so that we don't have to adjust them on the distro level. Ulrich
Re: [O] just made orgmode-7.8.02
Then perhaps something more is wrong. I downloaded orgmode-7.8.02 and
installed that after having run the standard gitclone command to clone
org-mode on this system. I did that because the gitclone process pulled
version 5.23 for me and also created my git repository for me in that
process. I don't know how or why that happened but it was a satellite
connection yesterday and not my usual cable connection.On Thu, 29 Dec
2011, Nick Dokos wrote:
Jude DaShiell jdash...@shellworld.net wrote:
Once that was done I figured to run make ./update in the org-7.8.02
directory and get the latest patches. No cigar, this isn't within any git
repository apparently on my end so couldn't be pulled by make ./update.
Do I need to edit the Makefile to clear this problem and if so how? If
not, how do I get this version to the update capability?
You need to clone the git repository:
git clone git://orgmode.org/org-mode.git
/path/to/your/local/org/mode/git/repository
before you can use the update target in the Makefile, which just does a git
pull
before remaking:
,
| ...
| update:
| git pull
| ${MAKE} clean
| ${MAKE} all
| ...
`
Note that the /path/to/your/local/org/mode/git/repository must not exist
beforehand:
it is created by the cloning process. And, of course, you need to have git
installed.
Nick
Jude jdashiel-at-shellworld-dot-net
http://www.shellworld.net/~jdashiel/nj.html
[O] Problem with noweb-ref property
Hi list, This is my first post, so just let me say first that I have been using org-mode for 10 months or so and I love it. It's an exceptional package, and before I ask my question I would just like to thank Carsten, Bastien, and the community for the great work and for sharing. Now my question: I am trying to extract code from a .org file by tangling with noweb-style references. As I understand from the manual, if I write foo in a code block, the line will be expanded with the code block named foo. This name I can set with #+NAME: or with the :noweb-ref header argument. Both ways work for me, except that I cannont set the :noweb-ref argument through a property. The following example is almost verbatim from the manual: #+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh fullest-disk #+END_SRC * the mount point of the fullest disk ** query all mounted disks #+HEADER: :noweb-ref fullest-disk #+BEGIN_SRC sh df \ #+END_SRC ** strip the header row :PROPERTIES: :noweb-ref: fullest-disk :END: #+BEGIN_SRC sh :noweb yes |sed '1d' \ #+END_SRC If I understand correctly, tangling should produce a file which is a concatenation of the two code blocks. However, when I do org-babel-tangle, only the first block is inserted. Am I doing something wrong? I'm with emacs 23.2.1 and org-mode 7.8.02 Thanks in advance, Tomas
Re: [O] just made orgmode-7.8.02
Jude DaShiell jdash...@shellworld.net wrote:
Then perhaps something more is wrong. I downloaded orgmode-7.8.02 and
installed that after having run the standard gitclone command to clone
org-mode on this system. I did that because the gitclone process pulled
version 5.23 for me and also created my git repository for me in that
process. I don't know how or why that happened but it was a satellite
connection yesterday and not my usual cable connection.
Oy, vey: that is pretty weird.
Just delete the whole cloned repository and clone again. I just did that
and git describe says:
,
| $ git describe
| release_7.8.02-53-g88ef5fe
`
Nick
On Thu, 29 Dec
2011, Nick Dokos wrote:
Jude DaShiell jdash...@shellworld.net wrote:
Once that was done I figured to run make ./update in the org-7.8.02
directory and get the latest patches. No cigar, this isn't within any
git
repository apparently on my end so couldn't be pulled by make ./update.
Do I need to edit the Makefile to clear this problem and if so how? If
not, how do I get this version to the update capability?
You need to clone the git repository:
git clone git://orgmode.org/org-mode.git
/path/to/your/local/org/mode/git/repository
before you can use the update target in the Makefile, which just does a git
pull
before remaking:
,
| ...
| update:
| git pull
| ${MAKE} clean
| ${MAKE} all
| ...
`
Note that the /path/to/your/local/org/mode/git/repository must not exist
beforehand:
it is created by the cloning process. And, of course, you need to have git
installed.
Nick
Jude jdashiel-at-shellworld-dot-net
http://www.shellworld.net/~jdashiel/nj.html
[O] Clock time implied as 00:00
Hi, Org people. This morning, I just noticed this line: CLOCK: [2011-12-29 jeu 9:30]--[2011-12-29 jeu 11:44] = 11:44 because of the strange 11:44 total. My error is clear, as I wrote 9:30 instead of 09:30. Correcting it gives a move reasonable total: CLOCK: [2011-12-29 jeu 09:30]--[2011-12-29 jeu 11:44] = 2:14 Yet, forgetting a leading 0 is an easy mistake (I know I should not make mistakes!), and then, maybe (I'm not sure) Org mode could deliver unexpected or misleading statistics out of a silent error. Not such a problem for me, yet it could have become one if I missed it. Would it be reasonable to suggest that Org mode be more lenient about missing leading zeroes? François P.S. I wish every one is enjoying the Festive Times!
[O] Location of OpenDocument style files should be configurable
Hi, In Gentoo we have an issue with the location of the OpenDocument style files, reported to us in bug 396269 [1]. When org-mode is installed as a separate Gentoo package, its lisp files are installed in /usr/share/emacs/site-lisp/org-mode/. According to our policy, non-lisp files would go to /usr/share/emacs/etc/org-mode/. We would pass this as the etcdir parameter to make install, so the odt style files would be installed in stylesdir = /usr/share/emacs/etc/org-mode/styles/. Now org-odt.el currently defines org-odt-styles-dir in a defconst, and it searches only in ../etc/styles/, ./etc/styles/, and ./etc/org/ relative to lispdir. Obviously it cannot find the files in the Gentoo location. Now my question, could the defconst be changed to a defvar, so that we can specify the location in our site-start file? Or, preferably, could the etcdir specified in make command be honoured in the lisp code? Ulrich [1] https://bugs.gentoo.org/show_bug.cgi?id=396269
Re: [O] Location of OpenDocument style files should be configurable
Hello Ulrich Hi, In Gentoo we have an issue with the location of the OpenDocument style files, reported to us in bug 396269 [1]. Makefile in org-7.8.02 is buggy and breaks the ODT exporter. Bastien, is likely to re-publish a version of org-7.8.x soon. Lately, there has been some confusion around how and where OpenDocument style files go. There have also been multiple bug reports surrounding broken export. When org-mode is installed as a separate Gentoo package, its lisp files are installed in /usr/share/emacs/site-lisp/org-mode/. According to our policy, non-lisp files would go to /usr/share/emacs/etc/org-mode/. We would pass this as the etcdir parameter to make install, so the odt style files would be installed in stylesdir = /usr/share/emacs/etc/org-mode/styles/. Org-7.8.x has been accepted in to Emacs-24.1 [1]. I have proposed that the style files go as c:/Program Files/emacs-24.0.92/etc/org/*.xml [2]. Note that under stock Emacs, the org package go under org subdir. (locate-library org.elc) = c:/Program Files/emacs-24.0.92/lisp/org/org.elc So, will it be acceptable, if org-odt.el searches for styles file under wherever-org-odt.elc-is/../../etc/org/. (For vanilla Emacs, this is same as `data-directory'/etc/org. See C-h v data-directory) This way the package structure under gentoo will parallel the structure under stock Emacs. I am copying Sebastien (the debian maintainer) and Dave (who fixed the Makefile subsequent to 7.8.02) release. If there is consensus, I will fix org-odt.el and also Makefile. Side Note: I am little bit hesitant to make org-odt-styles-dir a defcustom. Already there are defcustoms for org-export-odt-styles-file and org-export-odt-content-template-file and making org-odt-styles-dir will add needless confusion to the users. Jambunathan K. Footnotes: [1] http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00607.html [2] http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00571.html Now org-odt.el currently defines org-odt-styles-dir in a defconst, and it searches only in ../etc/styles/, ./etc/styles/, and ./etc/org/ relative to lispdir. Obviously it cannot find the files in the Gentoo location. Now my question, could the defconst be changed to a defvar, so that we can specify the location in our site-start file? Or, preferably, could the etcdir specified in make command be honoured in the lisp code? Ulrich [1] https://bugs.gentoo.org/show_bug.cgi?id=396269 --
Re: [O] Enhancing table cell alignments and commenting columns (was Re: Orthogonality of blocks)
I am wrong, the issue is not with the LibreOffice but with my memory. The srcblocks are actually aligned centrally (along the vertical axis) within the table cell. Since the two blocks are of different sizes/lengths the top border gets staggered. Changing the alignment to top will fix the issue. I have pushed a fix to this effect. Table cells will now be top-aligned by default in ODT export. --
Re: [O] Clock time implied as 00:00
François Pinard pin...@iro.umontreal.ca wrote: Hi, Org people. This morning, I just noticed this line: CLOCK: [2011-12-29 jeu 9:30]--[2011-12-29 jeu 11:44] = 11:44 because of the strange 11:44 total. My error is clear, as I wrote 9:30 instead of 09:30. Correcting it gives a move reasonable total: CLOCK: [2011-12-29 jeu 09:30]--[2011-12-29 jeu 11:44] = 2:14 Yet, forgetting a leading 0 is an easy mistake (I know I should not make mistakes!), and then, maybe (I'm not sure) Org mode could deliver unexpected or misleading statistics out of a silent error. Not such a problem for me, yet it could have become one if I missed it. Would it be reasonable to suggest that Org mode be more lenient about missing leading zeroes? IMO, yes. This looks like a bug in org-parse-time-string which is supposed to be an optimized parse-time-string, but look: , | (setq ts 2011-12-29 Thu 2:11) | 2011-12-29 Thu 2:11 | | (parse-time-string ts) | (0 11 2 29 12 2011 4 nil nil) | (org-parse-time-string ts) | (0 0 0 29 12 2011 nil nil nil) ` Nick François P.S. I wish every one is enjoying the Festive Times!
Re: [O] just made orgmode-7.8.02
Jude DaShiell jdash...@shellworld.net wrote:
Once that was done I figured to run make ./update in the org-7.8.02
directory and get the latest patches. No cigar, this isn't within any git
repository apparently on my end so couldn't be pulled by make ./update.
Do I need to edit the Makefile to clear this problem and if so how? If
not, how do I get this version to the update capability?
You need to clone the git repository:
git clone git://orgmode.org/org-mode.git
/path/to/your/local/org/mode/git/repository
before you can use the update target in the Makefile, which just does a git pull
before remaking:
,
| ...
| update:
| git pull
| ${MAKE} clean
| ${MAKE} all
| ...
`
Note that the /path/to/your/local/org/mode/git/repository must not exist
beforehand:
it is created by the cloning process. And, of course, you need to have git
installed.
Nick
Re: [O] Location of OpenDocument style files should be configurable
On Thu, 29 Dec 2011, Jambunathan K wrote:
According to our policy, non-lisp files would go to
/usr/share/emacs/etc/org-mode/. We would pass this as the etcdir
parameter to make install, so the odt style files would be
installed in stylesdir = /usr/share/emacs/etc/org-mode/styles/.
Org-7.8.x has been accepted in to Emacs-24.1 [1]. I have proposed that
the style files go as c:/Program Files/emacs-24.0.92/etc/org/*.xml
[2]. Note that under stock Emacs, the org package go under org subdir.
(locate-library org.elc) = c:/Program
Files/emacs-24.0.92/lisp/org/org.elc
So, will it be acceptable, if org-odt.el searches for styles file
under wherever-org-odt.elc-is/../../etc/org/. (For vanilla Emacs,
this is same as `data-directory'/etc/org. See C-h v data-directory)
This way the package structure under gentoo will parallel the
structure under stock Emacs.
Gentoo policy is to install auxiliary (non-lisp) files under
/usr/share/emacs/etc/${PN}/ where PN is the package name. The Gentoo
package is named org-mode not org.
And I guess you'll not be able to catch all possible cases by adding
even more paths like ../../etc/org/ to the heuristics of your search.
Such a solution looks like a dead end to me.
I am copying Sebastien (the debian maintainer) and Dave (who fixed
the Makefile subsequent to 7.8.02) release. If there is consensus,
I will fix org-odt.el and also Makefile.
Side Note: I am little bit hesitant to make org-odt-styles-dir a
defcustom. Already there are defcustoms for org-export-odt-styles-file
and org-export-odt-content-template-file and making org-odt-styles-dir
will add needless confusion to the users.
I wasn't asking for a defcustom, a defvar for org-odt-styles-dir would
be sufficient and wouldn't add confusion for users. This way, we could
simply setq the variable in our site-init file.
On the long term, another solution would be to collect all
Makefile-configurable paths (lispdir, stylesdir, etc.) in a file
org-paths.el that would be auto-generated by make.
Ulrich
[O] just made orgmode-7.8.02
Once that was done I figured to run make ./update in the org-7.8.02 directory and get the latest patches. No cigar, this isn't within any git repository apparently on my end so couldn't be pulled by make ./update. Do I need to edit the Makefile to clear this problem and if so how? If not, how do I get this version to the update capability? Jude jdashiel-at-shellworld-dot-net http://www.shellworld.net/~jdashiel/nj.html
Re: [O] Problem with noweb-ref property
Tomas Grigera tgrig...@gmail.com writes: Hi list, This is my first post, so just let me say first that I have been using org-mode for 10 months or so and I love it. It's an exceptional package, and before I ask my question I would just like to thank Carsten, Bastien, and the community for the great work and for sharing. Now my question: I am trying to extract code from a .org file by tangling with noweb-style references. As I understand from the manual, if I write foo in a code block, the line will be expanded with the code block named foo. This name I can set with #+NAME: or with the :noweb-ref header argument. Both ways work for me, except that I cannont set the :noweb-ref argument through a property. The following example is almost verbatim from the manual: #+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh fullest-disk #+END_SRC * the mount point of the fullest disk ** query all mounted disks #+HEADER: :noweb-ref fullest-disk #+BEGIN_SRC sh df \ #+END_SRC ** strip the header row :PROPERTIES: :noweb-ref: fullest-disk :END: #+BEGIN_SRC sh :noweb yes |sed '1d' \ #+END_SRC If I understand correctly, tangling should produce a file which is a concatenation of the two code blocks. However, when I do org-babel-tangle, only the first block is inserted. Am I doing something wrong? I'm with emacs 23.2.1 and org-mode 7.8.02 Thanks in advance, Tomas Hi Tomas, You are correct the behavior described above is a bug introduced by a fairly recent commit of mine which switched to using regular expressions when resolving noweb references in an attempt to decrease the time required to tangle code blocks (which can be significant in large code blocks). However correct performance is more important than fast performance. I've just pushed up a patch which fixes the bug you've described, and hopefully doesn't slow down the tangling process too significantly. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] Problems exporting org-babel to HTML
Hi Org-Moders, I've got a problem with org-babel HTML exports and I wonder if you can help me. I'm using an up-to-date debian emacs-snapshot as follows: - GNU Emacs 24.0.92.1 (x86_64-pc-linux-gnu, GTK+ Version 3.2.3) of 2011-12-27 on zelenka, modified by Debian - Org-mode version 7.7 The problem manifests itself when exporting in batch mode (please see below for source org file): shell output $ /usr/bin/emacs-snapshot --batch --visit=test.org --funcall org-export-as-html-batch Loading 00debian-vars... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50cmake-data.el (source)... Loading /etc/emacs/site-start.d/50devhelp.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Skipping dictionaries-common setup for emacs-snapshot Loading /etc/emacs/site-start.d/50global.el (source)... Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)... Loading /etc/emacs/site-start.d/50psvn.el (source)... Exporting... Symbol's function definition is void: copy-seq /shell output This error is very similar to what is described here: - http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01203.html - #634695: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634695 However, from reading that thread it appears I should already have this fix. Can you please confirm if this is the case? Also, if v7.7 does not have the fix, is there a workaround? The org-file i'm using is as follows: org_file #+tblname: test_chart | Day | Expected | Actual | |-+--+| | 0 |8 | 8 | | 1 |7 | 8 | | 2 |6 | 8 | | | || #+begin_src gnuplot :var data=test_chart :file test.png :exports both reset set termoption dash set terminal png font /usr/share/fonts/truetype/inconsolata/Inconsolata.otf 14 set title Test Chart set auto x set border linewidth 1.5 set style line 1 linecolor rgb red linetype 2 linewidth 3 pointtype 1 set style line 2 linecolor rgb orange linetype 2 linewidth 3 pointtype 1 set ylabel Story Points set yrange [0:10] set ytics 0,1,10 set xlabel Time set xrange [0:15] set xtics 0,1,15 plot data using 1 title 'Expected' linestyle 1 with lines, \ data using 2 title 'Actual' linestyle 2 with lines #+end_src #+results: [[file:test_chart.png]] /org_file Thanks for a wonderful piece of software and for your time. marco
[O] Export visible part of tree to latex
Hi all,
I have an org file with this structure:
* head
** topic 1 :topic:
*** foo
some foo :foo:
*** bar
some bar :bar:
** topic 2
*** foo
some other foo :foo:
*** bar
some other bar :bar:
and I would like to collect all entries with the tag foo and export them to a
latex file. I have the variable org-show-hierarchy-above set to nil, so f I
run C-c \ foo, I get this:
* head...
some foo
:foo:...
some other foo
:foo:...
which is exactly what I would like to export. But when I go to export using
C-c C-e v l, the resulting latex file doesn't contain any of the entries below
the top (head) level:
% Created 2011-12-29 Thu 12:47
\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}
\usepackage{fixltx2e}
\usepackage{graphicx}
\usepackage{longtable}
\usepackage{float}
\usepackage{wrapfig}
\usepackage{soul}
\usepackage{textcomp}
\usepackage{marvosym}
\usepackage{wasysym}
\usepackage{latexsym}
\usepackage{amssymb}
\usepackage{hyperref}
\tolerance=1000
\usepackage{fullpage}
\providecommand{\alert}[1]{\textbf{#1}}
\title{org}
\author{John MacCallum}
\date{\today}
\hypersetup{
pdfkeywords={},
pdfsubject={},
Re: [O] Problems exporting org-babel to HTML
Hi Marco, Please update to the latest version of Org-mode available from git at http://orgmode.org/org-mode-download.html and let us know if the problem persists. Cheers, Marco Craveiro marco.crave...@gmail.com writes: Hi Org-Moders, I've got a problem with org-babel HTML exports and I wonder if you can help me. I'm using an up-to-date debian emacs-snapshot as follows: - GNU Emacs 24.0.92.1 (x86_64-pc-linux-gnu, GTK+ Version 3.2.3) of 2011-12-27 on zelenka, modified by Debian - Org-mode version 7.7 The problem manifests itself when exporting in batch mode (please see below for source org file): shell output $ /usr/bin/emacs-snapshot --batch --visit=test.org --funcall org-export-as-html-batch Loading 00debian-vars... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50cmake-data.el (source)... Loading /etc/emacs/site-start.d/50devhelp.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Skipping dictionaries-common setup for emacs-snapshot Loading /etc/emacs/site-start.d/50global.el (source)... Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)... Loading /etc/emacs/site-start.d/50psvn.el (source)... Exporting... Symbol's function definition is void: copy-seq /shell output This error is very similar to what is described here: - http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01203.html - #634695: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634695 However, from reading that thread it appears I should already have this fix. Can you please confirm if this is the case? Also, if v7.7 does not have the fix, is there a workaround? The org-file i'm using is as follows: org_file #+tblname: test_chart | Day | Expected | Actual | |-+--+| | 0 |8 | 8 | | 1 |7 | 8 | | 2 |6 | 8 | | | || #+begin_src gnuplot :var data=test_chart :file test.png :exports both reset set termoption dash set terminal png font /usr/share/fonts/truetype/inconsolata/Inconsolata.otf 14 set title Test Chart set auto x set border linewidth 1.5 set style line 1 linecolor rgb red linetype 2 linewidth 3 pointtype 1 set style line 2 linecolor rgb orange linetype 2 linewidth 3 pointtype 1 set ylabel Story Points set yrange [0:10] set ytics 0,1,10 set xlabel Time set xrange [0:15] set xtics 0,1,15 plot data using 1 title 'Expected' linestyle 1 with lines, \ data using 2 title 'Actual' linestyle 2 with lines #+end_src #+results: [[file:test_chart.png]] /org_file Thanks for a wonderful piece of software and for your time. marco -- Eric Schulte http://cs.unm.edu/~eschulte/
Re: [O] just made orgmode-7.8.02
We're now golden. When I ran git describe I was told no repository exists. So I ran git init and created an empty repository and then ran the git clone command and this time aI have an installed version of 7.8.02 and am told I'm up to date. Apparently running a git clone operation on slackware 13.0 without having an existing repository for git to populate makes git a very unhappy camper. Jude jdashiel-at-shellworld-dot-net http://www.shellworld.net/~jdashiel/nj.html
Re: [O] just made orgmode-7.8.02
On Thu, Dec 29, 2011 at 3:12 PM, Jude DaShiell jdash...@shellworld.netwrote: We're now golden. When I ran git describe I was told no repository exists. So I ran git init and created an empty repository and then ran the git clone command and this time aI have an installed version of 7.8.02 and am told I'm up to date. Apparently running a git clone operation on slackware 13.0 without having an existing repository for git to populate makes git a very unhappy camper. You're just trying to clone the orgmode repo? You shouldn't need to do 'git init.' That's used when you want to create a local git repo from your own, pre-existing files. You're just trying to pull from a remote repository. ,--- | $ git clone git://orgmode.org/org-mode.git `--- Should work on it's own from any directory and will create a new directory populated with the orgmode git tree. Git should work, regardless of the distro. Can you try again? If you'e like, try cd-ing to a directory where you want this to live and executing: ,--- | $ git clone git://orgmode.org/org-mode.git org.git `--- See what happens. If you get errors, post the exact output to the list and others should be able to help. Thanks! John Jude jdashiel-at-shellworld-dot-net http://www.shellworld.net/~jdashiel/nj.html
Re: [O] Problems exporting org-babel to HTML
Hi Eric, Thanks for the prompt reply. I was trying hard to avoid dependencies on anything other than vanilla debian actually. If there is no other way around it, I'll try and use git latest... Thanks Marco On Thu, 2011-12-29 at 14:10 -0700, Eric Schulte wrote: Hi Marco, Please update to the latest version of Org-mode available from git at http://orgmode.org/org-mode-download.html and let us know if the problem persists. Cheers, Marco Craveiro marco.crave...@gmail.com writes: Hi Org-Moders, I've got a problem with org-babel HTML exports and I wonder if you can help me. I'm using an up-to-date debian emacs-snapshot as follows: - GNU Emacs 24.0.92.1 (x86_64-pc-linux-gnu, GTK+ Version 3.2.3) of 2011-12-27 on zelenka, modified by Debian - Org-mode version 7.7 The problem manifests itself when exporting in batch mode (please see below for source org file): shell output $ /usr/bin/emacs-snapshot --batch --visit=test.org --funcall org-export-as-html-batch Loading 00debian-vars... Loading /etc/emacs/site-start.d/50autoconf.el (source)... Loading /etc/emacs/site-start.d/50cmake-data.el (source)... Loading /etc/emacs/site-start.d/50devhelp.el (source)... Loading /etc/emacs/site-start.d/50dictionaries-common.el (source)... Skipping dictionaries-common setup for emacs-snapshot Loading /etc/emacs/site-start.d/50global.el (source)... Loading /etc/emacs/site-start.d/50gtk-doc-tools.el (source)... Loading /etc/emacs/site-start.d/50psvn.el (source)... Exporting... Symbol's function definition is void: copy-seq /shell output This error is very similar to what is described here: - http://lists.gnu.org/archive/html/emacs-orgmode/2011-07/msg01203.html - #634695: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634695 However, from reading that thread it appears I should already have this fix. Can you please confirm if this is the case? Also, if v7.7 does not have the fix, is there a workaround? The org-file i'm using is as follows: org_file #+tblname: test_chart | Day | Expected | Actual | |-+--+| | 0 |8 | 8 | | 1 |7 | 8 | | 2 |6 | 8 | | | || #+begin_src gnuplot :var data=test_chart :file test.png :exports both reset set termoption dash set terminal png font /usr/share/fonts/truetype/inconsolata/Inconsolata.otf 14 set title Test Chart set auto x set border linewidth 1.5 set style line 1 linecolor rgb red linetype 2 linewidth 3 pointtype 1 set style line 2 linecolor rgb orange linetype 2 linewidth 3 pointtype 1 set ylabel Story Points set yrange [0:10] set ytics 0,1,10 set xlabel Time set xrange [0:15] set xtics 0,1,15 plot data using 1 title 'Expected' linestyle 1 with lines, \ data using 2 title 'Actual' linestyle 2 with lines #+end_src #+results: [[file:test_chart.png]] /org_file Thanks for a wonderful piece of software and for your time. marco
[O] mailto link problem
This might be off-topic, but there has been discussion about this issue before on this list. http://comments.gmane.org/gmane.emacs.orgmode/22550 The problem is that the above discussion doesn't solve my problem. So here it is. On my old system (Ubuntu 10.04, Emacs 23.3, Org-Mode 7.8.02, default browser Firefox, default mail client Thunderbird), I could click on a mailto link in an org file and Firefox would open up Thunderbird. I could then put in the message and send it via Thunderbird. No problems. On my new system (Xubuntu 11.10, Emacs 24.0.92.1, Org-Mode 7.8.02, default browser Firefox, default mail client Thunderbird), an Emacs window in message-mode is opened when I click on a mailto link in an org-mode file. This is not what I want, I want the behavior to be like it was in my old system. My old system just worked without me customizing any variables. I didn't change org-follow-link, org-link-mailto-program, mail-user-agent, etc. I didn't mess around with /etc/mailcap or other stuff. The Emacs variables on my new system are identical to those I used with my old system and the html stuff in /etc/mailcap looks identical. I don't understand why the two systems behave differently. Please don't suggest that I switch to Gnus or something. I don't have time to switch, Thunderbird is easy to set up, it handles HTML well, it reads feeds nicely, and I use the External Editor plug-in (http://globs.org/articles.php?pg=2lng=en) and emacsclient to write my email using Emacs (as I am doing now). I keep my email addresses in org files and I would like to be able to just click on a mailto link to connect to Thunderbird instead of doing a kill and yank routine.
Re: [O] just made orgmode-7.8.02
On 12/29/2011 07:02 PM, Jude DaShiell wrote: Then perhaps something more is wrong. I downloaded orgmode-7.8.02 and installed that after having run the standard gitclone command to clone org-mode on this system. I did that because the gitclone process pulled version 5.23 for me and also created my git repository for me in that process. I don't know how or why that happened but it was a satellite connection yesterday and not my usual cable connection. Maybe you're cloning the right repository but ending up using the shipped version in Emacs anyway? What is your configuration to use git org-mode from the git repository?
Re: [O] mailto link problem
Scott Randby sran...@gmail.com wrote: ... On my new system (Xubuntu 11.10, Emacs 24.0.92.1, Org-Mode 7.8.02, default browser Firefox, default mail client Thunderbird), an Emacs window in message-mode is opened when I click on a mailto link in an org-mode file. This is not what I want, I want the behavior to be like it was in my old system. So what is the value of org-link-mailto-program? Mine says , | org-link-mailto-program is a variable defined in `org.el'. | Its value is (browse-url mailto:%a?subject=%s;) ` and if that's the case for you as well, then org is off the hook: you have to look downstream from browse-url to figure out where it's going off the rails. In particular, check if browse-url-mailto-function is set: if it is, try setting it to nil and see if that gets things back on track (not tested, not guaranteed). Nick
Re: [O] mailto link problem
On 12/29/2011 05:42 PM, Nick Dokos wrote: and if that's the case for you as well, then org is off the hook: you have to look downstream from browse-url to figure out where it's going off the rails. In particular, check if browse-url-mailto-function is set: if it is, try setting it to nil and see if that gets things back on track (not tested, not guaranteed). Setting browse-url-mailto-function to nil worked. That must be a new variable for Emacs 24. At least it isn't in the browse-url group of Emacs 23.3. Its default value is emacs-mail. Thanks a bunch, I only spent most of today trying to figure out this issue. Scott
Re: [O] mailto link problem
On 12/29/2011 05:55 PM, Nick Dokos wrote: One more thing - try the following from the command line: firefox --remote openURL(mailto:sran...@gmail.com) If that gets you back into emacs, then emacs is off the hook: a visit to about:config in firefox is indicated. Good suggestion. I had already checked to make sure that Firefox would open a mailto url in Thunderbird, but I didn't do it via the command line. I'd never thought about running Firefox from the command line. Scott
Re: [O] Problem with noweb-ref property
Hi Eric, Thanks a lot for your quick reply and fix. Getting the git repo version scares me a bit, but I guess I'll just have to take the plunge! Here we go :) Thanks again, Tomas On Thu, Dec 29, 2011 at 16:51, Eric Schulte eric.schu...@gmx.com wrote: Tomas Grigera tgrig...@gmail.com writes: Hi list, This is my first post, so just let me say first that I have been using org-mode for 10 months or so and I love it. It's an exceptional package, and before I ask my question I would just like to thank Carsten, Bastien, and the community for the great work and for sharing. Now my question: I am trying to extract code from a .org file by tangling with noweb-style references. As I understand from the manual, if I write foo in a code block, the line will be expanded with the code block named foo. This name I can set with #+NAME: or with the :noweb-ref header argument. Both ways work for me, except that I cannont set the :noweb-ref argument through a property. The following example is almost verbatim from the manual: #+BEGIN_SRC sh :tangle yes :noweb yes :shebang #!/bin/sh fullest-disk #+END_SRC * the mount point of the fullest disk ** query all mounted disks #+HEADER: :noweb-ref fullest-disk #+BEGIN_SRC sh df \ #+END_SRC ** strip the header row :PROPERTIES: :noweb-ref: fullest-disk :END: #+BEGIN_SRC sh :noweb yes |sed '1d' \ #+END_SRC If I understand correctly, tangling should produce a file which is a concatenation of the two code blocks. However, when I do org-babel-tangle, only the first block is inserted. Am I doing something wrong? I'm with emacs 23.2.1 and org-mode 7.8.02 Thanks in advance, Tomas Hi Tomas, You are correct the behavior described above is a bug introduced by a fairly recent commit of mine which switched to using regular expressions when resolving noweb references in an attempt to decrease the time required to tangle code blocks (which can be significant in large code blocks). However correct performance is more important than fast performance. I've just pushed up a patch which fixes the bug you've described, and hopefully doesn't slow down the tangling process too significantly. Cheers, -- Eric Schulte http://cs.unm.edu/~eschulte/
[O] [babel] noweb with ob-screen??
Hi this is a follow up on a early post. I try to get noweb working with ob-screen. I wrote several code blocks and named them. I finished with a code block which calls all other blocks using noweb notation adding to its header :noweb yes. I execute this block by C-c C-c but the noweb reference get not resolved. In my understanding they should isn't it? Or do I mix tangling and execution? In my understanding noweb should work for both cases isn't it? I looked in the source code of ob-screen and try to get an idea why it doesn't work. However compare to other babel modes I could not find that it is missing anything related to noweb. It seems to me that noweb is a babel mode independent functionality and hence should work with all babel languages. If I'm wrong could someone please point me to an example in the source code how to implement noweb functionality. Thanks a lot Torsten Cc. Sorry all this is written down from memory on my smartphone and hence no code examples and maybe wrong syntax.
[O] capture problem
Aloha all, 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). All the best, Tom -- T.S. Dye Colleagues, Archaeologists 735 Bishop St, Suite 315, Honolulu, HI 96813 Tel: 808-529-0866, Fax: 808-529-0884 http://www.tsdye.com
