On 20/12/2025 14:22, Ihor Radchenko wrote:
Ihor Radchenko writes:
I do not like adding conditions inside `org-open-file'. It is already
excessively complex. On the other hand I can not figure out how to make
it more flexible without overwhelming configuration options.
Rather than overcomplicating things, we can:
1. Introduce some helper function/macro to do the right call depending
on the OS.
2. Use the macro in `org-open-file'
3. Hold on with adding configuration options. If users actually request
such feature, we can think further.
WDYT?
Max, any comment here?
I am sorry. I expect some tricky points, so it is hard to discuss
without some code. I believe, there should be a way to switch between
call-process, start-process, etc. It should be possible to add more
argument e.g. to specify page and/or search pattern for PDF.
I was going to review related threads I'm aware of and to try to find
discussions related to dired implementation. It is rather disappointing
to look at some code that is written for the same purpose, that has been
modified many times to fix corner cases, but that is not reusable.
Ideally users and developers who define new link types should be able to
just use the strategy default to the current OS. But since it appeared
to be fragile, users should be able to override default policy. I can
not figure out a source of resistance against using `browse-url' for URL
schemes with external handlers. People prefer to use some function to
start a process explicitly.
Sorry, I do not understand what you are referring to and what you want
to suggest in the context of this discussion.
There was enough threads where users pick some function (start-process,
call-process) almost randomly not expecting any complications, but that
cases may be handled by `browse-url' that tries to use sensible generic
handler depending on OS. Generic handler in `browse-url' is close to
what org-open-file should do in some cases.
