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.
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.
New wrapper span around keyword plus time stamp, with class
timestamp-wrapper.
.timestamp-wrapper {float: right;}
could be a nice entry in a CSS style file.
Adam Elliot writes:
> Automatically resuming the clock after an Emacs restart
> fails under the following cases:
>
> 1. If org-log-states-order-reversed set to t (default), and
> a state change line precedes the clock line to resume.
> Error message is "Cannot restart clock because task does
> not contain unfinished clock".
>
[...]
> 2. If org-log-states-order-reversed set to nil. Error
> message is the same. Reason: point is placed *after*
> last clock line and so fails looking-at test.
>
This commit fixes the problem, in a slightly different way
than Adam proposed. Instead of trying to fix the old way to
find the position of the clock, we now simple search the
entry if there is an unfinished clock and go there. Since
new clocks are added before older ones, this should be a
safe bet.
Time stamps in LaTeX export now also honor custom time stamp formats.
Furthermore, the new option `org-export-latex-timestamp-markup' can
specify special markup for time stamps.
Some of the standard export options are now defined in backend
specific files. This commit makes sure that building the options
property list will not cause an error because of unneeded (for the
backend) undefined variables.
Samuel Wales writes:
> A lower case version of a todo kw at the beginning of a
> headline, when in lower case, causes sort to ignore the
> word.
>
> Also, setting priority with shift down causes the cookie to
> be inserted in the wrong place.
Both problems are address in this commit.
The following contributed packages are (partially) obsolete.
org-browser-url.el
org-annotation-helper.el
The functionality of both these packages is a subset of
org-protocol.el, which is now part of the Emacs core
and is recommended.
org-depend.el
A significant fraction of the org-depend functionality
dependence on siblings, children, and parents) is now
built-in into the Org core. Org-depend remains
in the distribution as a proof-of-concept fro complex
and remote dependencies.
org-interactive-query.el
I believe that much of what this package was build for
is now available with tag filtering.
These packages are now marked in org-modules as such.
The command org-reload did not only reload any loaded files, but all
lisp files in the Org distribution. Also, it actually never reloaded
any files from the contrib directory. Both of these problems are now
fixed.
Mapping call a function for each matching entry. So far this has
always assumed that the entry stays in the buffer and search can
continue from there. However, when the mapper function removes the
tree, more control is needed to specify from where the search should
continue.
The action function handed to the mapping function can now set the
variable `org-map-continue-from' to the position from where mapping
should continue.
Daniel Hochheimer writes:
> It seems there is a bug in the handling of simple dependencies.
> I think an example tree is the best solution, to show you the bug:
>
> * Projects
> #+CATEGORY: Projects
> *** TODO foo bar project
> :PROPERTIES:
> :ORDERED: t
> :END:
> ***** TODO foo subproject :FooSubproject:
> ******* TODO Task 1
> ***** TODO bar subproject :BarSubproject:
> ******* TODO Task 1
>
> This is in my .emacs file:
> (setq org-enforce-todo-dependencies t)
> (setq org-agenda-dim-blocked-tasks 'invisible)
> (setq org-odd-levels-only t)
>
> the expected global todo agenda view imho is:
>
> Projects: Task 1 :FooSubproject:
>
> but actual it is unfortunately:
>
> Projects: Task 1 :FooSubproject:
> Projects: Task 1 :BarSubproject:
>
>
> Imho "Task 1" from "bar subproject" should not be visible,
> because "bar subproject " is blocked because of the
> ORDERED property (therefore it's childs should be blocked, too)
>
>
> Is it easy / possible to fix this bug? My whole GTD system is
> heavily based on such project / subproject-Constructs. But with
> this bug my global todo agenda view is unfortunately "polluted"
> a little bit with tasks from projects that shouldn't be active.
After some back and forth, Daniel convinced me, and this is now done
correctly.
If the trigger for a log mode entry in the agenda has notes, for
example a note associated with a state change or with a clock entry,
the first line of the notes will now be added to the logbook entry.
You can turn this off the with new variable
`org-agenda-log-mode-add-notes'.
The annotation and initial contents for a remember template are
normally taken from the variables `annotation' and `initial', which
are bound by remember. We now also check the property list for such
values, so that the link generating routine can force the right values
in there.
With the setting
(setq org-refile-use-outline-path 'file)
the file names ended up twice, like
"xxx.org/level 1/level 2 (xxx.org)"
Now the second occurrence is omitted.
During secondary agenda filtering, pressing "?" now will install a
filter that selects entries which do not have an effort defined.
This new model was necessary because we needed to stop interpreting
entries with no effort defines as 0 effort. This was inconsistent,
because for normal agenda sorting, the treatment of these entries
depends on the variable `org-sort-agenda-noeffort-is-high'. Now this
variable is also respected during filtering.
Rustom Mody writes:
> The last two lines of my org file are
>
> *** Vishnu Sahasranam
> *** Ram Navami
>
> without a newline at the end
>
> Trying to reorder these two lines I do a M-S-down on second last
> line I get
>
> *** Ram Navami*** Vishnu Sahasranam
This module implements inline tasks in Org-mode. Inline tasks are
tasks that have all the properties of normal outline nodes, including
the ability to store meta data like scheduling dates, TODO state, tags
and properties. However, these nodes are treated specially by the
visibility cycling and export commands.
RefTeX can now be used to create a citation in Org-mode buffers.
Setup the buffer with #+BIBLIOGRAPHY: bibbase style
and create citations with `C-c C-x ['.
The new variable `org-agenda-cmp-user-defined' can contain a function
to test how two entries should be compared during sorting.
user-defined-up and user-defined-down can then be part of any sorting
strategy.
Chris Leyon writes:
> For some semi-short time, org-ido-switchb has been broken, complaining
> about wrong type arguments. The attached one-line patch corrects
> this.
Patch by Chris fixes this problem.
The new variable `org-agenda-search-headline-for-time' also turned off
time searching for diary items as an unwanted side-effect. This
commit makes sure that diary entries are always parsed for a time.
Harri Kiiskinen writes:
> It seems that org-use-tag-inheritance set to regexp, the use of
> #+FILETAGS: and org-todo-list do not work together. It seems, that a
> regexp in org-use-tag-inheritance matching a tag set in #+FILETAGS
> causes this error:
>
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
> string-match("^ +" nil)
> [...]
> when org-use-tag-inheritance is set to regexp "te"
> with this file:
>
> --------
> #+STARTUP:
> #+FILETAGS: tea
> * TODO testing :test:
> ** TODO too :data:
> -----
>
> When the regexp is "tes", so that the FILETAG does not match,
> org-todo-list produces a correct list.
This is indeed a bug. The all to `org-get-tags-at' does change the
match data if there is a match for the inheritance regexp. This
problem is now avoided by first extracting (match-string 1), and then
getting the tags.
Studying this bug also exposed another one, namely that file tags are
not marked as inherited tags. This is now fixed, immediately when
the #+FILETAGS line is parsed.
Chris Randle writes:
> I have one giant Org-mode file for everything. I frequently use
> `C-c C-x b' to take the current node and show it in a new frame
> with narrow subtree so that I can concentrate on just that region
> of my file. Rather like hoist in GrandView, if anyone remembers
> that.
>
> My Org Manual (6.24b) says "The indirect buffer...will contain
> the entire buffer, but will be narrowed to the current
> tree. Editing the indirect buffer will also change the original
> buffer, but without affecting visibility in that buffer.
>
> I've noticed that, when working in the new frame, changing the
> TODO state of any item within the frame to DONE (when it is the
> currently clocked in item) does not stop the clock. Going back to
> my main frame and doing the same thing there on the same item
> does stop the clock.
>
> I haven't altered `org-clock-out-when-done', and Emacs reports
> its value as t.
This was caused by the fact that markers seem to point to the
base buffer always, so we need to check if the current buffer's
base buffer is equal to the marker buffer.
Chritopher Suckling writes:
> All,
>
> For various reasons (mainly Spotlight and an excess of HTML mail
> send by employers), I've migrated back to Mail.app after some
> time in Mutt (and how I miss the speed and threading).
>
> I habitually flag mails that need attention at a later date, and
> rather than use both org-mode and Mail.app to keep track of what
> needs doing, I've written a couple of hybrid elisp AppleScript
> functions to suck links to my flagged email into org-mode.
>
org-mac-message.el now contains these new functions.
When setting the variable `org-remember-back-directory', each
remember buffer created will now get its own unique file name in that
directory. So if you, by accident, overwrite a remember buffer or
remove it before storing it, there will be a backup.
Items are listed in the agenda sometimes in bright colors, to draw
attention to important tasks or deadlines. When such an item is
switched to DONE, the state change is reflected by the new TODO
keyword, but the line itself might still be bright. Org de-emphasizes
the line by changing the face of the line. It used to change it to
the face `org-done', but now we use a new, independent face
`org-agenda-done'.
When a tags/property match does match an entry and its sublevels, the
sublevels used to be indented by dots, to indicate that the matches
likely result from tag inheritance. This is now no longer the
default, but you can get it back with
(setq org-tags-match-list-sublevels 'indented)
David Maus writes:
> When I start to clock a headline (C-c C-x C-i) that does not have a
> LOGBOOK drawer orgmode inserts one but removes the indentation of the
> first line below the headline:
>
> Example:
>
> * TODO Do something
> Do this, do that etc.
>
> after C-c C-x C-i becomes
>
> * TODO Do something
> :LOGBOOK:
> CLOCK: [2009-03-20 Fr 19:03]--[2009-03-20 Fr 19:03] => 0:00
> :END:
> Do this, do that etc.
Fixed with this commit, a patch written by Peter Jones.
Outline levels below the headline boundary are now treated better, as
proper list. The variable `org-export-latex-low-levels' can now also
be `itemize' or `enumerate', to get the corresponding list structure.
The new default is `itemize', to make it parallel with the behavior in
HTML.
When exporting to a temporary buffer, images to replace LaTeX
fragments cannot be produced, because there is no useful location
where they can be put. Therefore, these images are not produced in
this case.
This commit implements an important change: When, during a
stuck-project search, a project tree is identified as not stuck, so
far the search would continue after the end of the project tree. From
now on, the search continues in the subtree, so that stuck subprojects
can still be identified.
In verse environments, line breaks are now enforced both in LaTeX and
in HTML. Centering is now implemented using a div rather than a
paragraph, so that there may be several paragraphs in the centering
environment. Blockquotes now also may have several paragraphs.
When a note is taken, the new drawer is created before the note is
taken. Now the drawer is removed again if the note gets aborted and
if the drawer is empty.
Anupam Sengupta writes:
> I routinely use time ranges (and occasionally time-stamp ranges)
> in my org files to document the scheduled block of time for a
> meeting or activity. As an example, I will mark meetings as:
>
> * A Meeting
> <2009-03-12 Thu 10:00-11:00>
>
> As often happens with meetings, rescheduling needs to be done and
> I use S-<up> or S-<down> on the time-stamp to make the
> modifications. While this works fine, it usually leads to a
> duplication when the *time* part of the time-stamp needs to be
> changed.
>
> For the same example above, if the time-block has now changed to
> 11:00-12:00, then I need to do S-<up> on both the "10:00" and the
> "11:00" string. I.e,
>
>
> * A Meeting
> <2009-03-12 Thu 11:00-11:00>
> ^
> +---------------- After the first S-<up>
>
> * A Meeting
> <2009-03-12 Thu 11:00-12:00>
> ^
> +---------------- After the second S-<up>
>
> Can we have a feature (with a toggle option perhaps) which would
> *move* the block (i.e., both time entries) by the same amount
> when either one is moved in the same direction. I.e., the
> proposal is to have:
>
> * A Meeting
> <2009-03-12 Thu 11:00-12:00>
> ^ ^
> | |
> | +---------- Automatically shifted
> +---------------- After the S-<up>
This is in fact how changing time works in many applications, and
it does make sense here as well. The commits implements this
change.
It also implements a way to change the start time of an entry from
the agenda. The date is normally changed with S-right/left.
Now, if you add a C-u prefix, the hour will be changed. If you
immediately press S-right/left again, hours will continue to be
changed.
A double prefix will do the same for minutes.
If a link is [[#name][desc]], the href wil be exacty href="#name".
So starting a link target with # will indicate that there will be an
explicit target for this.
Hsiu-Khuern Tang writes:
> If I export the file
>
> --------------------------------------------------
> #+OPTIONS: ^:{}
>
> * test
>
> a_{\alpha}
>
> a_{foo}
> --------------------------------------------------
>
> as HTML, I get "a_{α}" but "a<sub>foo</sub>": \alpha is not
> subscripted but foo is. I was expecting both to be subscripted,
> since they are in {}.
This is a bug, fixed now.
Wanrong Lin writes:
> Suppose I have an org file with following lines:
>
> * Test1
> Test2
>
> Now if I put the cursor at the beginning of the "Test2" line and
> press "M-S-RET" (Alt-Shift-Return on my machine), I got this:
>
> * Test1
> * Test2TODO
>
> The "TODO" keyword was inserted at the end instead of the
> beginning of the task text. This seems a bug to me.
Yes, this is a bug that occurs in the special case when the
heading stars are inserted in front of an existing line. The
commit adds code to make sure the correct position is used.
Carsten Dominik
Bastien Guerry