emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Bastien <bzg@gnu.org>
To: Nicolas Goaziou <n.goaziou@gmail.com>
Cc: Org Mode List <emacs-orgmode@gnu.org>
Subject: Re: [RFC] Sloppy `org-element-context'?
Date: Sat, 19 Apr 2014 10:47:38 +0200	[thread overview]
Message-ID: <871twteltj.fsf@bzg.ath.cx> (raw)
In-Reply-To: <874n2jsls9.fsf@gmail.com> (Nicolas Goaziou's message of "Thu, 27 Mar 2014 16:28:54 +0100")

Hi Nicolas,

Nicolas Goaziou <n.goaziou@gmail.com> 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."
  (let ((string-ahead (and (looking-at ".+") (match-string 0)))
	(value (org-element-property :value (org-element-at-point))))
      (insert value)
      (goto-char (point-min))
      (search-forward string-ahead)

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.


  parent reply	other threads:[~2014-04-19  9:00 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-03-27 15:28 [RFC] Sloppy `org-element-context'? Nicolas Goaziou
2014-03-27 21:34 ` Rasmus
2014-03-28  9:26   ` Nicolas Goaziou
2014-04-19  8:47 ` Bastien [this message]
2014-04-19  9:15   ` Nicolas Richard
2014-04-19  9:30     ` Bastien
2014-04-23 20:35   ` Nicolas Goaziou
2014-04-29 21:20     ` Nicolas Goaziou
2014-05-06  9:25       ` Bastien
2014-05-26 15:50         ` Bastien

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871twteltj.fsf@bzg.ath.cx \
    --to=bzg@gnu.org \
    --cc=emacs-orgmode@gnu.org \
    --cc=n.goaziou@gmail.com \


* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).