From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#75052: 31; browse-url-transform-alist is not used by secondary browser Date: Fri, 3 Jan 2025 20:55:56 -0600 Message-ID: References: <87cyhi6y3p.fsf@daniel-mendler.de> <87zfkl28vf.fsf@daniel-mendler.de> <87frlz3kvs.fsf@daniel-mendler.de> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30297"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 75052@debbugs.gnu.org To: Daniel Mendler Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jan 04 03:57:28 2025 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 1tTuLu-0007hk-Uz for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 04 Jan 2025 03:57:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tTuLa-0002FR-L1; Fri, 03 Jan 2025 21:57:06 -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 1tTuLY-0002En-58 for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 21:57:04 -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 1tTuLX-0007LR-Lr for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 21:57:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:MIME-Version:References:In-Reply-To:From:To:Subject; bh=wzo8/Os5b7v1N/NucQrEnPoC0fEemcAdHeI11/7OD3U=; b=AX7+zGPXyNF/dQK4a2kGF5IsiWBFD0ThOS4XmqyQ/ztB2q153Qy/MJlvyKWpXPBCJGDJjQEl67Z+TtKQftDyp+Ifp6zbbTHZe+lMsqmbFWA2hAEBbMLM9oD8Sy8n9aUW4ESsX1OGYZs/JEKVpKgV2Mp4F5sTakZfHRtEqkDJAbqQRyzY7bLY8Q4NrnQFIInTcx8csurlrizuOd9gs7D33RneDiNhCVKItJsDZ4dVOZe0G5s/JJ6LUK0NaQWLPfoS9kVdWiH8BgC1jB1Gou+ujcmTBeb+nU+sBf6IRIrzIGo4cENA3MGYmI/jCQ6YqVQgVI3DO+IDFvg9PlOCiHfQgQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tTuLW-0003k5-Fd for bug-gnu-emacs@gnu.org; Fri, 03 Jan 2025 21:57:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 04 Jan 2025 02:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 75052 X-GNU-PR-Package: emacs Original-Received: via spool by 75052-submit@debbugs.gnu.org id=B75052.173595936314276 (code B ref 75052); Sat, 04 Jan 2025 02:57:02 +0000 Original-Received: (at 75052) by debbugs.gnu.org; 4 Jan 2025 02:56:03 +0000 Original-Received: from localhost ([127.0.0.1]:52851 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tTuKY-0003iC-Io for submit@debbugs.gnu.org; Fri, 03 Jan 2025 21:56:03 -0500 Original-Received: from mail-ed1-x530.google.com ([2a00:1450:4864:20::530]:59752) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1tTuKU-0003hk-Jf for 75052@debbugs.gnu.org; Fri, 03 Jan 2025 21:56:01 -0500 Original-Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-5d3e8f64d5dso22711398a12.3 for <75052@debbugs.gnu.org>; Fri, 03 Jan 2025 18:55:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1735959357; x=1736564157; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=wzo8/Os5b7v1N/NucQrEnPoC0fEemcAdHeI11/7OD3U=; b=QFpgtv+/SB6vnFyhfuGfUPwRKQIqQ1A3NCuDifAdqcuDRuLJv9AD8/Hbp/F4JfXLRr HxGy8PsTjPw0urKer72KaqJ9dFH1uTJBUF9eyoalfpiRfXYxa0nb9/Jj7KY8U/PezI5k G43SPkz8btu1PrBLrRV9vbjZ4HRN1La0qJdIHZN3JOsYTgRok60D0Exa+TwErMmX+sXW dyUzTP9aAUyFfu6Vs7T0PVNMMY5pKgF41qFxDHVHQv43jTwEwZOa+jws79rpN2oyCsRm /YGP8X7qoYaEvp/MyJhR4XkItFjEyrBFQnjhNn0eqHo9T5T2B8UaInpjeaFoQOquURRS 1Hug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1735959357; x=1736564157; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wzo8/Os5b7v1N/NucQrEnPoC0fEemcAdHeI11/7OD3U=; b=kpdo5m3ZWmkLSPvHHXmM4RYugsG68b5DfQhWBLs6IEkxPBZcFWTHXhBclVZTrR7WIB go4MMFRnPhn12ZHCwIEl7+Y1/TP6zILTnC2q2Tvzp0IieEzBx/aN47PPPVJYYs8yfHXo waARllkJzO2bzSZljB3mhZc2trtWqXhbn4M7ja8Z0il9yEG5OT8Uv2F2BKid4nR1+G1z 7k4pOCZgAD+ulpn0hmLs+IGLalA4UxCSBjC/gabMJH4R0/Kq+pyHRbqaxfMVWAa3pwE4 8ihng4FLQNALC6LVywYV8vPu4Ex0R6agj5uON11ciKbSggwz+QWFDZDC8e7cs1saQspz NWKA== X-Gm-Message-State: AOJu0YyRxK9HtoYKhDKxQ1yrZm/65XmRnH0Uhu47vTjN7buNiumXjgQX 5PCRw03Q5wqejFzG0LnUKIztXxSgwZPjeTiyCmUpoL91Db53y8a/9li4YlCr71Ni+NpmGfTfUll GWjaxUp2tv1PTGSpvYoO9PPY6AeXwSMaA X-Gm-Gg: ASbGnctAhoAxbJNWfgFr2TDpjGReo6EfRBJqyMUEu+zUSLEQAKDM14Mp8cVt2jPKUaH TJ1tOSS9WVhKmVHHX5PKkHT1AkzfKVq2sY9cQAFPy X-Google-Smtp-Source: AGHT+IGhNLUYOv16xYDkWQ56gOF++7ESjWU/oVKHK4uPSakyqFw8mXpc/G2NoxK2I5Slw5i2w0t2ermMlzi34CRJGJo= X-Received: by 2002:a05:6402:35d6:b0:5d0:f9f1:cd73 with SMTP id 4fb4d7f45d1cf-5d81ddf3befmr48084754a12.13.1735959356956; Fri, 03 Jan 2025 18:55:56 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 3 Jan 2025 20:55:56 -0600 In-Reply-To: <87frlz3kvs.fsf@daniel-mendler.de> 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:298320 Archived-At: Daniel Mendler writes: > Stefan Kangas writes: > >> Thanks for identifying this issue, and for the patch! >> Sorry for the delay in reviewing it. > > Thanks for taking a look. The problem goes a little bit further even. > `browse-url' contains some setup code (`setenv' etc), which is also > relevant when invoking secondary browser functions. OK, let's look into it. > Maybe it would be more clear if the function is renamed to > `browse-url-via`? Then the VIA argument could either be a function or a > flag. > > (browse-url-via some-function url) > (browse-url-via secondary url) That would be an improvement, I think. >> I believe that the API would be simpler if we had two functions instead: >> >> (browse-url-with-function func url &rest args) >> (browse-url-with-secondary-browser url &rest args) > > This would work too but would impose slightly more work on the callers, > since they would then decide if they want to call > `browse-url-with-secondary-browser' or `browse-url'. If code is read more often than it is written, this is an acceptable tradeoff. But see below. > Another perhaps simpler and significantly more minimal approach would be > to let-bind `browse-url-browser-function' to > `browse-url-secondary-browser-function' at all call-sites instead of > calling `browse-url-secondary-browser-function' directly. Inside the > let, `browse-url' would be called as usual. > > However the problem with that approach is that it wouldn't be entirely > backward compatible, since the `browse-url-handlers' take precedence > over the `browse-url-browser-function'. In order to circumvent this > problem we could introduce a new variable > `browse-url-override-browser-function' which would take precedence in > `browse-url'. `package-browse-url' would become the following: > > #+begin_src emacs-lisp > (defun package-browse-url (desc &optional secondary) > (interactive (list (package--query-desc) current-prefix-arg) > package-menu-mode) > (unless desc > (user-error "No package here")) > (let ((url (cdr (assoc :url (package-desc-extras desc)))) > (browse-url-override-browser-function > (and secondary browse-url-secondary-browser-function))) > (unless url > (user-error "No website for %s" (package-desc-name desc))) > (browse-url url))) > #+end_src > > However this small incompatibility may even be acceptable. In case URL > handlers are defined, you may want them to take precedence in any case. > > I believe the problem is only pronounced in > `browse-url-with-browser-kind' which under all circumstances wants to > use the browser function it has chosen. In order to achieve that it > could let-bind `browse-url-handlers' and `browse-url-default-handlers' > to nil. The function would become this: > > #+begin_src emacs-lisp > (defun browse-url-with-browser-kind (kind url &optional arg) > (interactive ...) > (let ((function (browse-url-select-handler url kind))) > (unless function > (setq function > (seq-find > (lambda (fun) > (eq kind (browse-url--browser-kind fun url))) > (list browse-url-browser-function > browse-url-secondary-browser-function > #'browse-url-default-browser > #'eww)))) > ;; Ensure that function is used > (let ((browse-url-browser-function function) > (browse-url-default-handlers nil) > (browse-url-handlers)) > (browse-url url arg)))) > #+end_src I quite like this idea, and I think it buys us some improvements even, as you detail above, while the compatibility issues are fixed with the new variable. This is the only idea so far that guarantees that the environment variables, etc., that we set now and in future in `browse-url`, are used also for the secondary browser. IIUC, it would also give us exactly one function that Lisp programs should normally call: `browse-url`. Could you perhaps send a patch?