From: Ignacio Casso <ignaciocasso@hotmail.com>
To: Ihor Radchenko <yantar92@gmail.com>
Cc: emacs-orgmode@gnu.org
Subject: Re: [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)]
Date: Sun, 24 Apr 2022 11:45:00 +0200 [thread overview]
Message-ID: <PAXPR06MB77609467579F3DD6D11225EBC6F99@PAXPR06MB7760.eurprd06.prod.outlook.com> (raw)
In-Reply-To: <87y1zvlyj0.fsf@localhost>
Ihor Radchenko <yantar92@gmail.com> writes:
> Ignacio Casso <ignaciocasso@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.fsf@nicolasgoaziou.fr
Actually, I have investigated a little bit and I think the issue is more simple
than that:
- Link abbreviations rely in the variables `org-link-abbrev-alist' for
global abbreviations and `org-link-abbrev-alist-local' for
abbreviations defined with #+LINK for a single org file.
- `org-open-at-point-global' opens links with
`org-link-open-from-string' as opposed to `org-open-at-point', which
uses `org-link-open'.
- `org-link-open-from-string' ends up using `org-link-open' too, but
inside a `with-temp-buffer' form:
(defun org-link-open-from-string (s &optional arg)
...
(pcase (with-temp-buffer
(let ((org-inhibit-startup nil))
(insert s)
(org-mode)
(goto-char (point-min))
(org-element-link-parser)))
(`nil (user-error "No valid link in %S" s))
(link (org-link-open link arg))))
- But in a temporal buffer, `org-link-abbrev-alist-local' is nil, and
thus all abbreviations defined with #+LINK are lost.
So a simple solution to this would be preserving the value of
`org-link-abbrev-alist-local' when switching to the temporal buffer. I
think this is orthogonal to the issue of the parser, and it's a bug on
its own, since as a user I would expect that evaluating
`org-link-open-from-string' would use my current buffer's local values
of variables.
What do you think? If you agree, I can send a patch fixing it in two
lines with something like this:
(let ((org-link-abbrev-alist
(append org-link-abbrev-alist org-link-abbrev-alist-local)))
(pcase (with-temp-buffer ...) ...))
or this:
(let ((tmp-var (org-link-abbrev-alist-local)))
(pcase (with-temp-buffer
(setq org-link-abbrev-alist-local tmp-var)
...) ...))
P.S. There is another variable defined with `defvar-local' in ol.el:
`org-target-link-regexp'. I don't know what it is used for but it could
potentially suffer from the same problem.
next prev parent reply other threads:[~2022-04-24 10:27 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-23 9:53 [BUG] link abbreviations do not work inside property drawers [9.5.2 (release_9.5.2-38-g682ccd @ /home/ignacio/repos/emacs/lisp/org/)] Ignacio Casso
2022-04-24 7:40 ` Ihor Radchenko
2022-04-24 9:45 ` Ignacio Casso [this message]
2022-04-26 8:49 ` Ihor Radchenko
2022-04-26 9:07 ` Ignacio Casso
2022-04-26 13:52 ` Ihor Radchenko
2022-04-26 14:46 ` Ignacio Casso
2022-04-27 4:25 ` Ihor Radchenko
2022-04-27 6:46 ` Ignacio Casso
2022-04-27 9:18 ` tony aldon
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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=PAXPR06MB77609467579F3DD6D11225EBC6F99@PAXPR06MB7760.eurprd06.prod.outlook.com \
--to=ignaciocasso@hotmail.com \
--cc=emacs-orgmode@gnu.org \
--cc=yantar92@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
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).