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

[Eli Zaretskii]

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

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

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

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

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