Re: Bug: refiling gobbles a newline and absorbs the next heading [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Hello, Miguel Morin writes: > TL;DR: starting a capture item and deleting the new lines at the end > of the capture buffer gobbles the next heading, and refiling moves the > gobbled heading along with the new capture item. I'm confused. Your bug title is about refiling, yet, all your message is about setting up capture in various ways. Could you update Org (Org 9.3.1 has been released last week) and try again? Also, could you provide an ECM demonstrating how to reproduce the issue in a simple way, not necessarily how you tried to work around it ? :) Thank you. Regards, -- Nicolas Goaziou
Bug: refiling gobbles a newline and absorbs the next heading [9.1.9 (release_9.1.9-65-g5e4542 @ /Applications/Emacs.app/Contents/Resources/lisp/org/)]
Hello,
TL;DR: starting a capture item and deleting the new lines at the end of the
capture buffer gobbles the next heading, and refiling moves the gobbled heading
along with the new capture item.
I asked on emacs.stackexchange and found no solution:
https://emacs.stackexchange.com/questions/53526/org-mode-refiling-gobbles-a-newline-and-absorbs-the-next-heading
In the course of fixing this, I found another bug in using the hook
`org-capture-before-finalize-hook`, which adds text at the beginning and end of
the org buffer and not in the beggining and end of the capture item.
Full details, copied from the StackExchange thread:
I often have this problem in Org mode: I write an item with org-capture, refile
it, and days later I see a result like this:
*** TODO some task
some notes** StackExchange
I believe that the problem is that org capture inserts the text into the
buffer, and if the item does not end with a newline, it gobbles the delimiter
to the next heading and both get refiled together.
I already added two newlines to my capture template to minimize this problem.
My capture template is:
``` lisp
(setq org-capture-templates
'(("t" "Todo" entry (file+headline "~/org/gtd.org" "Reminders")
"* TODO %?\n\n"))
```
If I try a new item with `C-c c t` and type something, I see it appear in the
main buffer. If I delete the newline at the end, the newline is deleted in the
buffer too and gobbles the next line. Deleting further characters in the
capture buffer does not delete them from the main buffer.
I think I could add a hook such as `(add-hook 'org-capture-before-finalize-hook
...)` but I'm not sure how to include a newline and how to do it before
refiling, to avoid the next item being refiled with the captured item.
How can I fix this problem?
**Update**: Following @Aquaactress's suggestions, I tried two methods. Both
fail and the versions may be important:
Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/Applications/Emacs.app/Contents/Resources/lisp/org/)
GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.20 Version
10.14.3 (Build 18D109)) of 2019-09-02
In the first method, I added `:empty-lines` in the org-capture template:
```lisp
(setq org-capture-before-finalize-hook nil)
(setq org-capture-templates
'(("t" "Todo" entry (file+headline "~/test.org" "heading 1")
"* TODO %?\n" :empty-lines 1)))
```
The result in screenshots is below: I add a capture item, delete newlines from
the end of the org-capture buffer, and refile. The heading next to the refiled
item is gobbled:
[![Empty lines method, step 1 - create an org-capture item][1]][1]
[![Empty lines method, step 2 - delete lines from end of org-capture
buffer][2]][2]
[![Empty lines method, step 3 - refile][3]][3]
In the second method, I added a function that inserts new lines at the
beginning and end of the org capture buffer (for exposition, I also add `hello
world!` to show that these insertions go at the beginning and end of the whole
org buffer, not the org-capture buffer):
```lisp
(setq org-capture-before-finalize-hook nil)
(defun +org|insert-newlines ()
(beginning-of-buffer) (insert "\nhello world!\n")
(end-of-buffer) (insert "\nhello world!\n"))
(add-hook 'org-capture-before-finalize-hook #'+org|insert-newlines)
(setq org-capture-templates
'(("t" "Todo" entry (file+headline "~/test.org" "heading 1")
"* TODO %?\n" :empty-lines 1)))
```
The result in screenshots is below: I add a capture item, delete newlines from
the end of the org-capture buffer, and refile. The heading next to the refiled
item is gobbled and the lines inserted go at the beginning and end of the
buffer, instead of the org-capture buffer.
[![Insert lines method, step 1 - add org-capture item][4]][4]
[![Insert lines method, step 2 - delete newlines from end of org-capture
buffer][5]][5]
[![Insert lines method, step 3 - refile][6]][6]
[1]: https://i.stack.imgur.com/6cUlo.png
[2]: https://i.stack.imgur.com/GPwg8.png
[3]: https://i.stack.imgur.com/tzAJI.png
[4]: https://i.stack.imgur.com/xcKva.png
[5]: https://i.stack.imgur.com/g5sIT.png
[6]: https://i.stack.imgur.com/D1H8l.png
[7]: https://i.stack.imgur.com/l6a55.png
Emacs : GNU Emacs 26.3 (build 1, x86_64-apple-darwin18.2.0, NS appkit-1671.20
Version 10.14.3 (Build 18D109))
of 2019-09-02
Package: Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @
/Applications/Emacs.app/Contents/Resources/lisp/org/)
current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-after-todo-state-change-hook '(org-clock-out-if-current)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-mode-hook '(#[0 "\300\301\302\303\304$\207"
[add-hook
Format of Effort estimates should be mentioned in its Info node
Currently, the Info node about effort estimates does not mention what format should it be written in. This causes confusion, as a user might assume that it's the same format as schedulers (10m, 6h, etc.) like I did. Simply mentioning "Effort estimates need to have the format H:MM" (copied from the docstring or org-effort-property, the only* description of the format I could find) in the Info node would be enough. *: searching for regexp effort.*format and manually filtering out the other 3 matches
Re: org-element-context in table.el behavior
Ok, thanks for confirming! Nicolas Goaziou writes: > Hello, > > John Kitchin writes: > >> I have run into a surprise with org-element-context on a link in a table.el >> cell. It is best illustrated here: >> >> +---++ >> | # | name | >> +---++ >> | 1 | [[./test.org]] | >> +---++ >> >> #+BEGIN_SRC emacs-lisp :results code >> (save-excursion >> (re-search-backward (concat "test." "org")) >> (org-element-context)) >> #+END_SRC >> >> >> #+RESULTS: > >> #+begin_src emacs-lisp >> (table >> (:begin 1463 :end 1563 :type table\.el :tblfm nil :contents-begin nil >> :contents-end nil :value "+---++\n| # | name >> |\n+---++\n| 1 | [[./test.org]] |\n+---++\n" >> :post-blank 1 :post-affiliated 1463 :parent nil)) >> #+end_src >> > > [...] > >> Is this expected behavior, or a bug? > > This is expected: table.el tables, as their name suggest, are opaque to > Org mode. In particular, it doesn't know how to parse them. It just > feeds table.el with them at export time. > > Regards, -- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
Re: org-element-context in table.el behavior
Hello, John Kitchin writes: > I have run into a surprise with org-element-context on a link in a table.el > cell. It is best illustrated here: > > +---++ > | # | name | > +---++ > | 1 | [[./test.org]] | > +---++ > > #+BEGIN_SRC emacs-lisp :results code > (save-excursion > (re-search-backward (concat "test." "org")) > (org-element-context)) > #+END_SRC > > > #+RESULTS: > #+begin_src emacs-lisp > (table > (:begin 1463 :end 1563 :type table\.el :tblfm nil :contents-begin nil > :contents-end nil :value "+---++\n| # | name > |\n+---++\n| 1 | [[./test.org]] |\n+---++\n" > :post-blank 1 :post-affiliated 1463 :parent nil)) > #+end_src > [...] > Is this expected behavior, or a bug? This is expected: table.el tables, as their name suggest, are opaque to Org mode. In particular, it doesn't know how to parse them. It just feeds table.el with them at export time. Regards, -- Nicolas Goaziou
org-element-context in table.el behavior
Hi, I have run into a surprise with org-element-context on a link in a table.el cell. It is best illustrated here: +---++ | # | name | +---++ | 1 | [[./test.org]] | +---++ #+BEGIN_SRC emacs-lisp :results code (save-excursion (re-search-backward (concat "test." "org")) (org-element-context)) #+END_SRC #+RESULTS: #+begin_src emacs-lisp (table (:begin 1463 :end 1563 :type table\.el :tblfm nil :contents-begin nil :contents-end nil :value "+---++\n| # | name |\n+---++\n| 1 | [[./test.org]] |\n+---++\n" :post-blank 1 :post-affiliated 1463 :parent nil)) #+end_src I expected the element in this code to be a link, e.g. like in this next example: [[./test.org]] #+BEGIN_SRC emacs-lisp :results code (save-excursion (re-search-backward (concat "test." "org")) (org-element-context)) #+END_SRC #+RESULTS: #+begin_src emacs-lisp (link (:type "file" :path "./test.org" :format bracket :raw-link "./test.org" :application nil :search-option nil :begin 908 :end 922 :contents-begin nil :contents-end nil :post-blank 0 :parent (paragraph (:begin 907 :end 924 :contents-begin 907 :contents-end 923 :post-blank 1 :post-affiliated 907 :parent nil #+end_src Is this expected behavior, or a bug? John --- Professor John Kitchin Doherty Hall A207F Department of Chemical Engineering Carnegie Mellon University Pittsburgh, PA 15213 412-268-7803 @johnkitchin http://kitchingroup.cheme.cmu.edu
