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

[Ihor Radchenko <yantar92@gmail.com>]

Max Nikulin <manikulin@gmail.com> writes:

>> 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.

I was referring to GPL-compatible software.
If we have better integration with Libre/Free Software, it is suitable
for Org core. IMHO.

>> 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 am referring to cdr of the org-file-apps entries.
docview will correspond to `emacs' command. XDG will correspond to
`system'. And we have `default', which could detect Libre Software, if
installed.

>> 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.

I understand your idea. What I am suggesting is to implement support for
a subset of popular viewers (the Libre ones) and add it to Org core.
Support for non-Libre viewers could be added ad third-party packages
based on the Org core implementation.

The default viewer may be customized by user according to, say,
org-file-apps-default-pdf-viewer defaulting to 'auto (detect).
This customization will only take effect when the PDF file entry in
org-file-apps sets the command to `default'.

Hope I made my idea more clear.

-- 
Ihor Radchenko,
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