From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: [RFC] Sloppy `org-element-context'? Date: Thu, 27 Mar 2014 16:28:54 +0100 Message-ID: <874n2jsls9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:35741) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTCEO-00018Q-JL for emacs-orgmode@gnu.org; Thu, 27 Mar 2014 11:28:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WTCEG-0002am-5T for emacs-orgmode@gnu.org; Thu, 27 Mar 2014 11:28:36 -0400 Received: from mail-we0-x235.google.com ([2a00:1450:400c:c03::235]:39601) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WTCEF-0002af-QC for emacs-orgmode@gnu.org; Thu, 27 Mar 2014 11:28:28 -0400 Received: by mail-we0-f181.google.com with SMTP id q58so1921074wes.12 for ; Thu, 27 Mar 2014 08:28:26 -0700 (PDT) Received: from selenimh ([91.224.148.150]) by mx.google.com with ESMTPSA id di9sm8184396wid.6.2014.03.27.08.28.24 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Mar 2014 08:28:25 -0700 (PDT) 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-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: Org Mode List --=-=-= Content-Type: text/plain Hello, As you may know, `org-element-context' returns the object under point, according to Org Syntax. The questions are: should it be a little sloppy, for convenience? And, if it should, what degree of sloppiness is acceptable? Note that, at the time being, the function is already somewhat sloppy, because it will return an object right before point. In the following example, "|" is point. Even though it is not on the bold object, evaluating (org-element-context) there will give: "*bold*| text" => (bold ...) Should we go further? A recent discussion about opening links in node properties suggests that some users expect to encounter Org syntax there. I believe this is not generally desirable. One reason is that contents of properties drawers are hidden most of the time, and we may forget about them. So, for example, an entry could appear in the agenda but the timestamp triggering it could be difficult to find. This is why SCHEDULED and DEADLINE keywords were not turned into node properties: they are always in sight. Another reason is that properties can contain really anything, including markup from other languages. For example, EXPORT_LATEX_HEADER property contains LaTeX code. As such, they should be kept as general as possible, that is as a pair of key and value, without any syntax attached to value, much like keywords. However, it is possible to still parse value of such properties, as a convenience feature in `org-element-context', as the attached patch does. Note that it has drawbacks. Let's consider the following idiomatic example, meant to do something on every active timestamp below point in the visible part of the buffer, (while (re-search-forward "<[0-9]\\{4\\}-" nil t) (let ((context (org-element-context))) (when (eq (org-element-type context) 'timestamp) ...))) Used without care, it will be applied to non-existing timestamps (e.g., timestamps in a node property) and could lead to confusing behaviour, like displaying an entry in the agenda because of an invisible timestamp. Anyway, here we are. I think it is important to define clearly what belongs to the syntax (I think it is quite good at the moment), what can be allowed for the sake of convenience, and what line should never be crossed (I firmly believe, for example, that `org-element-context' should never return objects in a comment, an example block, or a fixed-width area). Opinions? Regards, -- Nicolas Goaziou --=-=-= Content-Type: text/x-diff Content-Disposition: attachment; filename=0001-org-element-Make-org-element-context-sloppy.patch >From ab72802ab90950d8edc2d415443f089a1208f5cc Mon Sep 17 00:00:00 2001 From: Nicolas Goaziou Date: Thu, 27 Mar 2014 15:12:05 +0100 Subject: [PATCH] org-element: Make `org-element-context' sloppy * lisp/org-element.el (org-element-context): Allow to parse node properties. --- lisp/org-element.el | 22 ++++++++++++++++++---- 1 file changed, 18 insertions(+), 4 deletions(-) diff --git a/lisp/org-element.el b/lisp/org-element.el index d94243b..a774528 100644 --- a/lisp/org-element.el +++ b/lisp/org-element.el @@ -5598,7 +5598,9 @@ object type, but always include `:begin', `:end', `:parent' and `:post-blank'. As a special case, if point is right after an object and not at -the beginning of any other object, return that object. +the beginning of any other object, return that object. Also, +parse Org syntax and return objects in planning lines and node +properties, for convenience. Optional argument ELEMENT, when non-nil, is the closest element containing point, as returned by `org-element-at-point'. @@ -5668,8 +5670,12 @@ Providing it allows for quicker computation." (if (and (>= pos (point)) (< pos (line-end-position))) (narrow-to-region (point) (line-end-position)) (throw 'objects-forbidden element)))) - ;; At a planning line, if point is at a timestamp, return it, - ;; otherwise, return element. + ;; Convenience features. + ;; + ;; - At a planning line, if point is at a timestamp, return + ;; it, otherwise, return element. + ;; + ;; - Return objects in node properties values. ((eq type 'planning) (dolist (p '(:closed :deadline :scheduled)) (let ((timestamp (org-element-property p element))) @@ -5677,8 +5683,16 @@ Providing it allows for quicker computation." (<= (org-element-property :begin timestamp) pos) (> (org-element-property :end timestamp) pos)) (throw 'objects-forbidden timestamp)))) - ;; All other locations cannot contain objects: bail out. (throw 'objects-forbidden element)) + ((eq type 'node-property) + (beginning-of-line) + (search-forward ":" (line-end-position) t 2) + (skip-chars-forward " \t") + (if (> (point) pos) (throw 'objects-forbidden element) + (narrow-to-region (point) (line-end-position)) + ;; Do not limit object types in a node property. + (setq type 'paragraph))) + ;; All other locations cannot contain objects: bail out. (t (throw 'objects-forbidden element))) (goto-char (point-min)) (let ((restriction (org-element-restriction type)) -- 1.9.1 --=-=-=--