Max Nikulin <maniku...@gmail.com> writes: >> What about passing an extra argument to :export function in >> `org-export-custom-protocol-maybe': >> >> (funcall protocol path desc backend info *link-object*) > > It would require another iteration with `condition-case' to deal with > functions having old signature.
Is it a problem? We can alternatively check function arity. > Earlier you considered :filter property that receives link object > instead of path and desc pair. I am unsure concerning name, but I like > that idea. I feel that :filter + :export will be rather redundant - they will do the same thing and only differ by calling convention. And we will have issues with priority of :filter vs. :export if both happen to be present (e.g. when a user defines a custom :export in personal config). I guess we may instead make :filter apply earlier, right after `org-export-filter-parse-tree-functions'. Then, it will be called before export transcoding process begins. >> Then, if the :export function returns non-string, the return value is >> further processed as (org-export-data *return-value* info). > > Do you mean something like the following? > > (defun org-man-export (link description backend) > "Export a man page LINK with DESCRIPTION. > BACKEND is the current export backend." > (org-element-create-link > (format "http://man.he.net/?topic=%s§ion=all"; link) > description)) > > where org-element-create-link parses link target into :type, :raw-link, > etc. properties. Yes. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at <https://orgmode.org/>. Support Org development at <https://liberapay.com/org-mode>, or support my work at <https://liberapay.com/yantar92>
