I've noticed a probably related bug. In a file like * before break between
If I put the cursor between break and between, M-ret causes the result * before * break between rather than what I expected: * before break * between With the holiday coming I might look at it also and figure out what is happening. R Horn Carsten Dominik writes: > Hi, > > yes, org-insert-heading is broken - nad I am trying to find time > to rewrite it. My top Org priority. > > - Carsten > > On 3.7.2013, at 00:11, John Hendy <jw.he...@gmail.com> wrote: > >> Hi Erik, >> >> >> Glad to see you around :) >> >> These all may be quite related. I haven't seen activity on those >> threads suggesting whether a) the documentation is, in fact, right or >> wrong or b) whether anyone has taken action to fix or adjust the >> behavior of M-RET or C-RET based on the complaints/counter-intuitive >> observations. >> >> Let me know if those are similar to your issue. Perhaps Bastien can >> comment on the state of these thread, now at least four in number... >> >> - http://www.mail-archive.com/emacs-orgmode@gnu.org/msg70718.html >> - http://osdir.com/ml/emacs-orgmode-gnu/2013-05/msg00846.html >> - http://permalink.gmane.org/gmane.emacs.orgmode/72399 >> >> I've taken to using C-RET in the meantime, as it seems to do what I >> often expect when reflexively pressing M-RET. Also, someone once >> corrected me on the documentation that "at the end of the line" might >> mean before the ellipsis, not after? >> >> >> Hope that helps! >> John >> >> >> On Tue, Jul 2, 2013 at 1:53 PM, Erik Iverson <erikriver...@gmail.com> wrote: >>> Hello, >>> >>> I am using a current git pull (Org-mode version 8.0.3, >>> release_8.0.3-345-g239aa7) and noticed behavior that's easiest to show >>> with a small example. If you save and visit the following org file, >>> >>> https://dl.dropboxusercontent.com/u/7514404/test.org >>> >>> you will see the behavior described and documented (assuming it's >>> reproducible under your version of emacs and orgmode). >>> >>> Briefly M-<RET> at the end of a *folded* headline that contains plain >>> list items will insert a new plain list item at the end of the >>> subtree, instead of a new top-level headline. I believe this conflicts >>> with the documentation for M-<RET>, which currently reads: >>> >>> ... If the command is used at the end of a folded subtree (i.e., >>> behind the ellipses at the end of a headline), then a headline like >>> the current one will be inserted after the end of the subtree... >>> >>> Best, >>> --Erik >>> >>
