[O] Adding information to tangled code regarding org-source
When one exports from org to, say, latex the resulting *.tex file includes a comment at the top indicating the time of creation. This is useful in part because it lets the user know that the *.tex file isn't the original source. The same isn't true of tangled code from a source block, and I've been repeatedly bitten by editing a file of python code that was tangled from a source org file. I'd like to deal with this by making tangle emit a comment with information about the org-source file. The :prologue header argument is well suited to this; e.g., #+begin_src python :tangle /tmp/test.py :prologue (format "# Tangled from %s on %s" (buffer-file-name) (current-time-string)) print "Hello, world!" #+end_src produces what one would want. I'd like to make this header argument be applied automatically. The variable org-babel-default-header-args looks like just the ticket, but my lame efforts to write the necessary emacs-lisp aren't working: #+BEGIN_SRC emacs-lisp (add-to-list 'org-babel-default-header-args:python '((:prologue . (format "# Tangled from %s on %s" (buffer- file-name) (current-time-string) #+END_SRC What am I doing wrong? Thanks for any help, -Ethan
[O] [PATCH] org.texi: Replace broken example script for batch execution
There is an example bash script in section 14.12 of the org manual which is meant to tangle source blocks from a supplied list of org files. The present version is broken in several small ways (it appears to date from a period when babel was still part of contrib), and requires a hard-coded specification of the path ORG_HOME. I've fixed the issue with ORG_HOME, another issue with grepping for strings that no longer are emitted by ob-tangle, and removed some obsolete dependencies. I'm finding the corrected script a useful thing to call from makefiles. -Ethan * doc/org.texi: Example bash script to tangle from *.org file was broken and obsolete; fixed to now work with recent versions of org. --- doc/org.texi | 14 ++ 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/doc/org.texi b/doc/org.texi index 8b8dc65..f935692 100644 --- a/doc/org.texi +++ b/doc/org.texi @@ -16838,14 +16838,12 @@ for i in $@@; do done emacs -Q --batch \ ---eval "(progn -(add-to-list 'load-path (expand-file-name \"~/src/org/lisp/\")) -(add-to-list 'load-path (expand-file-name \"~/src/org/contrib/lisp/\" t)) -(require 'org)(require 'org-exp)(require 'ob)(require 'ob-tangle) -(mapc (lambda (file) - (find-file (expand-file-name file \"$DIR\")) - (org-babel-tangle) - (kill-buffer)) '($FILES)))" 2>&1 |grep tangled + --eval "(progn + (require 'org)(require 'ob)(require 'ob-tangle) + (mapc (lambda (file) +(find-file (expand-file-name file \"$DIR\")) +(org-babel-tangle) +(kill-buffer)) '($FILES)))" 2>&1 |grep -i tangled @end example @node Miscellaneous
Re: [O] [RFC] Change \[..\] and $$...$$ into elements
Rasmus gmx.us> writes:
>
> Nicolas Goaziou nicolasgoaziou.fr> writes:
>
> > Hello,
> >
> > Rasmus gmx.us> writes:
> >
> >> What's wrong with equation (potentially coupled with mathtools for
> >> handling numbering automatically)? Is it worth breaking old documents
> >> (irrespective of org-lint) for this inconvenience?
> >
> > Actually, the idea behind this patch is to mimic the expected LaTeX
> > behaviour,i.e., treat \[..\] as an equivalent
> > to \begin{equation*}...\end{equation*}.
> >
> > This was requested at least once before, so I guess it may make sense
to
> > follow the path of least surprise.
>
> And I'm saying that people should just write:
>
> #+latex_header: \usepackage{mathtools} \mathtoolsset{showonlyrefs}
> aaa
> \begin{equation}
> bbb
> \end{equation}
> ccc
>
> Org isn't LaTeX and there’s no difference in the output from \[⋯\]
> and \begin{equation*}⋯\end{equation*} or the above.
>
> Nonetheless, I don't feel strongly about the (non)issue so if this
> behavior is better, somehow, go for it.
>
> Rasmus
>
At the risk of sounding flip, I've gotta say that the question of whether
#+begin_example
aaa
\[
bbb
\]
ccc
#+end_example
is "somehow better" than
#+begin_example
#+latex_header: \usepackage{mathtools} \mathtoolsset{showonlyrefs}
aaa
\begin{equation}
bbb
\end{equation}
ccc
#+end_example
sort of answers itself. It's not so much that we must make Org mimic
LaTeX; it's that people actually use Org to compose documents with
equations, and making this easier and simpler is a good thing.
-Ethan
Re: [O] [RFC] Change \[..\] and $$...$$ into elements
Nicolas Goaziou nicolasgoaziou.fr> writes: > > Hello, > > The following patch changes status for \[..\] and $$...$$ from objects > to elements. > I think I've already indicated my enthusiastic support for this change, but let me do it again! In /The TeXbook/ Donald Knuth writes that the markup for display math mode allows "your manuscript to mirror what you are trying to accomplish." I write all my manuscripts in org-mode these days, in large part because the mark-up is lighter-weight than it is for LaTeX, but at present the preferred markup for display equations does *not* really allow one to make the manuscript mirror what one is trying to do. Enthusiastic thanks and support for this patch! -Ethan
Re: [O] Problem with org-export--delete-comments
On Sun, Dec 20, 2015 at 1:29 AM Nicolas Goaziou wrote: > Hello, > > Ethan Ligon writes: > > > On Thu, Dec 17, 2015 at 12:47 PM Nicolas Goaziou > > > wrote: > > > >> Hello, > >> > >> Ethan Ligon writes: > >> > >> > I've long used the following construction for displayed equations in > org > >> > # > >> > \[ > >> > u_i(c)=p_i\lambda > >> > \] > >> > # > >> > which (i) gives nice space for reading equations in the org-source, > and > >> > (ii) nicely protects the display equation from (fill-paragraph) and > >> > friends. > >> > > >> > However, exporting with this construction *stopped* working after > commit > >> > 53a4209; what happens now is that ox.el replaces the # with a blank > line, > >> > breaking my single paragraph into three. > >> > >> I see only one paragraph above. Could you elaborate a bit? > >> > > > > Sure. If I export the above using ox-ascii, I obtain, in part: > > > > #+begin_example > > I've long used the following construction for displayed equations in org > > > > \[ u_i(c)=p_i\lambda \] > > > > which (i) gives nice space for reading equations in the org-source, and > > (ii) nicely protects the display equation from (fill-paragraph) and > > friends. > > #+end_example > > Actually this is consistent with the Org document. As explained > somewhere else in this thread, comments separate elements (e.g., > paragraphs). They cannot be inlined within a paragraph. This is exactly > what happens in the output. > > I think you are simply mis-using comments in this particular case. > > > Point taken, and I appreciate that you must have thought about this > quite > s> a lot. But I still wish for the old behavior, which would have simply > > deleted the # comment line. > > > > This would break SW's footnote example, but perhaps that (contrived? > maybe > > I don't understand his use case) problem could be addressed by changing > > the documentation. Right now the docs say that a footnote > > > > "ends at the next footnote definition, headline, or after two consecutive > > empty lines." > > > > Why not just change to > > > > "ends at the next footnote definition, headline, or two empty lines > > (consecutive, or with a comment)." > > This is not related to footnote syntax. We could find a similar example > in, e.g., plain lists. The problem is simply that comment syntax doesn't > fit for your use-case. > That's fair. That was simply a work-around I'd developed that worked until a few weeks ago, to solve the deeper problem you identify below... > > The simplest solution is to write a function handling commented lines > the way you want them to be handled and add it to > `org-export-before-processing-hook', e.g. (untested), > > (defun my-handle-comments () > (while (re-search-forward "^[ \t]*#\\( \\|$\\)" nil t) > (let ((element (org-element-at-point))) > (when (eq (org-element-type element) 'comment) > (delete-region (org-element-property :begin element) > (progn (goto-char (org-element-property :end > element)) > (skip-chars-backward " \t\n") > (line-beginning-position 2))) > Thanks! I really appreciate the help. > > Also, I have a dusty patch somewhere that promotes \[...\] and $$...$$ > to the rank of elements and prevent them from being filled. However, it > also means that these constructs are not recognized as math snippets > within a line anymore, e.g., > > Text \[1+1\] ... > > I'm not sure how much of an issue it is. Hence the dust. > > Well, I most certainly vote for applying your dusty patch. In my (admittedly LaTeX-centric) view the whole point of the distinction between \(\) and \[\] is that the former is meant to be an in-line construct, while the latter is meant to indicate a typographically distinct element. Thanks, -Ethan
Re: [O] Problem with org-export--delete-comments
Nicolas Goaziou nicolasgoaziou.fr> writes: > > Note that Org doesn't support comments within paragraphs since a comment > ends a paragraph. In this case, the export output matches the contents > of the document. > It seems odd that a comment ends a paragraph, but does not end a footnote! -Ethan
Re: [O] Problem with org-export--delete-comments
On Thu, Dec 17, 2015 at 12:47 PM Nicolas Goaziou wrote: > Hello, > > Ethan Ligon writes: > > > I've long used the following construction for displayed equations in org > > # > > \[ > > u_i(c)=p_i\lambda > > \] > > # > > which (i) gives nice space for reading equations in the org-source, and > > (ii) nicely protects the display equation from (fill-paragraph) and > > friends. > > > > However, exporting with this construction *stopped* working after commit > > 53a4209; what happens now is that ox.el replaces the # with a blank line, > > breaking my single paragraph into three. > > I see only one paragraph above. Could you elaborate a bit? > Sure. If I export the above using ox-ascii, I obtain, in part: #+begin_example I've long used the following construction for displayed equations in org \[ u_i(c)=p_i\lambda \] which (i) gives nice space for reading equations in the org-source, and (ii) nicely protects the display equation from (fill-paragraph) and friends. #+end_example While if I export via ox-latex I obtain in the *.tex source: #+begin_example I've long used the following construction for displayed equations in org \[ u_i(c)=p_i\lambda \] which (i) gives nice space for reading equations in the org-source, and (ii) nicely protects the display equation from (fill-paragraph) and friends. #+end_example It's really this last case that's a serious problem, since when compiled with LaTeX we get three paragraphs (too much vertical space between the first line and the displayed equation, and excruciatingly an improper indentation of the bit following the displayed equation (i.e., "which (i)..." is indented). > > > A related problem: one can no longer have commented lines in (at least > > some) property drawers. > > This is not possible indeed, per property drawers syntax. Also, I'd > rather not introduce comments in property drawers (I don't think this > was ever officially supported anyway). > > > It seems to me that the correct solution would have org-export--delete- > > comments actually delete a single line comment, not replace it with \n, > as > > was the case prior to the indicated commit. > > > > I gather that the change was introduced to deal with a bug observed by > > Samuel Wales (http://article.gmane.org/gmane.emacs.orgmode/102860; see > also > > below). His problem example involved incorrectly truncated footnotes > > (these are deemed to end after two blank lines). But it seems to me that > > the correct solution to his example is to delete *both* the commented > > line and the following blank line. > > Been there, done that. Your solution is not correct in all cases. E.g., > with the following document > > Paragra1 > # comment > > Paragraph2 > > removing both the comment and the blank line above gives you a single > paragraph, which doesn't match expectations. > > Point taken, and I appreciate that you must have thought about this quite a lot. But I still wish for the old behavior, which would have simply deleted the # comment line. This would break SW's footnote example, but perhaps that (contrived? maybe I don't understand his use case) problem could be addressed by changing the documentation. Right now the docs say that a footnote "ends at the next footnote definition, headline, or after two consecutive empty lines." Why not just change to "ends at the next footnote definition, headline, or two empty lines (consecutive, or with a comment)." Thanks for your work on this! -Ethan
[O] Problem with org-export--delete-comments
I've long used the following construction for displayed equations in org # \[ u_i(c)=p_i\lambda \] # which (i) gives nice space for reading equations in the org-source, and (ii) nicely protects the display equation from (fill-paragraph) and friends. However, exporting with this construction *stopped* working after commit 53a4209; what happens now is that ox.el replaces the # with a blank line, breaking my single paragraph into three. A related problem: one can no longer have commented lines in (at least some) property drawers. It seems to me that the correct solution would have org-export--delete- comments actually delete a single line comment, not replace it with \n, as was the case prior to the indicated commit. I gather that the change was introduced to deal with a bug observed by Samuel Wales (http://article.gmane.org/gmane.emacs.orgmode/102860; see also below). His problem example involved incorrectly truncated footnotes (these are deemed to end after two blank lines). But it seems to me that the correct solution to his example is to delete *both* the commented line and the following blank line. I regard this as a bug, but if it's not how do others deal with similar issues? Thanks, -Ethan Ligon * Sam Wales' example: commenting a paragraph will truncate footnotes in xanadu[fn:b3e0f07] um # comment [fn:b3e0f07] did kublai khan # was it "seemly"? a stately pleasure dome decree
Re: [O] odt import
Uwe Brauer mat.ucm.es> writes: > > Hello > > I just found in wikipedia > http://en.wikipedia.org/wiki/Org-mode > > Claiming there are tools to import _from_ ODT. > > Is this true? I have never seen anything like this. > > Uwe Brauer > > Presumably a reference to https://bitbucket.org/josemaria.alkala/odt2org/wiki/Home I haven't used it, and it's rather old (predates org-elements, I think). -Ethan
Re: [O] [BUG?] Strange effect of noweb name collision on LaTeX export
On Fri, Jun 8, 2012 at 8:13 AM, Eric Schulte wrote:
> Ethan Ligon writes:
>
>> #+TITLE: Example of name collision bug
>> #+AUTHOR:
>> #+EMAIL:
>> #+DATE: 2012-06-07 Thu
>> #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
>>
>> * Figure and trivial code reference
>> Here we have a figure.
>> This example works as expected; we get a latex figure on export.
>>
>> [[./foo.png]]
>>
>> * Figure and trivial code reference (with collision)
>> Here we have a figure and a trivial code block with a noweb reference.
>> The difference is that the basename of the figure matches the noweb
>> reference. Instead of a figure on latex export, we get a hyperref!
>>
>> [[./bar.png]]
>>
>> #+BEGIN_SRC sh :exports none
>> #<>
>> #+END_SRC
>
> Ah, so as it turns out the syntax for the noweb reference happens to be
> the same as the syntax used to specify a latex label. In this case the
> LaTeX exporter first mistakes the <> as a label anchor, and then
> apparently converts the bar.png link to a real link.
>
> The latex exporter probably shouldn't try to make anchors out of the
> text within code blocks. However, in the mean time you can customize
> the noweb syntax using the `org-babel-noweb-wrap-start' and
> `org-babel-noweb-wrap-end' variables so that they aren't mistaken for
> label anchors.
This diagnosis seems exactly right (and thanks for the work-around).
The problem is even worse than I indicated earlier, though---things
like
./foo-bar.png
or
./foo_bar.png
are incorrectly turned into a link if there's any source block along
the lines of
#+begin_src sh
<>
#+end_src
or
#+begin_src sh
<>
#+end_src
Note also that this is not just an ambiguity about whether
./foo-bar.png should be treated as a link or a figure, because if it's
a link it's a /broken/ link (in the example above the resulting LaTeX
is \hyperref[.-foo-bar.png]{./foo-bar.png})
-Ethan
--
Ethan Ligon, Associate Professor
Agricultural & Resource Economics
University of California, Berkeley
[O] [BUG?] Strange effect of noweb name collision on LaTeX export
#+TITLE: Example of name collision bug #+AUTHOR: #+EMAIL: #+DATE: 2012-06-07 Thu #+OPTIONS: H:3 num:t toc:nil \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t * Figure and trivial code reference Here we have a figure. This example works as expected; we get a latex figure on export. [[./foo.png]] * Figure and trivial code reference (with collision) Here we have a figure and a trivial code block with a noweb reference. The difference is that the basename of the figure matches the noweb reference. Instead of a figure on latex export, we get a hyperref! [[./bar.png]] #+BEGIN_SRC sh :exports none #<> #+END_SRC -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
Re: [O] Org, latex and asymptote in a math project
Hi, Jarmo- Jarmo Hurri syk.fi> writes: > 1. If I have understood correctly, in order for an asymptote image to be >included as an inline image, one has to specify a file name at the >beginning of the code block, as in > >#+CAPTION: A test caption. >#+begin_src asymptote :file foo.pdf >size (1cm, 0); >filldraw (unitsquare, red); >#+end_src > >It would be convenient if the user would not need to specify a >(unique) invented file name for the inline image. Instead, in the >case of an exported pdf, as an end user I would like for asymptote to >generate a unique temporary pdf image file, which would be removed >after the pdf corresponding to the complete document was >complete. The case of exported html is not as clear to me yet; my >current guess is that I would like the system to automatically >generate a uniquely named image file (preferably an svg image, but >not sure which browsers support these) which would then be inline >included into the html page. I'm starting on a textbook project using a similar set of tools. I'm making progress, but am still finding lots of little snags; perhaps as we both proceed we can share what we've learned. In any case, using temporary file names is a good idea, which hadn't occurred to me. But I guess it's easy to do, using something like #+CAPTION: A test caption. #+begin_src asymptote :file (org-babel-temp-file "figure-" ".pdf") size (1cm, 0); filldraw (unitsquare, red); #+end_src > 2. At least for me, _by far_ the most common way of referring to a >floating element (table or figure) is immediately before or after the >latex code that defines the float. For this, having to generate a >unique label for the float has always been an overkill, and I have >wanted a way to just refer to the previous or next float in the >document. In org this could mean something like specifying >#+AUTOLABEL and then some way of referring to the labels of the next >and previous float (regardless of whether they would be automatically >generated labels or standard named labels). Any support for this? Any >ideas regarding the syntax? How would one implement this behavior in LaTeX? > 3. It seems that currently inline images generated by asymptote are >included in the resulting latex file with a default size >width=.9\linewidth. I prefer them to be included in their original >size. To achieve this I first tried to define > >(setq org-export-latex-image-default-option "") > >This did not help: in the resulting latex file, the size was now >defined as width=.7\textwidth, which seems to come from >org-latex.el. Finally I obtained the wanted behaviour by artificially >defining the option to some value that does not cause any harm; in my >case > >(setq org-export-latex-image-default-option "keepaspectratio=true") > >Like I said, this is artificial. Is there a more natural way to >achieve the desired result, that is, inclusion of images in their >original size? Would it be ok if the code were changed so that >setting > >(setq org-export-latex-image-default-option "") > >would override the width=.7\textwidth coming from org-latex.el? This was one of the "snags" for me that I mentioned above. But this works: #+CAPTION: A test caption. #+Attr_LaTeX: width=\textwidth #+begin_src asymptote :file (org-babel-temp-file "figure-" ".pdf") size (1cm, 0); filldraw (unitsquare, red); #+end_src > > 4. Let us say that in the math document there would be questions with >corresponding answers and solutions. An answer would be just the >result, while the solution would show the steps needed to obtain the >result. In the org document I would like to write the question, the >corresponding answer and the solution in one place, one after the >other, while in the exported pdf / html I would like the answers and >solutions to be at the end of the document, numbered according to the >numbers of the questions. How could I achieve this? > Haven't done this, but the LaTeX code could put the answers and solutions in a float, which could then be floated to the end of the document. -Ethan
[O] [babel] Producing figures from octave
Dan Davison has a brief worg tutorial on using babel with octave at http://orgmode.org/worg/org-contrib/babel/languages/ob-doc-octave-matlab.html Amongst other things, he offers the following example block for producing a figure: #+begin_src octave :output file :file chart.png figure( 1, "visible", "off" ); sombrero; print -dpng chart.png #+end_src #+results: [[file:chart.png]] The figure seems to be (briefly) created (it pops up on my screen if I change 'figure( 1, "visible", "off" );' to 'figure( 1, "visible", "on");'; also the code provided does the right thing in the octave interpreter). However, rather than delivering the png figure, the file chart.png consists solely of the string "/usr/share/octave/packages/3.2". I'm not sure where this string is coming from: it's *not* part of the stuff that octave writes to stdout when the interpreter is invoked (my first guess). I suspect that the options that need to be offered on the #+begin_src line have changed somehow since that worg page was last updated at the end of April of this year, but don't really know. Help! -Ethan -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
Re: [O] Merge org-7.7 into emacs
Memnon Anon googlemail.com> writes: > > Hi, > > Just a heads up: > >http://permalink.gmane.org/gmane.emacs.devel/142944 > > I don't know anything about this, but maybe something can be said/done > about it while Bastien enjoys his vacation? > I'm afraid I'm mentioned twice. The first has to do with copyright assignment; I've begun the process described in org-contribute.org to assign copyright to the FSF. The second has to do with an incomplete ChangeLog entry for one of my patches (commit 49e6bc899758114d6d29e69a8f9e40798d26782b). I don't know the best to clean this up, since the ChangeLog is derived from the git log. But here's a ChangeLog entry that I think would have been valid: commit 49e6bc899758114d6d29e69a8f9e40798d26782b Author: Ethan Ligon Date: Sat Apr 9 18:39:35 2011 +0200 Fix for html & docbook export of description list items * lisp/org-html.el (org-html-export-list-line): Fix regexp for detecting description lists to allow "::" marker to be last visible element at end of line. * lisp/org-docbook.el (org-docbook-export-list-line): Fix regexp for detecting description lists to allow "::" marker to be last visible element at end of line. The problem is illustrated by the following example: * Illustration of bug in html export - This has a space after the colons :: so will work in latex and html - This doesn't have a space after the colons ::so is an invalid description item according to the org manual. Won't work in html or docbook. Will nevertheless work in latex, provided /first/ description item is valid. - Has a terminating space :: - So it works in both html and latex export! - Even though it's difficult to distinguish from the next example. - Lacks a terminating space :: - At present, *doesn't* work in html or docbook export, does in latex. This is the case that the following patch fixes. -Ethan
Re: [O] [Babel][Bug] Inconsistent output from babel function depending on how called
On Thu, May 26, 2011 at 12:17 PM, Christian Moe wrote: >> No, this is expected (if possibly under-documented behavior). The >> :results header arguments are associated with the code block and *not* >> with the #+call line. To get the desired behavior, you must specify the >> :results header argument on the #+call: line thusly. >> >> #+call: print_list(lst=list1) :results output org >> >> Best -- Eric > > Hi, > > I recently made the same mistake, and it took me a while to figure things > out. I had assumed #+CALLs inherited all the header arguments from the code > blocks they referenced. > > Regarding documentation, I see now that the correct behavior is at least > implicitly documented in the first example at > [[info:org#Header%20arguments%20in%20function%20calls]]. > > It might rate an explicit explanation at > [[info:org#Evaluating%20code%20blocks]] as well, though. > I'd be happy to help with the documentation, but I still don't understand the behavior. It seems as though some arguments to :results need to be supplied to the code block, but others have to be supplied to the call. In my situation, the "org" option to :results has to be supplied to the call, while the "output" option has to be supplied to the code block. What's the logic? Here's my setup: #+results: list1 - Item1 - Item2 #+results: list2 - Item3 - Item4 #+source: print_list(lst) #+begin_src sh for i in $lst; do echo "* $i" done #+end_src Here's a way of calling that works #+call: print_list[:results output](lst=list1) :results org #+results: print_list[:results output](lst=list1) #+BEGIN_ORG * Item1 * Item2 #+END_ORG but this way of calling doesn't #+call: print_list[:results output org](lst=list2) #+results: print_list[:results output org](lst=list2) : * Item3 : * Item4 and neither does this way #+call: print_list[:results org](lst=list2) :results output #+results: print_list[:results org](lst=list2) or this way #+call: print_list(lst=list2) :results output org #+results: print_list(lst=list2) #+END_ORG #+BEGIN_ORG Thanks for any enlightenment! -Ethan -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
Re: [O] [Babel][Bug] Inconsistent output from babel function depending on how called
So, the ":result output org" ought to be associated with the *call*, not with the function. That makes good sense. But perhaps it still doesn't work quite as it ought... On Thu, May 26, 2011 at 11:46 AM, Eric Schulte wrote: > Ethan Ligon writes: > >> I'd like to call a simple babel code block to generate org-code >> If I define a list thusly: >> >> #+results: list1 >> - foo >> - bar >> >> Then I define a code block thusly, and execute it by C-c C-c on the >> "source" line. That yields the desired result: a sequence of headings >> under "#+results: print_list". >> >> #+source: print_list(lst=list1) >> #+begin_src sh :results output org >> for i in $lst; do >> echo "* $i" >> done >> #+end_src >> >> #+results: print_list >> #+BEGIN_ORG >> * foo >> * bar >> #+END_ORG >> >> Now I want to reuse the code block to generate other sequences of >> headings. But even if I call it with the *same* list, instead of the >> desired headings, I get a literal, as below. >> >> #+call: print_list(lst=list1) >> >> #+results: print_list(lst=list1) >> : * foo >> : * bar >> >> I think this qualifies as a bug---surely the method of calling the >> code block shouldn't affect the output? >> > > No, this is expected (if possibly under-documented behavior). The > :results header arguments are associated with the code block and *not* > with the #+call line. To get the desired behavior, you must specify the > :results header argument on the #+call: line thusly. > > #+call: print_list(lst=list1) :results output org > If I do this, I get #+results: print_list(lst=list1) #+END_ORG #+BEGIN_ORG which is surprising first because there's no proper output, but also because the end and begin tags are reversed (!). What *does* work is to omit the "output" header argument. #+call: print_list(lst=list1) :results org #+results: print_list(lst=list1) #+BEGIN_ORG * foo * bar #+END_ORG So now I definitely have a good work-around, but still think there's a bug. Thanks, -Ethan -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
[O] [Babel][Bug] Inconsistent output from babel function depending on how called
I'd like to call a simple babel code block to generate org-code If I define a list thusly: #+results: list1 - foo - bar Then I define a code block thusly, and execute it by C-c C-c on the "source" line. That yields the desired result: a sequence of headings under "#+results: print_list". #+source: print_list(lst=list1) #+begin_src sh :results output org for i in $lst; do echo "* $i" done #+end_src #+results: print_list #+BEGIN_ORG * foo * bar #+END_ORG Now I want to reuse the code block to generate other sequences of headings. But even if I call it with the *same* list, instead of the desired headings, I get a literal, as below. #+call: print_list(lst=list1) #+results: print_list(lst=list1) : * foo : * bar I think this qualifies as a bug---surely the method of calling the code block shouldn't affect the output? Thoughts, patches, or work-arounds welcomed! Thanks, -Ethan -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
[O] [PATCH] worg/org-contrib list items are missing
Okay. I deny that 49e6bc899758114d6d29e69a8f9e40798d26782b broke html export. Before that patch there were *two* bugs related to description lists. After that there was one. See below for an explanation and patch. This also fixes an analogous bug in latex export. On Wed, May 4, 2011 at 5:04 PM, Matt Lundin wrote: > Jason Dunsmore writes: > >> "Sullivan, Gregory (US SSA)" writes: >> >>> Something is broken exporting worg source to lists: >>> >>> http://orgmode.org/worg/org-contrib/ >>> >>> is missing the list item headers. >> >> I see it's missing the left part of the description list items. I ran a >> git-bisect and found the commit that introduced the problem: > > FWIW, the worg page can be fixed by adding an extra space after the "::" > in the first description item. I'm applying this fix to Worg for the > sake of readability, but am documenting my actions here, since it is > related to the patch below. > > Best, > Matt > >> >> 49e6bc899758114d6d29e69a8f9e40798d26782b is the first bad commit >> commit 49e6bc899758114d6d29e69a8f9e40798d26782b >> Author: Ethan Ligon >> Date: Sat Apr 9 18:39:35 2011 +0200 >> >> Fix for html & docbook export of description list items >> >> The problem is illustrated by the following example: >> >> * Illustration of bug in html export >> - This has a space after the colons :: so will work in latex and html >> - This doesn't have a space after the colons ::so is an invalid >> description item according to the org manual. Won't work in html >> or docbook. Will nevertheless work in latex, provided /first/ >> description item is valid. >> - Has a terminating space :: >> - So it works in both html and latex export! >> - Even though it's difficult to distinguish from the next example. >> - Lacks a terminating space :: >> - At present, *doesn't* work in html or docbook export, does in >> latex. This is the case that the following patch fixes. >> >> :04 04 feb2527d8b3294e9d9a118f4752a414b8431d706 >> 4bdeed49ce735a321ddbb3053c22282dd9909677 M lisp >> >> Ethan, can you investigate? > The first bug was that when org-html.el or org-docbook.el tried to process a description list, if the first item in a list looked like - /org-annotate-file.el/ -- annotate a file with org syntax :: without a trailing space or tab, then the entire list would be treated as a bullet list, not a description list. The second bug was that if the list was identified by org-list.el as being a description list, but a *subsequent* item looked like the example above, then the description would get swallowed, and replaced by a ??? in html export. The commit mentioned above fixed the second problem. But that uncovered the first bug, trigged by a description list in Worg/org-contrib/index.org. * Illustration of bug in org-list identification of description lists - This doesn't have a space after the colons :: Previously, export would break, and description wouldn't be printed. - Even worse :: All other subsequent description items in the same list would also not work---they'd be exported as bullet lists, with the description stripped out (in html export). - Prior to commit 49e6bc899758114d6d29e69a8f9e40798d26782b :: this list would have been interpreted as a list of bullets, with the list item content including the description. - After commit 49e6bc899758114d6d29e69a8f9e40798d26782b :: this list would still have been interpreted as a list of bullets, but code in org-html.el (or org-docbook.el) would have stripped out the description part. - After fixing the regex in org-list.el :: Every description item in this list is exported correctly in both html and latex export. Here's a patch that fixes the regex in org-list.el: diff --git a/lisp/org-list.el b/lisp/org-list.el index 9c178e1..83d6828 100644 --- a/lisp/org-list.el +++ b/lisp/org-list.el @@ -369,7 +369,7 @@ It depends on `org-empty-line-terminates-plain-lists'.") (concat "^[ \t]*\\(\\(?:[-+*]\\|\\(?:[0-9]+\\|[A-Za-z]\\)[.)]\\)[ \t]*\\)" "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\]\\)?" "\\(?:\\(\\[[ X-]\\]\\)[ \t]+\\)?" - "\\(?:\\(.*\\)[ \t]+::[ \t]+\\)?") + "\\(?:\\(.*\\)[ \t]+::\\(?:[ \t]+\\|$\\)\\)?") "Matches a list item and puts everything into groups: group 1: bullet group 2: counter -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
[O] [BUG][babel] ":result output table" doesn't work for python code blocks
The results from python code blocks aren't correctly returned as tables when they should be. To wit: #+begin_src python :results output table print "A,B,C" #+end_src #+results: : A,B,C where I'd expect to see #+results: | A | B | C | Eric Fraga seems to have noticed the same problem, but with octave code blocks in http://thread.gmane.org/gmane.emacs.orgmode/36091 but so far there's been no useful response to his post. Thanks for any help! -Ethan Ligon
Re: [O] [bug?] [babel] cannot generate table format output for octave results
Hi- Eric S Fraga ucl.ac.uk> writes: > > Hello, > > I want an octave babel code block to generate an org table as the > /result/ so that it can be used by another code block elsewhere in my > document. Typically, because of how I generate my data, I would like > babel to create the table from the /output/ of the octave code, not the > value. However, specifying =:results output table= doesn't seem to work > (for me, in any case). I can report a very similar apparent bug, but using python. -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
[O] Re: [PATCH] Problem with html export of description list items
Nic- Sent this to the list earlier; should have cc'd you. Thanks again for your help! -Ethan -- After some very helpful corrections and suggestions from Nic, I'd like to propose the following patch, which addresses a problem in the html and docbook export of description items. The problem is illustrated by the following example: #+begin_src org * Illustration of bug in html export - This has a space after the colons :: so will work in latex and html - This doesn't have a space after the colons ::so is an invalid description item according to the org manual. Won't work in html or docbook. Will nevertheless work in latex, provided /first/ description item is valid. - Has a terminating space :: - So it works in both html and latex export! - Even though it's difficult to distinguish from the next example. - Lacks a terminating space :: - At present, *doesn't* work in html or docbook export, does in latex. This is the case that the following patch fixes. #+end_src diff --git a/lisp/org-docbook.el b/lisp/org-docbook.el index dbb608d..124e1dc 100644 --- a/lisp/org-docbook.el +++ b/lisp/org-docbook.el @@ -1382,7 +1382,7 @@ the alist of previous items." (string-match (concat "[ \t]*\\(\\S-+[ \t]*\\)" "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[a-zA-Z]\\)\\]\\)?" "\\(?:\\(\\[[ X-]\\]\\)[ \t]+\\)?" - "\\(?:\\(.*\\)[ \t]+::[ \t]+\\)?" + "\\(?:\\(.*\\)[ \t]+::\\(?:[ \t]+\\|$\\)\\)?" "\\(.*\\)") line) (let* ((checkbox (match-string 3 line)) diff --git a/lisp/org-html.el b/lisp/org-html.el index d19d88b..4ae6d99 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -2501,7 +2501,7 @@ the alist of previous items." (concat "[ \t]*\\(\\S-+[ \t]*\\)" "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\]\\)?" "\\(?:\\(\\[[ X-]\\]\\)[ \t]+\\)?" - "\\(?:\\(.*\\)[ \t]+::[ \t]+\\)?" + "\\(?:\\(.*\\)[ \t]+::\\(?:[ \t]+\\|$\\)\\)?" "\\(.*\\)") line) (let* ((checkbox (match-string 3 line)) (desc-tag (or (match-string 4 line) "???")) -- Ethan Ligon, Associate Professor Agricultural & Resource Economics University of California, Berkeley
[O] Re: [PATCH] Fix for html & docbook export of description list items
After some very helpful corrections and suggestions from Nic, I'd like to propose the following patch, which addresses a problem in the html and docbook export of description items. The problem is illustrated by the following example: #+begin_src org * Illustration of bug in html export - This has a space after the colons :: so will work in latex and html - This doesn't have a space after the colons ::so is an invalid description item according to the org manual. Won't work in html or docbook. Will nevertheless work in latex, provided /first/ description item is valid. - Has a terminating space :: - So it works in both html and latex export! - Even though it's difficult to distinguish from the next example. - Lacks a terminating space :: - At present, *doesn't* work in html or docbook export, does in latex. This is the case that the following patch fixes. #+end_src diff --git a/lisp/org-docbook.el b/lisp/org-docbook.el index dbb608d..124e1dc 100644 --- a/lisp/org-docbook.el +++ b/lisp/org-docbook.el @@ -1382,7 +1382,7 @@ the alist of previous items." (string-match (concat "[ \t]*\\(\\S-+[ \t]*\\)" "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[a-zA-Z]\\)\\]\\)?" "\\(?:\\(\\[[ X-]\\]\\)[ \t]+\\)?" - "\\(?:\\(.*\\)[ \t]+::[ \t]+\\)?" + "\\(?:\\(.*\\)[ \t]+::\\(?:[ \t]+\\|$\\)\\)?" "\\(.*\\)") line) (let* ((checkbox (match-string 3 line)) diff --git a/lisp/org-html.el b/lisp/org-html.el index d19d88b..4ae6d99 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -2501,7 +2501,7 @@ the alist of previous items." (concat "[ \t]*\\(\\S-+[ \t]*\\)" "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\]\\)?" "\\(?:\\(\\[[ X-]\\]\\)[ \t]+\\)?" - "\\(?:\\(.*\\)[ \t]+::[ \t]+\\)?" + "\\(?:\\(.*\\)[ \t]+::\\(?:[ \t]+\\|$\\)\\)?" "\\(.*\\)") line) (let* ((checkbox (match-string 3 line)) (desc-tag (or (match-string 4 line) "???"))
[O] Re: [PATCH] Problem with html export of description list items
Nic- Nicolas Goaziou gmail.com> writes: > > Ethan Ligon are.berkeley.edu> writes: > >> > >> I've just stumbled across what I regard as a bug in the html export of > >> description list items. > >> > >> The problem has to do with whether the specification of a description > >> list includes a trailing space or not; i.e., whether "- Item ::" is > >> treated the same way as "- Item :: ". LaTeX export treats these as > >> identical. Html export gets confused about what the description list > >> item is, and winds up generating a "???" for the description. > > LaTeX exporter doesn't treats these as identical. What happens is that > in your example, the first item is correct and the list is thus set as > a description list. As such, LaTeX exporter tries hard to fill > description terms for every item in the list. If you exchange the first > and second items in your example, the list will be exported as > a standard itemize list in LaTeX. > Your patch allows items like: > > - term ::description > > which are not valid for a description list. Thanks for correcting my misunderstanding of the latex-export behavior. But I still think this behavior is undesirable. The org manual says that a description item takes the form '- term :: ', and thus seems to require a space after the double colon. I suppose it's this that you're relying on in claiming that "- term ::description" is invalid. I agree that "- term ::description" is ugly, but the use-case that is giving me problems is something like - term :: 1. A list 2. Providing 3. The description The html export code currently allows "- term ::[ \t]+", so the above breaks unless there's a space or a tab following the "::". My issue would be addressed if we could just slightly expand the set of allowable white space following, so that we'd have "::[ \t\n]+". Does that seem reasonable? Thanks, -Ethan
[O] [PATCH] Problem with html export of description list items
Ethan Ligon are.berkeley.edu> writes: > > I've just stumbled across what I regard as a bug in the html export of > description list items. > > The problem has to do with whether the specification of a description > list includes a trailing space or not; i.e., whether "- Item ::" is > treated the same way as "- Item :: ". LaTeX export treats these as > identical. Html export gets confused about what the description list > item is, and winds up generating a "???" for the description. > Having done the work to describe the problem, it wasn't hard to find a solution. In this case that's a one character change to a regexp in org-html.el. Here's the patch: diff --git a/lisp/org-html.el b/lisp/org-html.el index d19d88b..005a0f7 100644 --- a/lisp/org-html.el +++ b/lisp/org-html.el @@ -2501,7 +2501,7 @@ the alist of previous items." (concat "[ \t]*\\(\\S-+[ \t]*\\)" "\\(?:\\[@\\(?:start:\\)?\\([0-9]+\\|[A-Za-z]\\)\\]\\)?" "\\(?:\\(\\[[ X-]\\]\\)[ \t]+\\)?" - "\\(?:\\(.*\\)[ \t]+::[ \t]+\\)?" + "\\(?:\\(.*\\)[ \t]+::[ \t]*\\)?" "\\(.*\\)") line) (let* ((checkbox (match-string 3 line)) (desc-tag (or (match-string 4 line) "???"))
[O] [Bug] Problem with html export of description list items
I've just stumbled across what I regard as a bug in the html export of
description list items.
The problem has to do with whether the specification of a description
list includes a trailing space or not; i.e., whether "- Item ::" is
treated the same way as "- Item :: ". LaTeX export treats these as
identical. Html export gets confused about what the description list
item is, and winds up generating a "???" for the description.
Here's an example.
#+begin_src org
* Illustration of bug in html export
- Has a space after the colons :: so will work in latex and html
- No space after the colons ::so won't work in html
- Has a terminating space ::
- So it works in both html and latex export!
- Even though it's difficult to distinguish from the next example.
- Lacks a terminating space ::
- *Doesn't* work in html export, does in latex.
#+end_src
The relevant bit of the html export
#+begin_src html
Illustration of bug in
html export
This has a space after the colonsso will work
???This doesn't have a space after the colons ::so won't work
Has a terminating space
So it works in both html and latex export!
Even though it's difficult to distinguish from the next example.
???Lacks a terminating space ::
Doesn't work in html export, does in latex.
#+end_src
The relevant bit of the latex export looks like this:
#+begin_src latex
\vspace*{1cm}
\section{Illustration of bug in html export}
\label{sec-1}
\begin{description}
\item[This has a space after the colons] so will work
\item[This doesn't have a space after the colons] so won't work
\item[Has a terminating space]
\begin{itemize}
\item So it works in both html and latex export!
\item Even though it's difficult to distinguish from the next example.
\end{itemize}
\item[Lacks a terminating space]
\begin{itemize}
\item \textbf{Doesn't} work in html export, does in latex.
\end{itemize}
\end{description}
#+end_src
Thanks for any help!
-Ethan Ligon
[Orgmode] Re: Sending org buffer as mail?
Eric Schulte gmail.com> writes: > > Jean-Marie Gaillourdet gaillourdet.net> writes: > > > Hi Eric, > > > > "Eric Schulte" gmail.com> writes: > > > >> Hi Matt, > >> > >> This looks great, how would you feel about trying to fold this into > >> org-mime, or would you mind if I did so. I've already mimicked your > >> function to set subjects of outgoing emails to match the title of the > >> org-mode buffer. I think that generalizing the org-mime functions to > >> operate over either subtrees or whole files, and to output either html > >> or plain text should cover all use cases with maximal code re-use. > > > > does it also support using ascii exports as text part and the html > > export as html part in a multi part message? > > > > It does now. In the version I just pushed up an html and ascii export > can be accomplished by setting the :MAIL_FMT: property to html-ascii, or > by calling either `org-mime-send-buffer' or `org-mime-send-subtree' with > 'html-ascii as an argument. > Eric- This is just great; thanks! Two additional suggestions: 1. The subject line should be exported as ascii also, to avoid funky orgmode markup messing things up (I often have links in my headlines, for example). 2. Could we get some indication that the subtree's been mailed? I'm thinking of having org-mime-subtree set a property MAIL_SENT to a time stamp or perhaps to the message id. This way, if we inspect the subtree later we'll know if and when it was actually sent. A possible bonus if we use the message id: when we get to the point of getting replies *back* into the org file it'll be possible to thread things properly. -Ethan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Date calculations in spreadsheet
I'm working with a small spreadsheet, and would like to know how to manage date calculations within the spreadsheet. For example, * How to do date calculations in a spreadsheet? |--+--| | Date | Days elapsed | |--+--| | [2009-12-03 Thu] | | | [2010-12-03 Fri] | 365 | | [2010-12-06 Mon] |3 | |--+--| The question: What's the simplest way to construct a column formula for the second column to deliver the indicated results? And finally, my usual obligatory apology for not noticing the exhaustive thread on exactly this topic that I've undoubtedly missed. 8^) Thanks, -Ethan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] org-feeds, atom, authentication & gdata
I've been messing around in an ineffectual way with better ways to get data from various google services (importantly gcalender and gmail) into org. I'd like gcalendar to talk to calendar, and I'd like gmail to feed threads into headings. The latter seems very close to the idea behind org-feeds. I long ago hacked together a system for gcalendar that involved a wget on an *.ics file and some elisp to get this into calendar entries. This works, in a hackish way, but is neither elegant nor particularly robust. I think that a much better system would be to use org-feeds to subscribe to the atom feed that gcalendar provides. But I don't see how org-feeds manages authentication, which would be necessary for this or other (e.g., gmail services). T. V. Raman posted a couple of years ago (http://article.gmane.org/gmane.emacs.orgmode/3499/) regarding code he'd written to read google's atom feeds. This seems like a huge step in the right direction, but my elisp-fu isn't strong enough to manage the additional steps of integrating this into org-mode. Has anyone else tackled this problem? I'm used to discovering that all my clever ideas about ways to extend org's functionality have already been thought of, so I'm expecting one of you to point me to a thread from three years ago and point to the code that's sitting right there in contrib. Thanks! -Ethan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Email from org?
Eric Schulte gmail.com> writes: > The following function might get part way towards what you describe. > > --8<---cut here---start->8--- > (defun org-send-email-of-headline () > (interactive) > (let ((subject (org-get-heading t)) > (to (org-entry-get (point) "mailto"))) > (outline-mark-subtree) > (org-mime-org-buffer-htmlize) > (save-excursion > (message-goto-to) (insert to) > (message-goto-subject) (insert subject > --8<---cut here---end--->8--- > Indeed! This gets me very close to what I had in mind. Aside from saying thanks, I have two related things to say: 1) The code snippet above (really org-mime-org-buffer-htmlize) produces output which is either designed to be further processed by the mml library (mml-generate-mime) for gnus users or by the semi library for wanderlust users. Thus, the buffer resulting from the above code-snippet is still one step away from being something one could feed to smtpmail, and makes the output one needs to get from org-mime dependent on an MUA (gnus or wanderlust). 2) I don't see the reason for this dependence. Forget what mail client the user prefers, whether gnus or wanderlust or something else. Why not just feed the output of org-mime to a scratch buffer, run (mml-generate-mime) on that, stick the output in a message buffer, build a header, and then run smtpmail-send-it? 3) Okay, I see one reason for the dependence: I guess that mml isn't part of the base emacs distribution. 4) And I see another reason: if one wanted to edit the htmlized buffer it might be a little more convenient to work with the semi or mml representations instead of the mime. But (3) and (4) seem weak to me. What am I missing? -Ethan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Bug in org-mime may expose more than intended to email recipient
Acting on suggestions from Eric S. & David M., I've been experimenting
with org-mime; I can see that it's going to be useful.
However, I've also discovered what I think is a bug.
Consider the following org-file:
Cut here
* NEXT Do something private
* NEXT Email something not private
Kenneth-
Do please get back to me regarding the frequency.
-Ethan
Cut here
If I use C-c @ to select only the second item and then invoke
org-mime-org-buffer-htmlize, that results in a buffer:
Cut here----
From: Ethan Ligon
To:
Subject:
User-Agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.9 (Gojō)
APEL/10.7 Emacs/23.1 (i486-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO)
--text follows this line--
--<>-{
--[[text/plain]]
* NEXT Do something private
* NEXT Email something not private
Kenneth-
Do please get back to me regarding the frequency.
-Ethan
--[[text/html]]
Kenneth-
Do please get back to me regarding the frequency.
-Ethan
--}-<>
Cut here
The selected region has been correctly htmlized, and a recipient using
a web-browser or similar for their email will see just that part.
HOWEVER, the *entire* org file is embedded in the [text/plain]
alternative.
-Ethan
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Re: Email from org?
Eric Schulte gmail.com> writes: > > See http://orgmode.org/worg/org-contrib/org-mime.php for information on > exporting Org-mode documents to email, and on using Org-mode syntax to > compose email. > Thanks for the suggestions regarding org-mime. I can see that it would be very useful for composing complicated email. But I have what I think is actually a much simpler problem: *sending* email from an org-file. I have in mind something like: #+TYP_TODO: EMAIL SENT WAITING | DONE * Broadcasting project ** EMAIL What is the optimal frequency? :PROPERTIES: :To: kenn...@example.com :END: Dear Ken- Could you please let me know when you've made progress on computing the optimal frequency? Thanks, -Ethan Then a transition in workflow state from EMAIL to WAITING would cause (perhaps via org-mime) the construction of an email From: li...@are.berkeley.edu To: kenn...@example.com Subject: What is the optimal frequency? Date: Wed, 28 Jul 2010 13:36:14 -0700 Dear Ken- Could you please let me know when you've made progress on computing the optimal frequency? Thanks, -Ethan which would then be automagically fed into an SMTP client for delivery. Critically, one would *not* need to interrupt one's work flow in order to go mess around with a mail client; a simple \C-c\C-t or similar would send the email on its way. Or very possibly there's an obvious way to accomplish a similar end that hasn't occurred to me. Maybe the act of composing an email in a mail buffer could also format and re-file the message in an org-file, leading to a workflow similar to what one gets with org-capture? Any further thoughts welcome! Thanks, -Ethan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Email from org?
Over the last three years my projects and daily workflow have come to depend more and more on org-mode. A few months ago I took the step of composing important email as items in an org-file; the heading became the subject of the email; replies could then fill in the hierarchy under the heading (reproducing something like threads). The problem is that the methods I've used to send the message composed in org-mode and then to assemble the responses have been entirely crude and unsatisfactory. There has to be a better way. In fact, given my past experience with org-mode, there probably *is* a better way and I've simply overlooked it. Vague ideas that have occurred to me: - Sending the email might be something like exporting it to smtp? - Could org-protocol be useful for acquiring responses? Thoughts? -Ethan ___ Emacs-orgmode mailing list Please use `Reply All' to send replies to the list. Emacs-orgmode@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-orgmode
[Orgmode] Bug in org-beamer-settings-template
Org-mode has been my constant companion for nearly two years now, but I keep
discovering new and wonderful things it can do. It's been my practice for
somewhile to outline my talks in org-mode, export that to LaTeX, and then to
transform that into a beamer presentation by hand. Faced with this tedious task
this weekend, I wondered whether it wouldn't be easy to automate parts of this
by customizing org-latex. A couple of googles later and I found myself in this
thread, and a git clone after that I've got some nice slides.
This is just great! But I've found a very minor bug to report. After invoking
org-beamer-settings-template and [g]lobal, I get the template:
#+LaTeX_CLASS: beamer
#+LaTeX_CLASS_OPTIONS: [presentation]
#+BEAMER_FRAME_LEVEL: 1
#+BEAMER_HEADER_EXTRA: \usetheme{default}\usecolortheme{default}
#+COLUMNS: %45ITEM %10BEAMER_env(Env) %10BEAMER_envargs(Env Args)
%4BEAMER_col(Col) %8BEAMER_extra(Extra)
PROPERTY: BEAMER_col_ALL 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 :ETC
Note the final line. Surely this should be preceded by a "#+"?
-Ethan
___
Emacs-orgmode mailing list
Please use `Reply All' to send replies to the list.
Emacs-orgmode@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-orgmode
