Re: Org mode links: Open a PDF file at a given page and highlight a given string

[Max Nikulin <manikulin@gmail.com>]

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.