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 08:27:20 +0100
> 
> > 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.

Except that anything that calls them in eww must make some
assumptions, because it could otherwise cause infinite recursion.

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

Looking forward to seeing an updated patch which preserves the current
behavior wrt browse-url-secondary-browser-function's customization.

Thanks.