Re: [O] Bug: org-map-entries narrowing smaller than entry [9.1.14 (9.1.14-1049-g04641c-elpaplus @ /home/ionasal/.emacs.d/elpa/org-plus-contrib-20181203/)]

[Allen Li]

On Tue, Dec 11, 2018 at 8:27 AM Nicolas Goaziou <address@hidden> wrote:
> > (((headline (:raw-value "stuff" :begin 17 :end 36 :pre-blank 0
> > :contents-begin 26 :contents-end 36 ...)) 17 35))
>
> `org-element-at-point' ignores narrowing.

Yes, but my issue is with the fact that the entry bounds reported by
org-element-at-point disagrees with the bounds used by org-map-entries
narrowing, in specific edge cases.

For example, when running org-map-entries on a tree, the bounds
reported by org-element-at-point can be used *except* for the last
entry, which will extend one character past the narrowing.

It seems to me that whatever Org mode considers the bounds for an
entry should be used consistently.

I looked into this and it seems this behavior is deliberate in
org-narrow-to-subtree.  I can see why this behavior exists, because if
point is at the end of an entry (after the newline), it is considered
to be pointing at the next entry.  Thus the narrowing is artificially
tightened to make it impossible to position point at the end of an
entry.  Example, the bounds of an entry/subtree delimited by $:

* A
$* B
** foo
** bar
$* C

The bounds used by narrowing:

* A
$* B
** foo
** bar$
* C

If one were to narrow to a subtree and delete the entire visible
region, it would leave an extra newline that should be considered part
of the deleted subtree.  If such an operation were repeated, it would
leave behind many extra newlines.

I think this issue is medium/low priority and difficult to resolve.  I
have worked around it for my use case.  However, I still think it is
an issue since it's an edge case that users of org-map-entries will
need to take into account.

>
> Regards,
>
> --
> Nicolas Goaziou