Hello, Michael Brand <michael.ch.br...@gmail.com> writes:
> Only slowly I begin to get it partially. My observation is that if the > current `org-open-file' would be changed to > > (eval cmd > ;; LEXICAL argument. > `((file . ,(convert-standard-filename file)) > (link . ,dlink))) Actually, that should be (eval cmd t). Providing an alist is not necessary here. > to provide also the `link' symbol then a > > (add-to-list 'org-file-apps > (cons (concat org-player-file-extensions-regexp > "::\\([0-9]+:[0-9]+\\(:[0-9]+\\)?\\)") > '(org-player-play-file file (match-string 1 link)))) > > which is simple enough for me to understand in org-player.el works. > This situation looks favorable to me at least for a first step because > it would mean a version of org-player.el that remains compatible with > "any" Org before lexical binding in org.el > (release_8.3.3-426-g1f49e9f) but would also become compatible again > starting with one of the next commits in Org master. > > Do I understand correct that this would not break any backward > compatibility with all other existing and correct use of > `org-file-apps'? Although it does the job, it would leave an `eval' in the code base, which is not very pretty, and more difficult to maintain (scope is less obvious). That's why I prefer the functions. Of course, it may not be worth the trouble if introduced backward incompatibility is really nasty. Regards, -- Nicolas Goaziou
