From mboxrd@z Thu Jan 1 00:00:00 1970 From: Bastien Subject: Re: [RFC] Sloppy `org-element-context'? Date: Sat, 19 Apr 2014 10:47:38 +0200 Message-ID: <871twteltj.fsf@bzg.ath.cx> References: <874n2jsls9.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:43945) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbR81-0006X4-KY for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 05:00:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WbR7s-0003OO-JV for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 05:00:05 -0400 Received: from mail-we0-x22a.google.com ([2a00:1450:400c:c03::22a]:45393) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WbR7s-0003O6-CG for emacs-orgmode@gnu.org; Sat, 19 Apr 2014 04:59:56 -0400 Received: by mail-we0-f170.google.com with SMTP id w61so2273372wes.29 for ; Sat, 19 Apr 2014 01:59:55 -0700 (PDT) In-Reply-To: <874n2jsls9.fsf@gmail.com> (Nicolas Goaziou's message of "Thu, 27 Mar 2014 16:28:54 +0100") 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: Nicolas Goaziou Cc: Org Mode List Hi Nicolas, Nicolas Goaziou writes: > 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? I don't think `org-element-context' should be sloppy *at all*. `org-element-context' and `org-element-at-point' should both stick to the syntax as strictly defined -- that's where the value of your work lies, and we should never dirty that. IMHO the needed flexibility should be implemented at the level of what users may want to do with the string at point, even if this means to temporarily interpret this string in a different way than what the syntax would do. For example, on a comment, (eq 'comment (car (org-element-at-point))) should always return `t'. But if the user wants to open bracket links from comments (or in a property), then something like this would do: (defun org-open-links-in-comment-and-properties () "Open links in a comment or in a property." (interactive) (let ((string-ahead (and (looking-at ".+") (match-string 0))) (value (org-element-property :value (org-element-at-point)))) (with-temp-buffer (org-mode) (insert value) (goto-char (point-min)) (search-forward string-ahead) (org-open-at-point)))) which do work right now. Of course this could be generalized, provided the property to consider is always named ":value", which is not the case IIUC: sometimes it's :raw-data, right? My point is that sloppiness at the syntax level would break the separation of concerns. If we try to apply the MVC scheme to an org-mode file: the syntax would give us the model of a file, the buffer properties give us the view of the file, and functions to render the model or to act on the buffer are the controllers. Flexibility should not be in the model, but in the controllers. Those distinctions were blurred away before your parser because Org files are just text... and because we assumed the view (from the text properties) gave us something like a "syntax". Last but not least: the spirit of the solution shown above does not prevent amending the syntax if we *really* need to amend it, but that's where I'd be as conservative as possible -- that is, as *you* :) Hope this all makes sense -- let me know what you think. -- Bastien