Re: [O] Bug: org-insert-heading-respect-content inserts at the wrong level if target heading is invisible [7.9.2 (release_7.9.2-883-g6fb36e.dirty @ /home/dlm/share/org-mode.git/lisp/)]

[James Harkins]

On Tue, Mar 5, 2013 at 1:41 AM, Bastien <address@hidden> wrote:
> There is some obscure issues here... I fixed various things in
> `org-insert-heading' in master, but inserting in invisible parts of
> the subtree is still unstable.  So I went and used the workaround you
> suggested (i.e. org-show-subtree) in the maint branch, so that it will
> be in 7.9.4.

Apologies -- this seems to be the issue that wouldn't die -- but I
have to report another failure with this.

I just did org-mobile-pull with the following entry:

~~
* F(edit:addheading) [[olp:semester.org:Dates][Dates]]
** Old value

** New value
Graduating exams
the modern music Important Notice:.....
** End of edit
~~

This means the new heading should be at the second level, underneath
Dates. Instead, it was added as the topmost *first* level heading:

~~ BEFORE
#+LAST_MOBILE_CHANGE: 2013-03-13 16:38:42

* Dates
** DONE Teachers' meeting
~~

~~ AFTER
* Graduating exams
the modern music Important Notice:....#+LAST_MOBILE_CHANGE: 2013-03-13 16:38:42
* Dates
** DONE Teachers' meeting
~~

~~ EXPECTED
#+LAST_MOBILE_CHANGE: 2013-03-13 16:38:42

* Dates
** DONE Teachers' meeting
** ... a few other level 2 headings ...
** Graduating exams
the modern music Important Notice:....
~~

Also, "#+LAST_MOBILE_CHANGE:" should be the first line in any org file
that's being synced to MobileOrg, but
(org-insert-heading-respect-content '(4) t) ignores this.

BTW, I believe the arg '(4) is incorrect. In MobileOrg (at least in
android -- actually, I think the iPhone doesn't support this feature
yet), new nodes go to the bottom of the parent's children. They should
not be inserted at the top in Emacs.

This is slightly different from the earlier bug. "* Dates" *is* a
top-level heading in the target file -- hence, it *can't* be
invisible. Nonetheless, when inserting the new heading, it seems to be
reading the level of the target node as level 0, rather than level 1.
After that, the new node goes at the top of level 1 (which will also
obliterate any #+ preamble the file might have).

This may be a recent issue. I updated via git after you said that you
had put my workaround in place, and I don't remember seeing this
problem before. New second-level nodes did go into the right places. I
saw this issue only today (git pull yesterday).

Thanks...
hjh