David Maus writes:
> When `org-previous-item' is called on an item with nothing above it
> Orgmode enters an infinite loop. The reason is that
> `org-previous-item' searches for non-empty lines by moving point up
> line by line and if there is nothing above an item point gets stuck on
> begin of buffer.
>
> example.org
> ,----
> |
> | - Item
> `----
>
> Move point on Item, M-x org-previous-item RET and Orgmode enters the
> infinite loop.
>
> Attached patch adds a conditional clause to `org-previous-item' that
> leaves the search loop if point reaches beginning of buffer.
Daniel S. Sinder writes:
> Here's an "odd" problem when I call org-archive-subtree with a
> prefix argument. It seems that DONE subtrees are not found if
> I'm using odd level headlines. I've tried this minimal test
> case:
>
> ---- begin: test case 1 ----
> #+STARTUP: hidestars odd
>
> * DONE Project 1
> *** DONE Task 1.1
> *** DONE Task 1.2
> ---- end: test case 1 ----
>
> If I put the cursor on the level-1 headline and do C-u C-c C-x
> C-s, I am not prompted if I want to archive the level-3 children.
> However, if I remove 'odd' from the STARTUP line and move the
> level 3 headlines to level 2, so I have this:
>
> ---- begin: test case 1 ----
> #+STARTUP: hidestars
>
> * DONE Project 1
> ** DONE Task 1.1
> ** DONE Task 1.2
> ---- end: test case 1 ----
>
> then a repeat of the same command (C-u C-c C-x C-s) correctly
> asks if I want to archive the two level-2 headlines.
>
> I've removed my personal customizations and the problem does not
> go away.
Paul Griepentrog writes:
> Every once in a while I use org-mode in a buffer that is not
> associated with a file... and then org-goto gets confused. To repeat:
>
> BUFFER-NO-FILE
> ---------------
> * One
> - a
> * Two
> - b
> ---------------
>
> M-x org-mode
> C-c C-j
> org-get-refile-targets: Wrong type argument: stringp, nil
>
> [...]
>
> This patch fixes it:
Julien Barnier writes:
> I recntly noticed that in some specific cases, the final '}' was
> esacped when exproting an emphasis element to LaTeX.
>
> For example, the following element :
>
> /aa/
>
> Is exported to :
>
> \emph{aa\}
>
> This does not append if the string begins with a space or if it
> is ASCII-only. For example, the followig strings are exported
> correctly :
>
> /aaa/
> //
>
> I don't understand why the problem only occurs with non-ASCII chars,
> but I think that the regexp to protect added special chars in the
> org-export-latex-fontify function is missing a '?' in the
> beginning. Tha attached patch corrects it.
Bernt Hansen writes:
> ,----[ test.org ]
> |
> | * Main task
> | ** DONE Task 1
> | ** DONE Task 2
> | ** TODO Task 4
> | ** TODO Task 3
> | ** TODO Task 5
> | * Next task
> `----
>
> Put the point on * Main Task
> C-x n s to narrow to subtree
> C-c C-v to show active TODOs
> Put point on TODO Task 4
> M-down arrow
> M-up arrow
>
> generates
>
> Debugger entered--Lisp error: (error "before first heading")
Nicolas Girard writes:
> My point was, in the following two examples, the empty lines right
> before "C" should be preserved in the LaTeX output.
>
> Cheers,
> Nicolas
>
> #===
> - A2
> - B2
>
> C
> #===
>
>
> #===
> - A3
> - B3
>
>
> C
> #===
Variable names in gnuplot source code preceded by the '$' character
will be expanded to their value before the code is executed. For
example the following will results in the evaluation of 'plot
sin(x)' by gnuplot.
"sin(x)"
plot $fun
Add a variable org-complete-tags-always-offer-all-agenda-tags, which makes org
complete all tags from all agenda files if non-nil. Usually, setting it
locally to t in org-remember buffers is most convenient.
Insertion of new results was failing if the block was followed by
end-of-buffer. Also, if the block was followed by non-empty lines, the
\#+resname was being inserted away from column 0.
Carsten Dominik
Eric Schulte
Tassilo Horn
Benjamin Andresen
Jan Böcker
Dan Davison