Captured nodes entered into the wrong level in emacs

[mobileorg-android on behalf of hjh]

Quite often, new nodes entered under a specific heading are transferred
into emacs under the parent of the correct heading. E.g., I entered new
nodes such as agenda_main.org : Appointments : Housewarming : Food (Food is
new; Housewarming already existed in emacs). After org-mobile-pull, Food
showed up under Appointments. In MobileOrg, it's very clearly under
Housewarming (can provide screenshots).

I don't know if this happens every time, but I've seen it frequently. It's
not a one-off glitch.

hjh

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of Henning Weiss]

Hi,

On Fri, Dec 28, 2012 at 1:31 PM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> Quite often, new nodes entered under a specific heading are transferred
> into emacs under the parent of the correct heading. E.g., I entered new
> nodes such as agenda_main.org : Appointments : Housewarming : Food (Food
> is new; Housewarming already existed in emacs). After org-mobile-pull, Food
> showed up under Appointments. In MobileOrg, it's very clearly under
> Housewarming (can provide screenshots).
>
> I don't know if this happens every time, but I've seen it frequently. It's
> not a one-off glitch.
>

It would be nice if you could troubleshoot the exact conditions when this
happens. I'm aware of this problem, but haven't managed to consistently
reproduce it. The org-mode component that finds target subheadings is most
likely at fault and the bug has most likely something to do with
spaces/newlines above and below the target heading.

Henning

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of hjh]

On Sat, Dec 29, 2012 at 6:06 AM, mobileorg-android on behalf of
Henning Weiss <mobileorg-android-/***@public.gmane.org> wrote:
> It would be nice if you could troubleshoot the exact conditions when this
> happens. I'm aware of this problem, but haven't managed to consistently
> reproduce it. The org-mode component that finds target subheadings is most
> likely at fault and the bug has most likely something to do with
> spaces/newlines above and below the target heading.

Hi,

I haven't been able to figure out a pattern for what breaks
org-mobile-pull when it tries to insert new nodes. But I did keep a
record of all the edits in the last week or so, copied literally from
mobileorg.org before org-mobile-pull.

All of these edits placed the node one level too high. That is, for
the first one, I should have seen:

* Top to-dos
** Blah
** Blah
** Today
*** Blah
*** Blah
*** TODO [#A] ---- reactivate account
*** Blah

But instead, I got:

* Top to-dos
** Blah
** Blah
** Today
*** Blah
*** Blah
*** Blah
** TODO [#A] ---- reactivate account

I have not been able to reproduce any of these problems using a new
org file with only dummy entries. And the problem doesn't occur
consistently. Some of the new nodes go directly into the right place
(usually if they are immediately under a top-level heading).

I tend not to use very many blank lines (anymore) in my org files.

Does anything leap out?

hjh


* F(edit:addheading) [[olp:agenda_main.org:Top to-dos /Today][Today]]
** Old value

** New value
TODO [#A] ---- reactivate account
** End of edit

* F(edit:addheading) [[olp:agenda_main.org:Top to-dos /Today][Today]]
** Old value

** New value
TODO [#A] Fix and mail ----'s HKU letter
** End of edit


* F(edit:addheading) [[id:227cbfa6-dd05-48b9-9868-c4c6f16cee22][Housewarming]]
** Old value

** New value
To buy [/]
- Napkins, plates, forks, spoons
- Cups for hot drinks (need others for cold?)
- Serving dishes
- Ikea 3-tier tray
- Tablecloth(s)
- Seating? ¥¥¥
** End of edit



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

** New value
Film exams
- (Several plain list entries, confidential, won't quote them here)
** End of edit

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of Henning Weiss]

Hi,

On Tue, Jan 8, 2013 at 2:47 PM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On Sat, Dec 29, 2012 at 6:06 AM, mobileorg-android on behalf of
> Henning Weiss <mobileorg-android-/***@public.gmane.org> wrote:
> > It would be nice if you could troubleshoot the exact conditions when this
> > happens. I'm aware of this problem, but haven't managed to consistently
> > reproduce it. The org-mode component that finds target subheadings is
> most
> > likely at fault and the bug has most likely something to do with
> > spaces/newlines above and below the target heading.
>
> Hi,
>
> I haven't been able to figure out a pattern for what breaks
> org-mobile-pull when it tries to insert new nodes. But I did keep a
> record of all the edits in the last week or so, copied literally from
> mobileorg.org before org-mobile-pull.
>
> All of these edits placed the node one level too high. That is, for
> the first one, I should have seen:
>
> * Top to-dos
> ** Blah
> ** Blah
> ** Today
> *** Blah
> *** Blah
> *** TODO [#A] ---- reactivate account
> *** Blah
>
> But instead, I got:
>
> * Top to-dos
> ** Blah
> ** Blah
> ** Today
> *** Blah
> *** Blah
> *** Blah
> ** TODO [#A] ---- reactivate account
>
> I have not been able to reproduce any of these problems using a new
> org file with only dummy entries. And the problem doesn't occur
> consistently. Some of the new nodes go directly into the right place
> (usually if they are immediately under a top-level heading).
>
> I tend not to use very many blank lines (anymore) in my org files.
>
> Does anything leap out?
>

Thanks for your effort. Unfortunately this still isn't enough for me to
reproduce the problem. Would you say that only entries from level 3 are
placed on level 2? Or is this true for entries lower than the 3. level?

Henning

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of hjh]

On Jan 8, 2013 10:55 PM, "mobileorg-android on behalf of Henning Weiss" <
mobileorg-android-/***@public.gmane.org> wrote:
> Thanks for your effort. Unfortunately this still isn't enough for me to
reproduce the problem. Would you say that only entries from level 3 are
placed on level 2? Or is this true for entries lower than the 3. level?

I'm pretty sure I saw the problem with lower-level nodes too.

How does org-mobile-pull search for the new node's parent? Some info about
that might help me spot something in common among my failed cases.

Thanks,
hjh

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of Henning Weiss]

I can't quite remember how it works. I only wrote the part that inserts the
new nodes from the position it gets from the olp/id. You can have a look at
org-mobile-locate-entry if your interested. It determines the location of
the cursor prior to the insert.

On Wed, Jan 9, 2013 at 8:17 AM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On Jan 8, 2013 10:55 PM, "mobileorg-android on behalf of Henning Weiss" <
> mobileorg-android-/***@public.gmane.org> wrote:
> > Thanks for your effort. Unfortunately this still isn't enough for me to
> reproduce the problem. Would you say that only entries from level 3 are
> placed on level 2? Or is this true for entries lower than the 3. level?
>
> I'm pretty sure I saw the problem with lower-level nodes too.
>
> How does org-mobile-pull search for the new node's parent? Some info about
> that might help me spot something in common among my failed cases.
>
> Thanks,
> hjh
>
> --
> You received this message because you are subscribed to the Google Groups
> "mobileorg-android" group.
> To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> To unsubscribe from this group, send email to
> mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/mobileorg-android?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of hjh]

On Wed, Jan 9, 2013 at 8:58 PM, mobileorg-android on behalf of Henning
Weiss <mobileorg-android-/***@public.gmane.org> wrote:
> I can't quite remember how it works. I only wrote the part that inserts the
> new nodes from the position it gets from the olp/id. You can have a look at
> org-mobile-locate-entry if your interested. It determines the location of
> the cursor prior to the insert.

I finally had time to do a couple of tests, though I haven't gotten
very far. I started with the observation that org-mobile-locate-entry
delegates to org-find-olp or org-id-find, so I tested those functions
directly. As far as I can tell, they are working as they should. That
is, doing "Evaluate and print" from the scratch buffer for these
expressions:

(org-find-olp (cons "~/Documents/mobileorg/agenda_main.org" (setq path
(mapcar 'org-link-unescape (org-split-string
"Appointments/Housewarming/Drinks" "/")))))

(org-id-find "227cbfa6-dd05-48b9-9868-c4c6f16cee22" 'marker)

... produces output lines like "#<marker at 22914 in agenda_main.org>"
and, if I go to agenda_main, "show all," go to the top of the buffer
and then C-u 22914 C-f, the cursor goes directly to the right entry.

This does narrow down the problem a little bit. It must be happening
after locating the proper entry, but before insertion -- meaning, when
the point (or mark?) is moved to the end of the subtree. It appears
this does not happen in org-mobile-locate-entry itself -- in that
function, the org-id branch ends with org-id-find, and the other
branch (olp) ends with org-find-olp. That puts me into the thicket of
org-mobile-apply, I suppose, which will tax my limited ability to read
lisp...

Any hints? Thanks --
hjh

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of hjh]

On 01/15/2013 03:23 PM, James Harkins wrote:
> I finally had time to do a couple of tests, though I haven't gotten
> very far. I started with the observation that org-mobile-locate-entry
> delegates to org-find-olp or org-id-find, so I tested those functions
> directly. As far as I can tell, they are working as they should. That
> is, doing "Evaluate and print" from the scratch buffer for these
> expressions:
>
> (org-find-olp (cons "~/Documents/mobileorg/agenda_main.org" (setq path
> (mapcar 'org-link-unescape (org-split-string
> "Appointments/Housewarming/Drinks" "/")))))
>
> (org-id-find "227cbfa6-dd05-48b9-9868-c4c6f16cee22" 'marker)
>
> ... produces output lines like "#<marker at 22914 in agenda_main.org>"
> and, if I go to agenda_main, "show all," go to the top of the buffer
> and then C-u 22914 C-f, the cursor goes directly to the right entry.
>
> This does narrow down the problem a little bit. It must be happening
> after locating the proper entry, but before insertion...

So, I've been playing with this some more, and I'm pretty confused.

I started looking at org-mobile-apply, and found some variables that I
thought would indicate the beginning and ending of the parent node
specified in a mobileorg.org entry:

(id-pos (condition-case msg
(org-mobile-locate-entry (match-string 4))
(error (nth 1 msg))))
(bos (point-at-bol))
(eos (save-excursion (org-end-of-subtree t t)))

And then I used (message...) to print out bos and eos (id-pos is some
other type, which I don't know how to print out). But, bos is not even
close to the result of calling org-mobile-locate-entry in the scratch
buffer, and I can't imagine what the relationship actually is.

org-end-of-subtree level = 1
org-mobile-apply: bos = 30238, eos = 30372
org-end-of-subtree level = 2
org-end-of-subtree level = 1 [3 times]

vs.

(org-mobile-locate-entry "id:227cbfa6-dd05-48b9-9868-c4c6f16cee22")
#<marker at 21153 in agenda_main.org>

From the top of the buffer, the right subtree actually starts at 21153,
so bos/eos are... something different from the character positions of
the desired subtree. What they are, I have no idea. 30238 is way out, in
the middle of a plain list that lives under a completely different
top-level heading.

C-c C-x M-w tells me "Copied: Subtree(s) with 3656 characters," which
again is rather different from eos - bos = 30372 - 30238 = 134.

I also put a (message) line into org-end-of-subtree. "org-end-of-subtree
level = 2" is correct. I don't know what is calling the same function on
a level 1 heading.

Does anyone here have more insight into these functions? Or, take it to
the orgmode list?

hjh

[mobileorg-android on behalf of hjh]

On 01/16/2013 04:09 PM, James Harkins wrote:
>
> So, I've been playing with this some more, and I'm pretty confused.
>
> I started looking at org-mobile-apply, and found some variables that I
> thought would indicate the beginning and ending of the parent node
> specified in a mobileorg.org entry:
>
> (id-pos (condition-case msg
> (org-mobile-locate-entry (match-string 4))
> (error (nth 1 msg))))
> (bos (point-at-bol))
> (eos (save-excursion (org-end-of-subtree t t)))

Less confused... bos and eos are positions within from-mobileorg.org,
not the target org file.

More good stuff: one detail point, and a significant result from edebug.

The point of detail: If I cycle global visibility in the org buffer that
will be edited by org mobile pull so that everything is visible, then I
can't reproduce the bug anymore.

1. On the mobile, add a node under one of my failing cases. Sync.
2. In emacs, cycle global visibility to show top-level nodes only.
3. Org mobile pull puts the new node in the wrong place.
4. Same as 1.
5. Same as 2, but *show* everything (instead of hiding as much as possible).
6. Org mobile pull puts the new node in the *right* place.

So, something confuses it when content is hidden.

With source level debugging, I can pinpoint where the problem occurs --
in org-mobile-edit:

((eq what 'addheading)
(if (org-on-heading-p) ; if false we are in top-level of file
(progn
(end-of-line 1)

;; RIGHT HERE
(org-insert-heading-respect-content)

(org-demote))
(beginning-of-line)
(insert "* "))
(insert new))

Everything before this point appears to be kosher.

Somewhere, org-insert-heading-respect-content calls org-end-of-subtree.
When the problem occurs, there are multiple calls to find the end of the
subtree. In my test case, I added a new fourth-level heading underneath
a third-level heading. During org-insert-heading-respect-content's first
call to org-end-of-subtree, the "level" identified* is correct = 3, AND
the end of the subtree is correctly identified as the beginning of the
next third-level heading. If it stopped there and inserted the new node
at exactly that point, there would be no problem.

* org-end-of-subtree identifies the level by (funcall outline-level).
"Level" is not a defun argument.

Then, somehow (which I haven't figured out), org-end-of-subtree is
called again, but now the "level" is found to be 1, and it finds the
beginning of the next first-level heading. Not coincidentally, this is
exactly the place where the new fourth-level heading is added (but now
it's magically changed into a second-level heading).

Unfortunately, I've already spent way too much time trying to debug this
and I really have to turn my attention seriously to some other projects.
Since I have a test case that consistently reproduces the problem, I'm
happy to run more tests, try patches etc. but I'm not able at this point
to spend another 2-3 hours in a day to track the issue down. Still,
narrowing the issue down to one specific function call in all of
org-mobile.el should be a useful finding.

(I wanted to add this to the bug tracker, but for some reason, I can't
get to github right now...)

Thanks,
hjh

[mobileorg-android on behalf of Matthew Jones]

Need a tldr here.... is the source of the problem within org-mode itself?


On Mon, Jan 21, 2013 at 6:08 AM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On 01/16/2013 04:09 PM, James Harkins wrote:
>
>>
>> So, I've been playing with this some more, and I'm pretty confused.
>>
>> I started looking at org-mobile-apply, and found some variables that I
>> thought would indicate the beginning and ending of the parent node
>> specified in a mobileorg.org entry:
>>
>> (id-pos (condition-case msg
>> (org-mobile-locate-entry (match-string 4))
>> (error (nth 1 msg))))
>> (bos (point-at-bol))
>> (eos (save-excursion (org-end-of-subtree t t)))
>>
>
> Less confused... bos and eos are positions within from-mobileorg.org, not
> the target org file.
>
> More good stuff: one detail point, and a significant result from edebug.
>
> The point of detail: If I cycle global visibility in the org buffer that
> will be edited by org mobile pull so that everything is visible, then I
> can't reproduce the bug anymore.
>
> 1. On the mobile, add a node under one of my failing cases. Sync.
> 2. In emacs, cycle global visibility to show top-level nodes only.
> 3. Org mobile pull puts the new node in the wrong place.
> 4. Same as 1.
> 5. Same as 2, but *show* everything (instead of hiding as much as
> possible).
> 6. Org mobile pull puts the new node in the *right* place.
>
> So, something confuses it when content is hidden.
>
> With source level debugging, I can pinpoint where the problem occurs -- in
> org-mobile-edit:
>
> ((eq what 'addheading)
> (if (org-on-heading-p) ; if false we are in top-level of file
> (progn
> (end-of-line 1)
>
> ;; RIGHT HERE
> (org-insert-heading-respect-**content)
>
> (org-demote))
> (beginning-of-line)
> (insert "* "))
> (insert new))
>
> Everything before this point appears to be kosher.
>
> Somewhere, org-insert-heading-respect-**content calls org-end-of-subtree.
> When the problem occurs, there are multiple calls to find the end of the
> subtree. In my test case, I added a new fourth-level heading underneath a
> third-level heading. During org-insert-heading-respect-**content's first
> call to org-end-of-subtree, the "level" identified* is correct = 3, AND the
> end of the subtree is correctly identified as the beginning of the next
> third-level heading. If it stopped there and inserted the new node at
> exactly that point, there would be no problem.
>
> * org-end-of-subtree identifies the level by (funcall outline-level).
> "Level" is not a defun argument.
>
> Then, somehow (which I haven't figured out), org-end-of-subtree is called
> again, but now the "level" is found to be 1, and it finds the beginning of
> the next first-level heading. Not coincidentally, this is exactly the place
> where the new fourth-level heading is added (but now it's magically changed
> into a second-level heading).
>
> Unfortunately, I've already spent way too much time trying to debug this
> and I really have to turn my attention seriously to some other projects.
> Since I have a test case that consistently reproduces the problem, I'm
> happy to run more tests, try patches etc. but I'm not able at this point to
> spend another 2-3 hours in a day to track the issue down. Still, narrowing
> the issue down to one specific function call in all of org-mobile.el should
> be a useful finding.
>
> (I wanted to add this to the bug tracker, but for some reason, I can't get
> to github right now...)
>
> Thanks,
>
> hjh
>
> --
> You received this message because you are subscribed to the Google Groups
> "mobileorg-android" group.
> To post to this group, send email to mobileorg-android@**googlegroups.com<mobileorg-android-/***@public.gmane.org>
> .
> To unsubscribe from this group, send email to
> mobileorg-android+unsubscribe@**googlegroups.com<mobileorg-android%2Bunsubscribe-/***@public.gmane.org>
> .
> For more options, visit this group at http://groups.google.com/**
> group/mobileorg-android?hl=en<http://groups.google.com/group/mobileorg-android?hl=en>
> .
>
>

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of hjh]

On Jan 22, 2013 3:13 AM, "mobileorg-android on behalf of Matthew Jones" <
mobileorg-android-/***@public.gmane.org> wrote:
>
> Need a tldr here.... is the source of the problem within org-mode itself?

Yes. To sum up:

1. The links to the parent nodes (which MobileOrg saves into mobileorg.org)
are correct. Test: Call org-mobile-locate-entry from the scratch buffer,
passing one of the links copied directly from mobileorg.org. The printed
output is a marker with a character index. Go into the target buffer, "show
all," then, from the top, hit C-u {n-1} C-f (substitute one less than the
index as the argument). Voilà, the point is at the start of the expected
headline.

2. Then, org-mobile-edit jumps to the end of the line and uses
org-insert-heading-respect-content to open up space for the new heading.
This uses org-end-of-subtree to find the next heading that is at the same,
or a higher, level. That call is correct the first time, but then it's
called again (for a reason I don't know) and this obliterates the correct
result in favor of an even higher level heading. So, the new content goes
in the wrong place.

3. The problem seems not to occur if all content is displayed in the target
buffer (no trees folded).

hjh

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of Matthew Jones]

Have we reported this directly to the org-mode folks via their mailing list?


On Mon, Jan 21, 2013 at 8:56 PM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On Jan 22, 2013 3:13 AM, "mobileorg-android on behalf of Matthew Jones" <
> mobileorg-android-/***@public.gmane.org> wrote:
> >
> > Need a tldr here.... is the source of the problem within org-mode itself?
>
> Yes. To sum up:
>
> 1. The links to the parent nodes (which MobileOrg saves into mobileorg.org)
> are correct. Test: Call org-mobile-locate-entry from the scratch buffer,
> passing one of the links copied directly from mobileorg.org. The printed
> output is a marker with a character index. Go into the target buffer, "show
> all," then, from the top, hit C-u {n-1} C-f (substitute one less than the
> index as the argument). Voilà, the point is at the start of the expected
> headline.
>
> 2. Then, org-mobile-edit jumps to the end of the line and uses
> org-insert-heading-respect-content to open up space for the new heading.
> This uses org-end-of-subtree to find the next heading that is at the same,
> or a higher, level. That call is correct the first time, but then it's
> called again (for a reason I don't know) and this obliterates the correct
> result in favor of an even higher level heading. So, the new content goes
> in the wrong place.
>
> 3. The problem seems not to occur if all content is displayed in the
> target buffer (no trees folded).
>
> hjh
>
> --
> You received this message because you are subscribed to the Google Groups
> "mobileorg-android" group.
> To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> To unsubscribe from this group, send email to
> mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/mobileorg-android?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+***@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of hjh]

On Jan 22, 2013 10:36 AM, "mobileorg-android on behalf of Matthew Jones" <
mobileorg-android-/***@public.gmane.org> wrote:
>
> Have we reported this directly to the org-mode folks via their mailing
list?

We have now.

http://permalink.gmane.org/gmane.emacs.orgmode/64989

[mobileorg-android on behalf of Matthew Jones]

Thanks!


On Wed, Jan 23, 2013 at 1:11 AM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On Jan 22, 2013 10:36 AM, "mobileorg-android on behalf of Matthew Jones" <
> mobileorg-android-/***@public.gmane.org> wrote:
> >
> > Have we reported this directly to the org-mode folks via their mailing
> list?
>
> We have now.
>
> http://permalink.gmane.org/gmane.emacs.orgmode/64989
>
> hjh
>
> --
> You received this message because you are subscribed to the Google Groups
> "mobileorg-android" group.
> To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> To unsubscribe from this group, send email to
> mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
> For more options, visit this group at
> http://groups.google.com/group/mobileorg-android?hl=en.
>

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To unsubscribe from this group, send email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
For more options, visit this group at http://groups.google.com/group/mobileorg-android?hl=en.

[mobileorg-android on behalf of hjh]

> On Wed, Jan 23, 2013 at 1:11 AM, mobileorg-android on behalf of hjh
> <mobileorg-android-/***@public.gmane.org
> <mailto:mobileorg-android-/***@public.gmane.org>> wrote:
>
> On Jan 22, 2013 10:36 AM, "mobileorg-android on behalf of Matthew
> Jones" <mobileorg-android-/***@public.gmane.org
> <mailto:mobileorg-android-/***@public.gmane.org>> wrote:
> >
> > Have we reported this directly to the org-mode folks via their
> mailing list?
>
> We have now.

Incidentally, while playing around with it a little bit more today, I
was able to make a "minimal complete example" that reproduces the issue
by a lisp expression -- so an org developer doesn't need MobileOrg to test.

http://article.gmane.org/gmane.emacs.orgmode/65133

This also makes me think... possibly org-mobile could avoid the problem
by going directly to the end of the subtree, without using
org-insert-heading-respect-content. I don't have time to look up all the
org-y and lisp-y functions just now to write a proof of concept, but
perhaps this (my test):

(org-with-point-at (org-mobile-locate-entry "olp:test.org:I/A")
(progn
(end-of-line 1)
(org-insert-heading-respect-content)
(org-demote)
(insert "2. This should be a third-level heading, but it isn't")
)
)

... could turn into something like this (pseudocode!!):

(org-with-point-at (org-mobile-locate-entry "olp:test.org:I/A")
(let (level (org-outline-level))
(org-end-of-subtree t) ; would we need another org-with-point-at?
<<< Pseudocode: insert 'level' stars, followed by one space >>>
(org-demote)
(insert "2. This should be a third-level heading, but it isn't")
)
)

This might not handle all the cases that
org-insert-heading-respect-content handles. On the other hand, the
complexity of that function introduces buggy behavior, and in the
MobileOrg usage, the function is only ever used to add an item under a
true heading, with *** (no plain lists). So perhaps simplifying the
operation in org-mobile-edit would be easier than waiting for a fix from
org.

hjh

[mobileorg-android on behalf of Henning Weiss]

Hi,

On Fri, Jan 25, 2013 at 8:31 AM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On Wed, Jan 23, 2013 at 1:11 AM, mobileorg-android on behalf of hjh
>> <mobileorg-android@**googlegroups.com<mobileorg-android-/***@public.gmane.org>
>> <mailto:mobileorg-android@**googlegroups.com<mobileorg-android-/***@public.gmane.org>>>
>> wrote:
>>
>> On Jan 22, 2013 10:36 AM, "mobileorg-android on behalf of Matthew
>> Jones" <mobileorg-android@**googlegroups.com<mobileorg-android-/***@public.gmane.org>
>> <mailto:mobileorg-android@**googlegroups.com<mobileorg-android-/***@public.gmane.org>>>
>> wrote:
>> >
>> > Have we reported this directly to the org-mode folks via their
>> mailing list?
>>
>> We have now.
>>
>
> Incidentally, while playing around with it a little bit more today, I was
> able to make a "minimal complete example" that reproduces the issue by a
> lisp expression -- so an org developer doesn't need MobileOrg to test.
>
> http://article.gmane.org/**gmane.emacs.orgmode/65133<http://article.gmane.org/gmane.emacs.orgmode/65133>
>
> This also makes me think... possibly org-mobile could avoid the problem by
> going directly to the end of the subtree, without using
> org-insert-heading-respect-**content. I don't have time to look up all
> the org-y and lisp-y functions just now to write a proof of concept, but
> perhaps this (my test):
>
> (org-with-point-at (org-mobile-locate-entry "olp:test.org:I/A")
> (progn
> (end-of-line 1)
> (org-insert-heading-respect-**content)
> (org-demote)
> (insert "2. This should be a third-level heading, but it isn't")
> )
> )
>
> ... could turn into something like this (pseudocode!!):
>
> (org-with-point-at (org-mobile-locate-entry "olp:test.org:I/A")
> (let (level (org-outline-level))
> (org-end-of-subtree t) ; would we need another org-with-point-at?
> <<< Pseudocode: insert 'level' stars, followed by one space >>>
> (org-demote)
> (insert "2. This should be a third-level heading, but it isn't")
> )
> )
>
> This might not handle all the cases that org-insert-heading-respect-**content
> handles. On the other hand, the complexity of that function introduces
> buggy behavior, and in the MobileOrg usage, the function is only ever used
> to add an item under a true heading, with *** (no plain lists). So perhaps
> simplifying the operation in org-mobile-edit would be easier than waiting
> for a fix from org.


This is a good suggestion. When you have time it would be great if you
could post a patch. This bug has annoyed me for quite some time, but I
never got around to fixing it.

Henning

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/mobileorg-android?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[mobileorg-android on behalf of hjh]

On Fri, Jan 25, 2013 at 8:59 PM, mobileorg-android on behalf of
Henning Weiss <mobileorg-android-/***@public.gmane.org> wrote:
> This is a good suggestion. When you have time it would be great if you could
> post a patch. This bug has annoyed me for quite some time, but I never got
> around to fixing it.

Okay, I played with this a bit and the attached patch seems to work,
at least in a couple of simple test cases.

CAVEAT: I have not put this patch through any real-world usage yet. I
just wanted to send it sooner rather than later. Maybe other sets of
eyes could find problems and then I could update before submitting to
the org list.

Thanks in advance for suggestions --
hjh

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/mobileorg-android?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[mobileorg-android on behalf of Henning Weiss]

On Mon, Jan 28, 2013 at 3:01 PM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On Fri, Jan 25, 2013 at 8:59 PM, mobileorg-android on behalf of
> Henning Weiss <mobileorg-android-/***@public.gmane.org> wrote:
> > This is a good suggestion. When you have time it would be great if you
> could
> > post a patch. This bug has annoyed me for quite some time, but I never
> got
> > around to fixing it.
>
> Okay, I played with this a bit and the attached patch seems to work,
> at least in a couple of simple test cases.
>
> CAVEAT: I have not put this patch through any real-world usage yet. I
> just wanted to send it sooner rather than later. Maybe other sets of
> eyes could find problems and then I could update before submitting to
> the org list.
>

The patch looks good and seems to work as expected. You should have no
problems getting it submitted.

I would like to see org-insert-todo-heading (or org-insert-subheading) to
be fixed though. Did I understand you correctly in that the bug is caused
by org-insert-todo-heading doesn't handle invisible headings properly?
Could a prior call to org-show-subtree fix that?

Henning

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/mobileorg-android?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[mobileorg-android on behalf of hjh]

On Jan 29, 2013 9:27 PM, "mobileorg-android on behalf of Henning Weiss" <
mobileorg-android-/***@public.gmane.org> wrote:
> The patch looks good and seems to work as expected. You should have no
problems getting it submitted.

Cool! Maybe there's some hope for me to pick up more lisp after all.

I thought later, though, probably I should add 2 to the outline level if
the user has set the customize variable to use only odd levels.

> I would like to see org-insert-todo-heading (or org-insert-subheading) to
be fixed though. Did I understand you correctly in that the bug is caused
by org-insert-todo-heading doesn't handle invisible headings properly?
Could a prior call to org-show-subtree fix that?

That's the funny thing, which I really don't understand. In my edebug
traciI had test.org open in another frame during debugging, and when it
reached the show-subtree call, I could see the parent node's payload and
child nodes, but the actual heading remained invisible -- hence, later
actions that expected it to be visible would not behave correctly.

I submitted that as a full bug report. It hasn't appeared on the bug
tracker at worg yet. Actually, all my posts about the issue on the org-mode
mailing list have met with deafening silence, so I fear it will get no
attention as long as I am the only person complaining about it.

hjh

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/mobileorg-android?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[mobileorg-android on behalf of Henning Weiss]

On Tue, Jan 29, 2013 at 3:06 PM, mobileorg-android on behalf of hjh <
mobileorg-android-/***@public.gmane.org> wrote:

> On Jan 29, 2013 9:27 PM, "mobileorg-android on behalf of Henning Weiss" <
> mobileorg-android-/***@public.gmane.org> wrote:
> > The patch looks good and seems to work as expected. You should have no
> problems getting it submitted.
>
> Cool! Maybe there's some hope for me to pick up more lisp after all.
>
> I thought later, though, probably I should add 2 to the outline level if
> the user has set the customize variable to use only odd levels.
>
> > I would like to see org-insert-todo-heading (or org-insert-subheading)
> to be fixed though. Did I understand you correctly in that the bug is
> caused by org-insert-todo-heading doesn't handle invisible headings
> properly? Could a prior call to org-show-subtree fix that?
>
> That's the funny thing, which I really don't understand. In my edebug
> traciI had test.org open in another frame during debugging, and when it
> reached the show-subtree call, I could see the parent node's payload and
> child nodes, but the actual heading remained invisible -- hence, later
> actions that expected it to be visible would not behave correctly.
>
Could a call to org-show-entry fix that?

> I submitted that as a full bug report. It hasn't appeared on the bug
> tracker at worg yet. Actually, all my posts about the issue on the org-mode
> mailing list have met with deafening silence, so I fear it will get no
> attention as long as I am the only person complaining about it.
>
This is probably due to that org-mobile currently doesn't have a
maintainer. It's pretty hard to get input for org-mobile related stuff, as
not many of the developers are familiar with it. Don't think any bad of it.
Some of my patches took quite some time before they got in.

Henning

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/mobileorg-android?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

[mobileorg-android on behalf of hjh]

On Jan 30, 2013 2:05 AM, "mobileorg-android on behalf of Henning Weiss" <
mobileorg-android-/***@public.gmane.org> wrote:
>> That's the funny thing, which I really don't understand. In my edebug
traciI had test.org open in another frame during debugging, and when it
reached the show-subtree call, I could see the parent node's payload and
child nodes, but the actual heading remained invisible -- hence, later
actions that expected it to be visible would not behave correctly.
>
> Could a call to org-show-entry fix that?

This does appear to work. That's probably better than my hack... erm,
patch. I'll submit the new patch (an even tinier change) directly to the
org list.

>> I submitted that as a full bug report. It hasn't appeared on the bug
tracker at worg yet. Actually, all my posts about the issue on the org-mode
mailing list have met with deafening silence, so I fear it will get no
attention as long as I am the only person complaining about it.
>
> This is probably due to that org-mobile currently doesn't have a
maintainer. It's pretty hard to get input for org-mobile related stuff, as
not many of the developers are familiar with it. Don't think any bad of it.
Some of my patches took quite some time before they got in.

I submitted it as a bug about non-interactive behavior of
org-insert-heading, mentioning mobile only as a case that reveals the bug.
If Bastien were treating it as a MobileOrg bug, he would be misreading the
report.

I suspect he's just swamped with other issues, though.

hjh

--
You received this message because you are subscribed to the Google Groups "mobileorg-android" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mobileorg-android+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
To post to this group, send email to mobileorg-android-/JYPxA39Uh5TLH3MbocFF+G/***@public.gmane.org
Visit this group at http://groups.google.com/group/mobileorg-android?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.