Tassilo Horn writes:
> I have this entry in an org-file.
>
> --8<---------------cut here---------------start------------->8---
> ** bung Grundlagen der Softwaretechnik (B 016) :teaching:
> <2009-04-22 Wed 08:30-10:00 +1w>
> <2009-04-29 Wed 10:15-11:45> (Fr Hannes bernehmen)
> --8<---------------cut here---------------end--------------->8---
>
> I expect it to be displayed every wednesday after 2009-04-22
> for 08:30-10:00 and on 2009-04-29 it should be displayed
> twice: one at the usual time and one for 10:15-11:45.
>
> But the agenda shows only the regular entry (08:30-10:00)
> and omitts the exception. If I reorder the timestamps, so
> that the exception comes first, only the exception will be
> shown on 2009-04-29. Every other wednesday shows the
> regular repeater date.
>
> What do I have to do to make that entry showing up twice on
> 29th April?
This commit adds a new option
`org-agenda-skip-additional-timestamps-same-entry'. When set
to t, an entry that has multiple active time stamps will get
multiple lines in the agenda.
This reverts commit 61dfa0c67f.
This wasn't such a great idea after all. There is one case where
this is really annoying - if you are in the middle of displaying
an agenda view with lots of filters active and you change what you
are clocking it jumps away and you lose the agenda view.
This one case makes hitting a dedicated function key that runs
org-clock-goto more desireable.
Matt Lundin writes:
> If it's not too much trouble, I was wondering if I could
> request the following properties to set export options for
> subtrees:
>
> EXPORT_AUTHOR
> EXPORT_DATE
>
> In addition to specifying an EXPORT_FILE and EXPORT_TITLE
> for a subtree, I often find myself wanting to change the
> date and author lines.
The variable `org-refile-target-verify-function' can be set to a
function that will be called to verify a refile target. The function
must return t if the target is valid.
Users can now define custom IDs for use in HTML export.
These IDs are stores as property CUSTOM_ID. When present, HTML will
prefer using these over automatic targets like "sec-N.M".
Scot Becker writes:
> Prompted by Chris Gray's request for org markup in Latex
> environment, I thought I'd submit a note (for his sake and
> others') about a few quirks of org-latex-export's handling
> of embedded Latex markup in org documents. I have been
> puzzling with these for a while but only discovered the
> problem triggers (and workarounds) this morning just before
> Chris' mail arrived. These are both about inline Latex
> commands:
>
> I use a few custom commands \mycommand{like this}, and
> occasionally have to invoke the odd bit of standard LaTeX
> markup, for example /when \textbf{embedding bold text}
> inside italics/. For the most part, these work fine, but
> I've discovered the following two 'gotchas' that happen when
> exporting to LaTeX.
>
> 1. Inline Latex commands get their final curly brace
> escaped with a slash (and therefore don't work) if they
> spill over into another line, i.e. if they contain one or
> more newlines. This is true also for standard LaTeX
> commands like \textbf{} and \emph{}.
>
> ----------------SAMPLE------------------------
> \mycommand{So, for example this
> wrapped setence gets a slash added just after the
> final period and before the curly brace.} Org is quite
> helpfully escaping the slash for LaTeX, apparently.
>
> \mycommand{no trouble if it's all on one line}
> ------------------END-------------------------
>
> The workaround of putting all such commands on one line is
> no hardship for me, since I use visual-line-mode in Emacs 23
> and keep my paragraphs as single logical lines. It might be
> harder for those accustomed to hard-wrapping their
> paragraphs.
>
>
> 2. If you have two inline Latex commands on the same
> logical line, org's latex export doesn't treat the text
> between them in its usual manner. Italics get processed,
> but not the latexification of quotes. ("this" --> ``this'')
> For example:
>
> ----------------SAMPLE------------------------
> I have a short custom command to tell Latex to invoke a
> Hebrew-language right-to-left environment when I want to refer to a
> Hebrew phrase like this: \heb{phrase here}. But then if I "quote
> something," and follow that by another \heb{phrase}, the inner
> quotation marks don't get processed. Oddly enough, this problem is
> only triggered when there is an inline Latex command both before and
> after the quoted material on the same logical line.
>
> Now if you put a footnote in between those two inline Latex commands,
> the output is really nutty:
>
> And \heb{phrase here} with a footnote[fn:: Footnote here.] I'm not
> sure what funky org commands get invoked, but again, only when
> bookended by an inline Latex command like \heb{phrase here}.
> ------------------END-------------------------
>
> The nutty output is a number in square brackets like
> this[1], with the following at the bottom of the document:
>
> \$\^{}{1}\$ Footnote here.
>
> This has a the opposite work-around: break the lines so
> those elements are not all on the same logical line. Put in
> a few newlines. Latex, of course doesn't care. Do take
> care not to start a newline with the org-footnote, like this
> [fn:: Org doesn't parse a footnote command which starts on
> its own line.]
>
> This is just "for what it's worth" to those who use org-mode
> as a front-end to writing for LaTeX.
These problems were caused by a regular expression for
matching latex macros with arguments, that did not allow any
newlines. Now we have a much better regexp, that even
allows for three levels of nested braces.
Move the point to the selected task when clocking in using the clock
history. I find I'm always going to the currently clocked task after
picking it off of the menu and this saves one small step.
This could be optionally controlled by a variable.
Sometimes refiling a task displays the next task heading after ... at the
end of a folded task. This keeps the next task the cursor is on starting
in column 1 which feels more natural.
If the heading field in the remember template entry is either `top' or
`bottom', it is now OK to file to a file that is not in org mode, and
the content of the remember buffer is inserted without forcing an
Org-style header.
Rares Vernica writes:
> I think the standard references do not work correctly in the
> "remote" function. Moreover, the "edit all formulas" (C-c ')
> window replaces the internal references with standard
> references. Even if I toggle the references back to internal
> ones, the references in the "remote" function do not get
> updated.
>
> Here is an example:
>
> #+TBLNAME: TableA
> | 101 |
> #+TBLFM: @1$1=remote(TableC,@1$1)
>
> #+TBLNAME: TableB
> | A1 |
> #+TBLFM: @1$1=remote(TableC,A1)
>
> #+TBLNAME: TableC
> | 101 |
>
> If I do C-c * in TableA, it works correctly. In TableB it
> doesn't. If I do C-c ' in TableA and then (with or without
> C-c C-r) C-c C-c and C-c *, then the contents of TableA will
> be equivalent to the ones of TableB and the reference will
> be broken.
Standard references like A1 are now allowed in call to
remote().
Rares Vernica writes:
> I think I found another bug related to remote
> references. When I insert/remove a row/column using the
> table commands, the remote references to other tables are
> also updated. I think org treats "remote" as a regular
> function and updates the references inside it.
>
> Here is an example:
>
> #+TBLNAME: TableA
> | 101 |
> #+TBLFM: @1$1=remote(TableB,@1$1)
>
> #+TBLNAME: TableB
> | 101 |
>
> If I go in the cell of TableA and do M-S-down arrow, I get
> the following:
>
> #+TBLNAME: TableA
> | |
> | 101 |
> #+TBLFM: @2$1=remote(TableB,@2$1)
> ^^^^
>
> As you can see the remote reference has been updated. I
> similar update happens when I remove a row or insert/remove
> a column.
This commit makes sure that references inside calls to
remote() are not touched.
sha1-string is not autoloaded in sha1.el as in the version distributed
with Emacs 22. Instead of relying on autoloads, the sha1 library is
now required by org-feed.el.
When refiling, you can now create new parent nodes on the fly. To do
this, set the variable `org-refile-allow-creating-parent-nodes' to
`confirm'. Then, at a refiling prompt, proceed with completion until
you have an existing heading, and then add "/new heading", i.e. a
slash followed by the new heading. That heading will be created as a
child of the existing heading, and the entry to be refiled will end up
under that new heading.
Carsten Dominik
Bernt Hansen