From: Allen Li <darkfeline@felesatra.moe>
To: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: 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/)]
Date: Tue, 11 Dec 2018 13:47:34 -0800 [thread overview]
Message-ID: <CADbSrJxs23uGtr+VZA3ETzXRQ+tHL3S-5okkekpxh6MuH3RMJw@mail.gmail.com> (raw)
In-Reply-To: <87r2eojaf7.fsf@nicolasgoaziou.fr>
On Tue, Dec 11, 2018 at 8:27 AM Nicolas Goaziou <mail@nicolasgoaziou.fr> 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
next prev parent reply other threads:[~2018-12-11 21:47 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-11 7:43 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
2018-12-11 16:27 ` Nicolas Goaziou
2018-12-11 21:47 ` Allen Li [this message]
2018-12-12 12:21 ` Nicolas Goaziou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.orgmode.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CADbSrJxs23uGtr+VZA3ETzXRQ+tHL3S-5okkekpxh6MuH3RMJw@mail.gmail.com \
--to=darkfeline@felesatra.moe \
--cc=emacs-orgmode@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).