bug#74730: [PATCH] 30.0.92; eww-browse-with-external-browser and eww-follow-link should use browse-url-with-browser-kind

[Daniel Mendler]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Daniel Mendler <mail@daniel-mendler.de>
>> Cc: 74730@debbugs.gnu.org
>> Date: Sun, 08 Dec 2024 07:13:54 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > The doc string of browse-url-secondary-browser-function explicitly
>> > says not to set it to eww.  So users who do the above are acting
>> > against the design and the recommended usage, and I'm not sure we
>> > should support that at all, let alone with a (seemingly)
>> > backward-incompatible change such as the one you propose.
>> 
>> How can I then use an external browser as the default and Eww as
>> alternative? I argue that this is a legitimate use case - an external
>> browser as primary and Eww as secondary browser for distraction-free
>> reading.
>
> It is a legitimate use case, but please describe it in more detail:
> what do you mean by "using external browser as primary and eww as
> secondary"?  That is, which Emacs commands should behave like that?

In Emacs there are many commands which use `browse-url-browser-function'
or `browse-url-secondary-browser-function' depending on the prefix
argument. Many of the commands are generic and act on URLs or buttons at
point in different kinds of buffers. Also many external packages use
`browse-url'.

- `goto-address-at-point'
- `browse-url-button-open'
- `browse-url-button-open-url'
- `package-browse-url'
- `gnus-summary-browse-url'

When any of these commands on links is invoked, the
`browse-url-browser-function' is used by default. The primary browser is
configured by `browse-url-browser-function' while the secondary browser
is configured by `browse-url-secondary-browser-function'. Both use cases
are plausible: `browse-url-browser-function' can be external and
`browse-url-secondary-browser-function' can be internal and vice versa.

> E.g., is "use browse-url-with-browser-kind" a valid solution for the
> use case you describe?  If not, why not?

`browse-url-with-browser-kind' can be used when one explicitly wants to
call an external or internal browser. The command in Eww
`eww-browse-with-external-browser' has `*-external-*' as part of its
name, so in this case I think is a valid solution.

>> As I wrote, the only place which leads to problems is in
>> `eww-browse-with-external-browser' - I checked all other places in
>> Emacs.
>
> You haven't describe the results of your investigation in detail.  I
> see 6 callers of browse-url-secondary-browser-function, so please
> explain how this change is not a problem in each one of them.  Your
> original message said that "most commands use a prefix argument to
> switch to the secondary browser", but I don't understand how saying
> that allows you to conclude that this change will not cause trouble?

Each of the other call sites does not make assumptions about the
internal or external distinction. All that is important is that two
browser functions exist - a primary browser function and a secondary
function. By default the primary function is called, and if explicitly
requested by the user via a prefix argument, the secondary function is
used. It does not matter if the functions point to external or internal
browsers.

>> I argue that the behavior and implementation will be even more
>> explicit, since `browse-url-with-browser-kind' explicitly supports the
>> `external' kind. But you are right about the backward compatibility
>> problem, see below.
>> [...]
>> > What will happen as result of this change to users who customize
>> > browse-url-secondary-browser-function as its doc string says, and then
>> > invoke the command eww-browse-with-external-browser?
>> 
>> In this case the change will indeed be backward-incompatible, if
>> multiple external browsers are used and the secondary browser is
>> configured to a different one than the one which will be selected by
>> `browse-url-with-browser-kind'.
>> 
>> The patch can be extended however. I can change it such that the
>> `browse-url-secondary-browser-function' is checked first if it is indeed
>> external (via the `browser-kind' property). And only if it is not
>> external, `browse-url-with-browser-kind' will be used. One could be even
>> more strict and compare `browse-url-secondary-browser-function' to
>> `eww-browse-url' and only in this case fall back to
>> `browse-url-with-browser-kind'.
>
> If we can make it so that existing customizations of
> browse-url-secondary-browser-function will keep working as they did,
> then the backward incompatibility issue will disappear, and such a
> change becomes possible.  But in any case, the doc string of
> browse-url-secondary-browser-function should be amended if we are
> going to support its setting to eww.

Okay, I can do that.

> Also, are we sure all the relevant functions always have the
> 'browse-url-browser-kind property? what about user-defined functions,
> for example?

User-defined functions may not have the property. But we can be
conservative and preserve the existing behavior in the case where the
property is unavailable, treating the missing property like the value
`external'. Only if the property is found and `internal', the
`browse-url-with-browser-kind' will be used to make sure that an
external browser is used. As I mentioned, alternatively one can be even
more conservative and only use `browse-url-with-browser-kind' if
`browse-url-secondary-browser-function' is set to `eww-browse-url'. That
might be a little bit too restrictive, but it would be completely
backward compatible.

Daniel