From mboxrd@z Thu Jan 1 00:00:00 1970 From: Allen Li 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 Message-ID: References: <87r2eojaf7.fsf@nicolasgoaziou.fr> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:51744) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gWpsk-0005KF-3N for emacs-orgmode@gnu.org; Tue, 11 Dec 2018 16:47:59 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gWpsf-0003A4-F6 for emacs-orgmode@gnu.org; Tue, 11 Dec 2018 16:47:56 -0500 Received: from mail-io1-xd2f.google.com ([2607:f8b0:4864:20::d2f]:41364) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gWpsa-00036l-9B for emacs-orgmode@gnu.org; Tue, 11 Dec 2018 16:47:50 -0500 Received: by mail-io1-xd2f.google.com with SMTP id s22so13119799ioc.8 for ; Tue, 11 Dec 2018 13:47:46 -0800 (PST) In-Reply-To: <87r2eojaf7.fsf@nicolasgoaziou.fr> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: "Emacs-orgmode" To: Org Mode List On Tue, Dec 11, 2018 at 8:27 AM Nicolas Goaziou 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