From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#74730: [PATCH] 30.0.92; eww-browse-with-external-browser and eww-follow-link should use browse-url-with-browser-kind Date: Sun, 08 Dec 2024 14:02:04 +0200 Message-ID: <86r06ifkn7.fsf@gnu.org> References: <87frmz40f2.fsf@daniel-mendler.de> <86ikruhg3q.fsf@gnu.org> <874j3ed487.fsf@daniel-mendler.de> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="28567"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 74730@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Dec 08 13:05:32 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1tKG2W-0007DQ-4e for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 08 Dec 2024 13:05:32 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tKG2D-0005RI-Kj; Sun, 08 Dec 2024 07:05:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKG23-0005OQ-Tm for bug-gnu-emacs@gnu.org; Sun, 08 Dec 2024 07:05:06 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tKG22-00047i-Ne for bug-gnu-emacs@gnu.org; Sun, 08 Dec 2024 07:05:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=References:In-Reply-To:From:Date:To:Subject; bh=RRhULYWYVHIcK2TEMVpyhw+SBjT2EXNv9bVQW+ott5A=; b=S8XrpMPGmHMxMyFgyLQnkP5XCj81o27Xg8I68xOShdKy05XVRMT8ZCocwGHQ4MBxOh3rJdVki58cJfylMgYlZ9p5jhc50m2LywsK1z+QDklWTgX165LOyyeh7rkZYdOtnLYGr73UG05V+B7UzzH1rJ40g0BtBpVuP7p9lvRp1ikzfM140/JOU6bIVuZsdbsW8tfGSOD8XTB8aEMWlbnlUodSF9Kyg69hVeQv1hNyeBNIOTpYk3mrzK7xB9XuKiPq/FC4CM4Nuj9TMRbJbPQb2hZUmhj2GIVpcpZ0Btfx17M/juew1qQ9cPTXqdxbaYhCOcg8F6uw/kGZPWg8yaURuQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tKG22-0005Ph-I3 for bug-gnu-emacs@gnu.org; Sun, 08 Dec 2024 07:05:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Dec 2024 12:05:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74730 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74730-submit@debbugs.gnu.org id=B74730.173365947320753 (code B ref 74730); Sun, 08 Dec 2024 12:05:02 +0000 Original-Received: (at 74730) by debbugs.gnu.org; 8 Dec 2024 12:04:33 +0000 Original-Received: from localhost ([127.0.0.1]:49897 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKG1Y-0005Oe-Ra for submit@debbugs.gnu.org; Sun, 08 Dec 2024 07:04:33 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tKG1W-0005OP-Vo for 74730@debbugs.gnu.org; Sun, 08 Dec 2024 07:04:31 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tKFzJ-0003Ft-BO; Sun, 08 Dec 2024 07:02:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=RRhULYWYVHIcK2TEMVpyhw+SBjT2EXNv9bVQW+ott5A=; b=hGrr77RtHENh rHGdEMQ9Acr1ijqWhn7hOApTbwbwGoPtgaqi1zpB4dtNgE6qU3MkYPHV9O5gWV7uyM3HdBeFp6vtR yC+PkSvkAYnjdo6ykriO8El9SCHVppFJI7FaDWKtpMPnPvbP4p55imlu4QJoyBtOpN9+LxBNlHIRB gbXmM8zyHXlGN1Yn7hkhdlvXp4IrlsU+y0wgmkT1HI9uGEKUiOHrrAbnBLs5+lcH9JgtMrLCMSk83 kUWvJPRFT22egPp10SLS9EwY5hkS/N3P06w7tG+200Gbab/Eo4PV9lEUD+08RXh9BbeXa2+Lvti6r 4OnwWhIjNP6n8OGi/FrM6w==; In-Reply-To: <874j3ed487.fsf@daniel-mendler.de> (message from Daniel Mendler on Sun, 08 Dec 2024 08:27:20 +0100) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:296632 Archived-At: > From: Daniel Mendler > 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.