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#56514: 29.0.50; Improve ERC's URI scheme integration for irc:// links Date: Tue, 8 Nov 2022 07:16:02 -0800 Message-ID: References: <87pmiabvd5.fsf@neverwas.me> <87edyqzeag.fsf@gnus.org> <874jzl2hsv.fsf@neverwas.me> <874jzkuqk3.fsf@neverwas.me> <87pmdxlera.fsf@neverwas.me> 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="35104"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Lars Ingebrigtsen , emacs-erc@gnu.org To: "J.P." , 56514@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 08 16:17:30 2022 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 1osQLy-0008q5-AN for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 08 Nov 2022 16:17:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1osQLf-0003xo-UH; Tue, 08 Nov 2022 10:17:12 -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 1osQLW-0003vQ-QF for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2022 10:17:05 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1osQLW-0007SX-6V for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2022 10:17:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1osQLV-0003Qp-Vd for bug-gnu-emacs@gnu.org; Tue, 08 Nov 2022 10:17:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 08 Nov 2022 15:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56514 X-GNU-PR-Package: emacs Original-Received: via spool by 56514-submit@debbugs.gnu.org id=B56514.166792057113129 (code B ref 56514); Tue, 08 Nov 2022 15:17:01 +0000 Original-Received: (at 56514) by debbugs.gnu.org; 8 Nov 2022 15:16:11 +0000 Original-Received: from localhost ([127.0.0.1]:37993 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osQKg-0003Ph-LN for submit@debbugs.gnu.org; Tue, 08 Nov 2022 10:16:11 -0500 Original-Received: from mail-oi1-f178.google.com ([209.85.167.178]:37673) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1osQKe-0003PM-Of for 56514@debbugs.gnu.org; Tue, 08 Nov 2022 10:16:09 -0500 Original-Received: by mail-oi1-f178.google.com with SMTP id b124so15817715oia.4 for <56514@debbugs.gnu.org>; Tue, 08 Nov 2022 07:16:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=Oby1lnM9tXGh1CCNc/RDTuU7/5WCTQNAN2TgVsp5c94=; b=OONeeWWHG1M4j5PdaALav8XU8Xnyt/SNEGk5K1q2xA7JXxcYEZmhR293Q4lhEXLB+D fjqwVhPm1xhX84SAUqgOoQqW0/dWZMfyjzNWM6V8ZfvYfpcToUmsQJ55egML95XKF+mZ VhkHUY065gss/urXwnF7ZCuoO9lEWxP/zocwdrVnraHWgFK7XjMODW25MPT4wqLCM+pB MDTzGM3rubvPPXcbY7H5mzNjhCaOARRHpltQwaJj8klaNQBdCdfSIAvtG6AAsZG9iYD8 LvAhRflRXO7QYBegE6En818gXbcDXbXTrgSTGHkgz6nGMY0BCU+FvmS8dkbe8k5PoADY hK/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; 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=Oby1lnM9tXGh1CCNc/RDTuU7/5WCTQNAN2TgVsp5c94=; b=Jvm2Gssft0XG9C0A7u49gzdbNAp3JaPukr/x6u0SQypy3KqyEBAQu3PNXDasvMJQue StNuAigRpdoK+bLfNDRFaA8VPf2qdafWgNrDY8wcf5ZE84NoMPMdMHqBtYGl4h3wD24x h5t0fbWi0dw6hfaTwl3rilIUuiVmoIUZDRVOM/938JZTs4UKmfmA4pNB/Brx0LAXymOn 9yGBkYRuVVfOMtlfwMqjyQ4JUu0tmNSBiTkQA8xepW1ki5huuNoyutq+BGbs6+9EcOvE pX5hL7YKKxIc67IuBGrRm46aV2nSxtfYQRpxaQ3OzZXtc8gBusRgmWDT0KrTOGb+sRtC omtQ== X-Gm-Message-State: ACrzQf3jE6FcZtGjKvsWEohYDQ1SgU9UPTyTnL5Fz2luzwBHfAEdQi/2 C5bK9+/INYLv7Ih+ipf3I7L/wymb/2Vb4MaQnZY= X-Google-Smtp-Source: AMsMyM713+x4CC1aLThRRTUL1DlSZmBk7S2aoST9tYu6BYOFCYUcygyMND92dQwXcE5KSkBS/sVoEuKCrrFuF3Rt4mU= X-Received: by 2002:a05:6808:1186:b0:353:b77a:a481 with SMTP id j6-20020a056808118600b00353b77aa481mr39126718oil.199.1667920563100; Tue, 08 Nov 2022 07:16:03 -0800 (PST) Original-Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Tue, 8 Nov 2022 07:16:02 -0800 In-Reply-To: <87pmdxlera.fsf@neverwas.me> X-Hashcash: 1:20:221108:jp@neverwas.me::j8Y2hz2OuX/Wwzk5:kXF 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:247340 Archived-At: "J.P." writes: > Questions (for anyone): > > 1. I added a couple autoloads in lisp/url/url-irc.el to avoid having > to create a url-ircs.el (or even a url-irc6{,s}.el). Is there a > better alternate means of getting `url-scheme-get-property' to > discover handlers that doesn't rely on autoloads? I'm hoping someone else will weigh in about this. > 2. In the function `url-irc', I bind `url-current-object' around the > call to `url-irc-function' to avoid adding another parameter to the > latter's interface (which mainly benefits ERC). Any obvious problem > with borrowing `url-current-object' for this purpose? No real opinion here. It feels slightly cleaner to add it as a proper argument, if we expect that other IRC clients than ERC would be interested in its value. > 3. In browse-url, I basically ignore what looks like the favored > practice for adding handlers, namely, registering an internal > function with `browse-url-default-handlers' that calls a public > function assigned to a user option. An example of this pattern is: > > internal: browse-url--mailto > option: browse-url-mailto-function > public: browse-url-mail > > The reason for sidestepping the intervening indirection and adding > a public function directly to `browse-url-default-handlers' is that > I figure users wishing to override this can already do so via > `browse-url-handlers'. Is that misguided somehow? You do have a point, but I think it's better to have the user option for consistency, and for ease of customization. Customizing an alist with customize is always going to be harder than customizing a single-value user option. > 4. Are any of these non-ERC changes newsworthy enough for etc/NEWS? I think teaching browse-url to recognize irc URLs is NEWS-worthy. I also added some notes inline below: > From 0d191d30b15ea2d5b6042f51c6cf421b82feb7e5 Mon Sep 17 00:00:00 2001 > From: "F. Jason Park" > Date: Wed, 13 Jul 2022 01:54:19 -0700 > Subject: [PATCH 1/6] Teach thing-at-point to recognize bracketed IPv6 URLs I suggest pushing this patch so that we're sure to have it in Emacs 29. I don't think it's NEWS-worthy, as it's more of a bug fix. > From 6fd2f75707f123abfbcfae2d4f2837efed5b7adc Mon Sep 17 00:00:00 2001 > From: "F. Jason Park" > Date: Mon, 11 Jul 2022 05:14:57 -0700 > Subject: [PATCH 2/6] Accommodate ircs:// URLs in url-irc and browse-url [...] > +;;;; ircs:// > + > +;; The function `url-scheme-get-property' tries and fails to load the > +;; nonexistent url-ircs.el but falls back to using the following: > + > +;;;###autoload > +(defconst url-ircs-default-port 6697 "Default port for IRCS connections.") > + > +;;;###autoload > +(defalias 'url-ircs 'url-irc) This change (support for ircs) should probably be in NEWS. What about `irc6' and `irc6s'? Should they have aliases? > From a9b47f5a6079fb3030c9e1514b4cbbda86dafff8 Mon Sep 17 00:00:00 2001 > From: "F. Jason Park" > Date: Mon, 11 Jul 2022 05:14:57 -0700 > Subject: [PATCH 4/6] Default to TLS port when calling erc-tls from lisp > > * lisp/erc/erc.el (erc-legacy-port-names, erc-normalize-port): Add > standard IANA port-name mappings for 6667 and 6697, as well as an > option to opt in for saner but nonstandard behavior. > (erc-open): Add note to doc string explaining that params `connect' > and `channel' are mutually exclusive. > (erc-tls): Call `erc-compute-port' with override. > (erc-compute-port): Call `erc-normalize-port' with result'. > > * test/lisp/erc/erc-tests.el (erc-tls): Add simplistic test focusing > on default parameters. This belongs in NEWS. > @@ -1550,8 +1564,16 @@ erc-normalize-port > (cond > ((> port-nr 0) > port-nr) > - ((string-equal port "irc") > - 194) > + ((string-equal port "ircu") 6667) > + ((string-equal port "ircs-u") 6697) > + ((member port '("irc" "ircs")) > + (when (eq erc-legacy-port-names 'legacy) > + (lwarn 'ERC 'warning > + (concat "`erc-legacy-port-names' will default to nil " > + "in a future version of ERC."))) Warning about the default seems unfortunate. Then every user will be warned until they customize this. I think we should either disable the warning, or flip the default to nil. > From 3658e89614cbe3b5b27f09271b7bc738a1c7ec38 Mon Sep 17 00:00:00 2001 > From: "F. Jason Park" > Date: Mon, 11 Jul 2022 05:14:57 -0700 > Subject: [PATCH 6/6] Improve new connections in erc-handle-irc-url [...] > @@ -990,6 +992,43 @@ Sample Configuration > ;; (setq erc-kill-server-buffer-on-quit t) > @end lisp > > +@node Integrations > +@section Integrations > +@cindex integrations > + > +@subheading URL > +For anything to work, you'll want to set @code{url-irc-function} to > +@code{url-irc-erc}. As a rule of thumb, libraries that rely directly > +on @code{url-retrieve} should be good to go out the box from Emacs > +29.1 onward. On older versions of Emacs, you may need to > +@code{(require 'erc)} beforehand. @pxref{Retrieving URLs,,, url, URL}. > + > +For other apps and libraries, such as those relying on the > +higher-level @code{browse-url}, you'll oftentimes be asked to specify > +a pattern, sometimes paired with a function that accepts a string URL > +as a first argument. For example, with EWW, you may need to tack > +something like @code{"\\|\\`irc6?s?:"} onto the end of > +@code{eww-use-browse-url}. But with @code{gnus-button-alist}, you'll > +need a function as well: > + > +@lisp > + '("\\birc6?s?://[][a-z0-9.,@@_:+%?&/#-]+" > + 0 t erc-browse-url-handler 0) > +@end lisp > + > +@defun erc-browse-url-handler url &rest args > +An autoloaded convenience function for use in options like those > +mentioned above. @var{url} must be a string. In Emacs 29 and above, > +the function @code{browse-url-irc} can be used instead. > +@end defun > + > +@noindent > +Keep in mind that when fiddling with these options, it may be easier > +(and more polite) to connect to a local server or a test network, like > +@samp{ircs://testnet.ergo.chat/#test}, since these generally don't > +require authentication. Why would that be more polite? It seems to me that, sure, if you're developing an IRC client I can see why you'd want to use a test network. But it seems like overkill just for user customization. > @@ -7184,25 +7184,98 @@ erc-get-parsed-vector-type > ;; Teach url.el how to open irc:// URLs with ERC. > ;; To activate, customize `url-irc-function' to `url-irc-erc'. > > -;; FIXME change user to nick, and use API to find server buffer > +(defcustom erc-url-connect-function nil > + "When non-nil, a function used to connect to an IRC URL. > +Called with any number of keyword arguments recognized by `erc' > +and `erc-tls'. The variable `url-current-object', if non-nil, > +can be used to help determine whether to connect using TLS." > + :group 'erc > + :package-version '(ERC . "5.4.1") ; FIXME increment on release > + :type '(choice (const nil) function)) > + > +(defun erc--url-default-connect-function (&rest plist) > + (let* ((scheme (and url-current-object (url-type url-current-object))) > + (ircsp (if scheme > + (string-suffix-p "s" scheme) > + (or (eql 6697 (plist-get plist :port)) > + (yes-or-no-p "Connect using TLS? ")))) > + (erc-server (plist-get plist :server)) > + (erc-port (or (plist-get plist :port) > + (and ircsp (erc-normalize-port 'ircs-u)) > + erc-port)) > + (erc-nick (or (plist-get plist :nick) erc-nick)) > + (erc-password (plist-get plist :password)) > + (args (erc-select-read-args))) > + (unless ircsp > + (setq ircsp (eql 6697 erc-port))) > + (apply (if ircsp #'erc-tls #'erc) args))) > + > +;; The current spec, unlike the 2003 Butcher draft, doesn't explicitly > +;; allow for an auth[:password]@ component (or trailing ,flags or > +;; &options). > +;; > +;; https://www.iana.org/assignments/uri-schemes > +;; https://datatracker.ietf.org/doc/html/draft-butcher-irc-url#section-6 > + This is a breaking change, no? I think it should be in NEWS, even if it is only to make ERC more standards compliant.