Ignacio Casso <ignacioca...@hotmail.com> writes: > 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: > ... > 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.
I am not sure if using current buffer in `org-link-open-from-string' is to be expected. This function is not tied to buffer, just to string. Imagine a situation when user function retrieves the link string from another buffer and then calls `org-link-org-from-string' in the context of current buffer. What you are proposing is going to change the current behaviour of `org-link-open-from-string' beyond the discussed problem. Instead of changing the default behaviour of `org-link-open-from-string', I would introduce an optional parameter holding the desired context. The parameter can be set to an Org buffer. That buffer's context will be used. > 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. A clean solution would do something similar to org-export--generate-copy-script. Best, Ihor
