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