Hsiu-Khuern writes:
> In contrib/lisp/org-export-bibtex.el, the BiBTeX file has to
> match the Emacs regexp "\w+". So a line like
>
> #+BIBLIOGRAPHY: mybib_new
>
> will not work because of the underscore character in the
> filename. (I suppose the actual behavior depends on the local
> Emacs settings that affect the "syntax table".) May I propose
> changing the regexp to "[[:alnum:]_]+"?
>
> Initially, I was stumped by this because I thought \w was a
> "regular" regexp :), such as defined in sed, and would match
> underscores as well.
An entry `#+TODO:' without content make `M-x org-mode' fail.
While it may cause problems to have no TODO keywords defined, this
should not make entering the mode fail.
It is possible that the regular expressions for LaTeX snippets match
at nested locations. For example, Nick Dokos submitted this:
,----
| #+LaTeX_HEADER: \usepackage{amsmath}
|
| * foo
|
| \[
| \begin{matrix}
| 1&d\\
| d&d\\
| \end{matrix}
| \]
|
`----
where the snippet regexps match at \[ ... \] and also at
\\begin{matrix}.
This would lead to two nested overlays being placed. With this
commit, only the outer one will remain.
A `save-excursion' around a call to org-table-align make point end up
*before* the table. The reason is that a table align replaces the
entire table, including the newline before it. When the table is
removed in order to be replaced, the marker created by
`save-excursion' slips. `org-table-align' has it's own, built-in
`save-excursion' by remembering the line and column where the cursor
was before the align.
However, if you are using arguments, it is required that the opening
parenthesis is attached to the macro name, and that the closing
parenthesis is attached to the three closing braces.
With the following org file:
------
Foo
In which foos are described.
#+OPTIONS: num:nil author:nil creator:nil timestamp:nil d:nil toc:nil skip:t
#+TITLE:
* The construction of a foo
** Armaments
------
I found exporting to ASCII gave five leading blank lines. The
following patch reduces that to one. (I'd love some help in tracking
down that final one.)
New variable `org-agenda-skip-scheduled-if-deadline-is-shown' to avoid
that a entry shows up in the agenda for today for both a scheduling
and a deadline entry. See the docstring of the variables for more
details.
Leo writes:
> Hi there,
>
> ,----[ (info "(org)Structure editing") ]
> | `C-<RET>'
> | Just like `M-<RET>', except when adding a new heading below the
> | current heading, the new heading is placed after the body instead
> | of before it. This command works from anywhere in the entry.
> `----
>
> Inside a substree and with the point at the beginning of a line, C-RET
> turns the current line into a heading. In the following example, ><
> indicates where the point is.
>
> ----------------
> * Sample
> < This is not a heading
> ----------------
>
> After C-RET, it changes to
> ----------------
> * Sample
> * This is not a heading
> ----------------
>
> I can reproduce this with org 6.29c as included in Emacs. Can someone
> else reproduce this bug?
Dan Griswold writes:
> Hi there,
>
> Well, I think this a bug.
>
> Given this org input file:
>
> ,----
> | * Things
> | ** A Heading
> | - some
> | - stuff
> | - in
> | - a
> | - list
> | ** Another heading
> | - another
> | - list
> `----
>
> then if I select the level one heading (titled "Things")
> with C-c @, and export to LaTeX using C-c C-e l, I get this
> output:
>
> ,----
> | % Created 2009-07-29 Wed 20:24
> | \documentclass[12pt]{article}
> | \usepackage[utf8]{inputenc}
> | \usepackage[T1]{fontenc}
> | \usepackage{graphicx}
> | \usepackage{longtable}
> | \usepackage{hyperref}
> |
> |
> | \title{Things}
> | \author{Daniel M. Griswold}
> | \date{July 29, 2009}
> |
> | \begin{document}
> |
> | \maketitle
> |
> | ** A Heading
> | \begin{itemize}
> | \item some
> | \item stuff
> | \item in
> | \item a
> | \item list
> | \end{itemize}
> | ** Another heading
> | \begin{itemize}
> | \item another
> | \item list
> | \end{itemize}
> |
> | \end{document}
> `----
>
> Note that the top level headings ("A Heading" and "Another
> Heading") are not exported as \section, but with the
> asterisks they have in the org file:
>
> ,----
> | ** A Heading
> | \begin{itemize}
> |
> | ... snip ...
> |
> | \end{itemize}
> | ** Another heading
> `----
>
> Exporting the whole file does what it's supposed to do:
> export the headlines as \section and \subsection.
This commit fixes the issue.
Bernt Hansen writes:
> Every so often I run into a situation where bulk refiling
> doesn't work anymore.
>
> I currently have 15 items in my refile.org file that I want
> to refile to other locations. I marked a few of them and
> bulk refiled them just fine. Then I marked a few more and B
> r fails with "Cannot find entry for marker #<marker at
> 297156 in norang.org>"
>
> I think this happens when I mark multiple tasks in the same
> subtree (i.e. the parent and a sibling) and refile both to
> the same location. After that it gets confused.
>
> If I have a task like this in refile.org
>
> #+FILETAGS: REFILE
> * Test
> ** Test 2
>
> and run a tags match on REFILE I see both tasks. Mark both
> with m in the agenda and B r to some other location. It
> refiles the first (and this moves the sibling too) and then
> it's broken after that.
>
> I get the following backtrace
>
> Debugger entered--Lisp error: (error "Cannot find entry for
> marker #<marker at 297156 in norang.org>")
Indeed the happens because, when a parent gets refiled or
achieved, any entries corresponding to its children are
removed from the agenda.
We address this issue by
- sorting the markers, to make sure parents will be handled
before children
- No longer throwing an error when a bulk action entry no
longer is present in the agenda - most likely it was taken
care of together with its parent.
Carsten Dominik
John Wiegley
Bastien Guerry
Andrew Stribblehill