On Thu, Feb 15, 2018 at 1:02 PM Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> Hello, > Allen Li <darkfel...@felesatra.moe> writes: > > With the org file: > > > > * foo > > some content > > * bar > > some content 1 > > some content 2 > > > > 1. C-s foo RET > > 2. C-c C-x C-w > > 3. C-r some RET > > 4. C-c C-x C-y > > > > Final content is > > > > * bar > > some content 1 > > * foo > > some content > > some content 2 > I can reproduce it. > > The behavior is insidious when the contents are folded: > > > > * foo... > > * bar... > > > > turns into > > > > * bar... > > * foo... > IIUC, you cannot reproduce the example above when contents are folded, > since you do not have access to the headline contents. > > This can displace property and logbook drawers, timestamps, etc with very > > little visual indication. > > > > Is this behavior even desirable? To me, killing and yanking subtrees > > should keep the content with the headings and not "splice" subtrees into > > the middle of another heading's content > But you did yank the contents of the subtree into the middle of another > heading's content. So, what should do Org? Decide that you don't know > what you are doing and paste it at the end of the current section? What > if you really want to split the current section? I modified the example a bit and made the undesired behavior unclear. * foo :PROPERTIES: :ID: a :END: * bar :PROPERTIES: :ID: b :END: Folded, this looks like * foo... * bar... With point on the f in foo, press C-c C-x C-w. With point on the b in bar, press C-c C-x C-y. Results in * bar * foo... Unfolded, this looks like * bar * foo :PROPERTIES: :ID: a :END: :PROPERTIES: :ID: b :END: I would expect C-c C-x C-y to work like C-RET rather than M-RET, that is to always append after the heading and body rather than splitting it. > Is there any good solution to this problem? > Regards, > -- > Nicolas Goaziou
