emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [O] [RFC] Sloppy `org-element-context'?


From: Bastien
Subject: Re: [O] [RFC] Sloppy `org-element-context'?
Date: Sat, 19 Apr 2014 10:47:38 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.4.50 (gnu/linux)

Hi Nicolas,

Nicolas Goaziou <address@hidden> 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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]