From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Goaziou Subject: Re: [RFC] Sloppy `org-element-context'? Date: Wed, 23 Apr 2014 22:35:32 +0200 Message-ID: <87tx9jlr6z.fsf@gmail.com> References: <874n2jsls9.fsf@gmail.com> <871twteltj.fsf@bzg.ath.cx> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48416) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Wd3su-0000Fk-H6 for emacs-orgmode@gnu.org; Wed, 23 Apr 2014 16:35:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Wd3sm-0003DY-3s for emacs-orgmode@gnu.org; Wed, 23 Apr 2014 16:35:12 -0400 In-Reply-To: <871twteltj.fsf@bzg.ath.cx> (Bastien's message of "Sat, 19 Apr 2014 10:47:38 +0200") 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: Bastien Cc: Org Mode List Hello, Bastien writes: > I don't think `org-element-context' should be sloppy *at all*. [...] > For example, on a comment, (eq 'comment (car (org-element-at-point))) *coughs* (eq 'comment (org-element-type (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))) (buffer-substring (point) (line-end-position)) > (value (org-element-property :value (org-element-at-point)))) > (with-temp-buffer > (org-mode) (let ((org-inhibit-startup t)) (org-mode)) > (insert value) > (goto-char (point-min)) > (search-forward string-ahead) > (org-open-at-point)))) > > which do work right now. Indeed. > 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? No, :raw-value are different and shouldn't get in the way in this case. > 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* :) Indeed. > Hope this all makes sense -- let me know what you think. I agree. We can ignore the patch. Regards, -- Nicolas Goaziou