Hi Nicolas and Paul On Sun, Jan 31, 2016 at 12:30 AM, Nicolas Goaziou <m...@nicolasgoaziou.fr> wrote:
> 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. I see the pros and cons of either solution with a slight bias to not break backward compatibility and am OK with what you and others decide. (Corrigenda: In my code examples earlier in this thread I should have used `link' instead of `dlink' which is ~(downcase link)~.) Michael
