Jambunathan K. writes:
> I would like to add the following observation as well -
>
> ---> org input <---
> #+AUTHOR: Jambunathan K\cr\href{mailto:{{{EMAIL}}}}{{{{EMAIL}}}}
>
> ---> actual tex output <---
> \author{Jambunathan K\cr\href{mailto:kjambunathan@gmail.com}\{kjambunathan@gmail.com\}}
>
> The above tex snippet has the effect of getting the "Url Box" wrong.
>
> I was hoping to produce the following line -
> \author{Jambunathan K\cr\href{mailto:kjambunathan@gmail.com}{kjambunathan@gmail.com}}
>
> Generally speaking, macro expansion in author string behaves strangely.
Eric Fraga writes:
> What am I missing? I tried exporting the following to HTML and the
> caption and HTML attributes seem to be ignored completely. Also, the
> alignment directives are ignored as well.
>
> --8<---------------cut here---------------start------------->8---
> #+TITLE: test file for org mode
> #+DESCRIPTION: used for bug reports
> #+AUTHOR: Eric S Fraga
> #+EMAIL: Eric S Fraga <e.fraga@ucl.ac.uk>
> #+DATE: 2010-03-11 Thu
> #+KEYWORDS:
> #+LANGUAGE: en
> #+OPTIONS: H:3 num:t toc:t \n:nil @:t ::t |:t ^:t -:t f:t *:t <:t
> #+OPTIONS: TeX:t LaTeX:t skip:nil d:nil todo:t pri:nil tags:not-in-toc
> #+INFOJS_OPT: view:nil toc:nil ltoc:t mouse:underline buttons:0 path:http://orgmode.org/org-info.js
> #+EXPORT_SELECT_TAGS: export
> #+EXPORT_EXCLUDE_TAGS: noexport
> #+LINK_UP:
> #+LINK_HOME:
>
> * tables
>
> #+caption: A very interesting table
> #+attr_html: border="1" rules="all" frame="all" align="center"
> | <r> | <l> |
> | Id | Description |
> |-----+--------------------------------|
> | 1. | The first item |
> | 2. | the second |
> | 4. | we don't have a third one |
> | 10. | a longer id to check alignment |
> |-----+--------------------------------|
> --8<---------------cut here---------------end--------------->8---
>
> I'm using org current as of yesterday Org-mode version 6.34trans
> (release_6.34c.186.g1902) and with GNU Emacs 23.1.1
> (i486-pc-linux-gnu, GTK+ Version 2.18.2) of 2009-11-02 on raven,
> modified by Debian
Tom writes:
> When archiving trees I'd like to see the archived items in
> reverse chronological order at the archive location, so if I jump
> to the header under which stuff is archived I would see the most
> recent item at the top.
>
> When searching for something in the archives it is much more
> frequent that I'm looking for something recently archived than
> something archived months ago, so the reserved order would make
> more sense to me.
>
> Is there a setting which tells the archiving command to insert
> the archived tree as first child of the archive location,
> instead of the last?
Patch by Matt Lundin
Matt writes:
> Below is a patch I've been using to speed up the construction of
> agenda views limited to certain types of entries (e.g., timestamps and
> sexps). Previously, I had constructed "calendar" views consisting
> only of timestamps and sexps by using the variable
> org-agenda-skip-function to exclude scheduled items and deadlines from
> the agenda. This, however, proved somewhat slow (3-4 seconds for
> weekly calendars, 10-12 seconds for monthly calendars). The patch
> below cuts the times to 1 and 3 seconds respectively. I believe it
> provides an efficient alternative to the skip function by allowing the
> user to tweak the arguments passed to org-agenda-get-day-entries.
John Wiegley writes:
> I have the following data in my Org-mode file:
>
> #+LINK: cegbug https://portal/bugzilla/show_bug.cgi?id=
>
> ** TODO [[cegbug:351][#351]] Bizcard: Fix Maven build setup
> - State "TODO" from "STARTED" [2010-03-01 Mon 14:42]
>
> Now, in the Agenda and in the Org-mode buffer, everything looks fine.
> I can also use C-c C-o if my cursor is within the #<NUMBER> text.
>
> However, if I'm in the Agenda and I hit C-c C-o, it says 'No match'
> after about a second. Is there any reason I can't open these links
> from the Agenda view?
William Henney writes:
> Anyone have a clue what is going on here?
>
> Cheers
>
> Will
>
> * Arctan2 bug
> Activate the formula editor for the following table with =C-c '=, then
> exit without changing anything. Note what happens to the arctan2
> formula. For me, "arctan2" changes to "@2$20173232".
> | x | y | arctan | arctan2 |
> |---+---+--------+---------|
> | 1 | 1 | 45 | 45. |
> #+TBLFM: $3=arctan($1/$2)::$4=arctan2($1,$2)
>
> ** Versions
> Org 6.34trans, Aquamacs 2.0preview4, Emacs 23.1.92.1
Daniel Clemente writesL
> Hi, I found an HTML export bug with org-mode 6.34c-140-g44c8 and
> older. I used:
>
> --------------------------------------------------------
> * only one section
> #+BEGIN_EXAMPLE:
>
> We need:
> ,* pears
> ,* lettuce
> ,* watermelons
>
> Very important!
> #+END_EXAMPLE:
> --------------------------------------------------------
>
> And the outputed table of contents had this code:
>
> --------------------------------------------------------
> <div id="text-table-of-contents">
> <ul>
> <li><a href="#sec-1">1 only one section </a></li>
> <li><a href="#sec-2">2 pears</a></li>
> <li><a href="#sec-3">3 lettuce</a></li>
> <li><a href="#sec-4">4 watermelons</a></li>
> </ul>
> </div>
> --------------------------------------------------------
>
> This is wrong because the asterisks inside the example don't
> represent headers. There should be only one header.
Lukasz Stelman writes:
I've create some presentation on programming (some more to do) and to my
surprise I've discovered that if org-mode escapes one "&" properly it
doesn't do its job in case of "&&" (and a single "^" too). I get "\&&"
in latex file which of course is wrong.
This support was totally broken. It works now again. Unfortunately
it is not possible to edit the table directly in the org-mode buffer
anymore - to edit such a table, you have to use C-c '
This patch implements reading American dates, like
2/5/3 --> 2003-02-05
2/5 --> ????-02-05
Is also fixes a bug that would force the current year when reading a
date like 2/5 (American) or 2-5 (ISO), and in this way would prevent
`org-read-date-prefer-future' to do its job. This bug was reported by
Lukasz Stelmach.
Also get rid of a bug: as timers where not properly canceled,
`org-timer-show-remaining-time' was not giving the proper result.
Thanks to Frédéric Couchet for this catch.
The `org-clock-set-current' and `org-clock-delete-current' functions
handle this variable. The variable only stores the last clocked in
entry, not the history of clocked in tasks.
This can help to get out of an inconsistent state produce for example
by viewing from the agenda. Reported by Matt Lundin:
> I'd like to report a minor issue with org-agenda-goto and inline tasks.
> Let's say one has the following file:
>
> --8<---------------cut here---------------start------------->8---
> * Here is an entry.
> Blah blah blah blah.
> *************** Here is an inline task.
> *************** END
> Blah blah blah blah blah.
> *************** TODO Here is a second inline task.
> *************** END
> Blah blah blah blah blah.
> *************** Here is a third inline task
> *************** END
> Blah blah blah blah blah.
> --8<---------------cut here---------------end--------------->8---
>
> Let's say one also has the following settings:
>
> --8<---------------cut here---------------start------------->8---
> (setq org-show-hierarchy-above t)
> (setq org-show-siblings '((default . nil) (isearch . t) (agenda . t)))
> (setq org-show-entry-below '((default . nil) (isearch . t) (agenda . t)))
> --8<---------------cut here---------------end--------------->8---
>
> If 1) one tries to jump to the TODO from the agenda and 2) the entry is
> currently folded, org-show-context reveals only the headlines. E.g.,
>
> --8<---------------cut here---------------start------------->8---
> * Here is an entry.
> *************** Here is an inline task.
> *************** END...
> *************** TODO Here is a second inline task.
> *************** END...
> *************** Here is a third inline task
> *************** END...
> --8<---------------cut here---------------end--------------->8---
>
> Invoking org-cycle on the END headline does nothing, since all headlines
> deeper than org-inlinetask-min-level are exempted from cycling. As a
> result, the only way to reveal the text in the entry is to cycle the
> parent twice (first to close, then to reveal).
Ruud Brekelmans writes about problems with spurious footnotes:
> I still find similar behavior when exporting to LaTeX with:
>
> #+BEGIN_LaTeX
> \newcommand{\norm}[1]{\lVert#1\rVert}
> #+END_LaTeX
Emilio Arias writes:
> egallego@babel.ls.fi.upm.es (Emilio Jess Gallego Arias) writes:
>
> To reproduce save this minimal org file:
>
> #+STARTUP: even
> * A
> :PROPERTIES:
> :ARCHIVE: a
> :END:
> ** B :ARCHIVE:
> Some text
>
> and hit TAB when in the * A headline; then the ** B headline contents
> will be incorrectly shown.
>
> I've found the culprit in org-hide-archived-subtrees:
>
> ,----
> | (defun org-hide-archived-subtrees (beg end)
> | "Re-hide all archived subtrees after a visibility state change."
> | (save-excursion
> | (let* ((re (concat ":" org-archive-tag ":")))
> | (goto-char beg)
> | (while (re-search-forward re end t)
> | (and (org-on-heading-p) (org-flag-subtree t))
> | (org-end-of-subtree t)))))
> `----
>
> The problem is that the RE matches the first archive "property" and
> then does an org-end-of-subtree which skips all the subtrees of the
> parent tree where the ARCHIVE property is located.
>
> I've replaced this part
>
> | (and (org-on-heading-p) (org-flag-subtree t))
> | (org-end-of-subtree t)))))
>
> by
>
> | (when (org-on-heading-p)
> | (org-flag-subtree t)
> | (org-end-of-subtree t)))))))
>
> so org-end-of-subtree is only called if we are really in a headline. I
> think that makes sense.
>
Carsten Dominik
Bastien Guerry
Andy Lutomirski