Make the default open program configurable.

[KorigamiK]

Right now, we hardcode the evince program to open the pdf files. This however doesn't provide enough configurability for the user. And might not work on other operating systems.

ripgrep-all/src/bin/rga-fzf-open.rs

Line 14 in 2ccf3ee

if fname.ends_with(".pdf") {

I propose a configuration parameter we create for opening the different mime types.
Even using something like a platform dependent file opener like xdg-open on linux or open on macos would be better.

[lafrenierejm]

To provide some relevant context:

• phiresky explained the rationale for why evince was hardcoded to begin with in Unable to open a searched file on macOS #240 (comment).
• check OS to use appropriate program to open files in rga-fzf #260 added support for macOS via open.
• Add Windows support to rga-fzf-open #265 left evince as the default but pulled in open as a fallback for any situation where evince isn't on PATH.

[phiresky]

we could make it extensively configurable, but I think it would be difficult to define the interface - how do we match file types? what if there's multiple choices? how does this configuration relate to the adapters configuration? what about (virtual) files in archives? should they be copied out to a temporary file? etc.

Alternatively we could make only one command configurable that's then used for everything, and maybe set a bunch of environment variables containing details of the search.

it's difficult to define where we want flexibility and where we don't for the whole rga-fzf thing. Really in that binary there could be tons of configurable args, but then it would just be fzf in the end and you can just write your own fzf command...

[KorigamiK]

So, let me propose a structure for defining the configuration options specifically for the case of pdfs. The way extensions like TexLab handle their build commands is as follows:

https://github.com/latex-lsp/texlab/wiki/Configuration

If some programs support the use of synctext we are able to use the backward and reverse search capabilities to move the cursor to specific parts of the pdf

This is how an implementation in the zed texlab extension looks like.

https://github.com/rzukic/zed-latex/blob/a7d3849eb954fa7628a387ee43fab98031851a8e/src/texlab_workspace_config/preview_presets.rs#L48-L121

Defining a similar json schema won't be too hard at least for pdf files eliminating the use of a separate rga-fzf-open binary to be shipped.

Please let me know your thoughts as I would like to begin working on this

[t-pohl]

Is there any update on this @KorigamiK ? I would also be pretty interested in the ability to configure the pdf viewer.

[PeonyThePeon]

The basic problem of file association is hardly new. It would be a mistake for rga to reinvent the wheel here.

A sensible approach would be for rga to:

1. Check a list of common per-user locations¹ for the OS's file association settings. Start with per-user locations (e.g. ~/.config/mimeapps.list, ~/.local/share/applications/mimeapps.list, etc.)
2. If no matching entry found, for the present filetype, check common per-user locations for mailcap files (e.g. ~/.mailcap, ~/.config/mailcap, etc.)
3. If no matching entry found, look for system-wide OS file association settings (e.g. /usr/share/applications/mimeapps.list, etc.)
4. If no matching entry found, look for system-wide mailcap file association settings (e.g. /etc/mailcap, etc.)
5. If no matching entry found, fall back onto default command for the relevant OS (e.g. xdg-open or open)

Footnotes

1. Some research will be needed to come up with a comprehensive, cross-platform list of file names/locations to search. See, e.g.:
   - https://manpages.ubuntu.com/manpages/trusty/en/man5/mailcap.order.5.html and
   - https://en.wikipedia.org/wiki/File_association ↩