Use `gnus-summary-article-header' function when in gnus-summary-mode.
This way the article doesn't get displayed unnecessarily. We don't use
this function in the gnus-article-mode because it is not reliable.
Thanks to Leo for this suggestion.
Eric Schulte writes:
> Attached is a small patch for a small issue.
>
> Sometimes a language uses a major mode which can't be guessed
> from it's name. This patch introduces the `org-src-lang-modes'
> variable which can be used to map language names to major modes
> when this is the case. This is used when editing a source-code
> block, or when exporting fontified source-code with htmlize.
>
> So far the only instance of this that I know of is ocaml and
> tuareg-mode, so that's the only thing that `org-src-lang-modes'
> is pre-populated with. Maybe there are other instances as well?
Nick Dokos writes:
> I define a LaTeX macro at the top of my document, like so:
>
> ,----
> | ...
> | #+LATEX_HEADER: \newcommand{\rowstyle}[1]{\gdef\currentrowstyle{#1}%
> | #+LATEX_HEADER: #1\ignorespaces
> | #+LATEX_HEADER: }
> | ...
> `----
>
> and export - I get the following inserted:
>
> ,----
> | ...
> | \begin{document}
> |
> |
> |
> |
> |
> | \$\^{}{1}\$ FOOTNOTE DEFINITION NOT FOUND: 1
> | ...
> `----
>
> Obviously, the macro argument spec is mistaken for a footnote.
Adds the output of 'git describe' to the org-version string if we are running
from a git repository. This identifies exactly what commit is checked out in
the org-mode git repository when reporting the org-mode version number.
org-version returns something like:
Org-mode version 6.29trans (release_6.29c.42.g5996)
which shows 6.29trans (somewhere after the last release tag) which
is 42 commits after release_6.29c at git commit 5996.
The git describe information is not included if org mode is not
running from a git repository.
This bug was caused by commit
8c177dc832, and reported by Matt
Lundin. The problem was that this commit tried to remove the text
propertes of the MATCH part of an agenda command. However, in block
commands, the MATCH part is not a string.
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.