Ignacio Casso <ignacioca...@hotmail.com> writes:
> Link abbreviations do not work inside property drawers and are instead
> confused with internal links. The following org file illustrates this
> behavior.
This is to be expected. org-open-at-point does the following:
;; No valid link at point. For convenience, look if something
;; looks like a link under point in some specific places.
((memq type '(comment comment-block node-property keyword))
(call-interactively #'org-open-at-point-global))
That is, links are only partially recognised inside comments, node
properties, and keywords.
> I know that there is discussion of whether timestamps and links should
> work or not inside property drawers, but since they currently work, I
> think link abbreviations should be supported too. Let me know if you
> agree and I'll debug the issue and send a patch with a fix proposal.
I do not think that it is an easy problem to solve properly.
In the discussion you referenced [1] Nicolas raised the problem that we
cannot modify org-element parser to support links in more contexts as it
may create various issues (e.g. in exporter).
Without modifying the parser, supporting abbreviations will require code
duplication or referring to internal org-element functions - a fragile
approach.
I am currently tinkering with an idea to implement several parser
contexts, similar to optional argument in org-at-timestamp-p.
Basically, org-element parser could allow using multiple
named org-element-object-restrictions: 'agenda, 'export, 'lax, etc.
This is not ideal, as Org syntax will be more complex. However, multiple
interpretations of Org syntax are already implemented de facto (e.g.
org-at-timestamp-p). So, centralising the parsing into org-element could
be beneficial.
Probably, the contexts might be defined by let-bound
org-element-parser-context value.
Best,
Ihor
[1] https://orgmode.org/list/877d8llha9....@nicolasgoaziou.fr
