On 20/09/2022 18:54, Ihor Radchenko wrote:
Max Nikulin writes:
Currently I believe that instead of injecting up to 6 entries into
`org-file-apps' for various combinations of page, anchor, and search
pattern, it is better to add single record with function handler. Notice
that the approach presented above is not affected by the bug with
multiple regexp group. Its additional advantage is that shell is not
involved, so peculiar file names can not cause execution of some code
when quoting and escaping are messed up.
I think a set of functions for popular PDF viewers (evince, zathura,
okular, xpdf, xpopple, firefox, chromium & Co., etc.) should be defined
in some package, but I am in doubts if it suitable for Org core.
Proof of concept implementation.
Thanks for taking time to implement this proof of concept!
I have realized that it misses customization of application binary
(exact name or full path to non-standard location).
I think that it is a very good idea for Org core to support search terms
in file links that are handled by Free Software.
Maybe I misunderstand something, but your stress on Free Software here
surprised me. I did not mention explicitly any proprietary application
such as Adobe Reader. On the other hand support of Chromium (that is
free) unavoidably assumes Google Chrome and likely MS Edge with other
derived products with same customization as chromium vs.
chromium-browser command name discrepancy in Linux distros.
Moreover, I think that we should, by default, auto-detect and use Free
Software to open file links, when such software is installed on user
machine (unless the user explicitly instruct otherwise).
Could you, please, elaborate? E.g. for PDF file default is docview mode.
Unless a user has an override in `org-file-apps', likely it should be
used. Perhaps system-wide handler may be considered as a candidate, but
on linux it means XDG MIME handlers that is not supported by Emacs, so
only mailcap remains. Both XDG database and mailcap have no notion of
location within the file to open.
I see Free Software support as dedicated files like ol-evince,
ol-okular, etc. The file functionality and common function may probably
be factored out into ol-file library.
I am considering a single package, something like org-pdfviewer, that
has definitions for all popular viewers: evince, okular, firefox,
chromium, etc. I believed that user should explicitly configure
preferred viewer by either adding an entry with supplied function to
`org-file-apps' or this package has its own defcustoms and the entry
injected to some variable as you suggested in
Ihor Radchenko. Re: [PATCH v2] org.el: Fix percent substitutions in
`org-open-file' Mon, 05 Sep 2022 13:46:41 +0800.
https://list.orgmode.org/875yi2xtj2.fsf@localhost
The point of defcustoms in the package instead of (or in addition to)
`org-file-apps' is that evince and okular support more formats than PDF.
