[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Org mode links: Open a PDF file at a given page and highlight a give
From: |
Ihor Radchenko |
Subject: |
Re: Org mode links: Open a PDF file at a given page and highlight a given string |
Date: |
Wed, 21 Sep 2022 16:18:41 +0800 |
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