GNU bug report logs - #56514
29.0.50; Improve ERC's URI scheme integration for irc:// links

Previous Next

Package: emacs;

Reported by: "J.P." <jp <at> neverwas.me>

Date: Tue, 12 Jul 2022 08:16:01 UTC

Severity: wishlist

Found in version 29.0.50

Fixed in version 29.1

Done: "J.P." <jp <at> neverwas.me>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 56514 in the body.
You can then email your comments to 56514 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to emacs-erc <at> gnu.org, bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Tue, 12 Jul 2022 08:16:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to "J.P." <jp <at> neverwas.me>:
New bug report received and forwarded. Copy sent to emacs-erc <at> gnu.org, bug-gnu-emacs <at> gnu.org. (Tue, 12 Jul 2022 08:16:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.0.50; Improve ERC's URI scheme integration for irc:// links
Date: Tue, 12 Jul 2022 01:14:46 -0700
[Message part 1 (text/plain, inline)]
Allowing users to follow links for various application protocols is
typically done by presenting an interface for external client handlers.
One such interface is `url-irc-function', needed by url.el's `url-irc'
loader. One such handler is `erc-handle-irc-url', tasked by ERC with
teleporting users to the right channel on the right server.

When conditions are ideal, things mostly work as designed. But when the
going gets tough and multiple asynchronous flows are in play, the user
experience suffers. In some cases, things don't work at all (and haven't
since at least Emacs 27). For example, clicking on a link with a channel
only works when an existing connection can be found. Otherwise, a hybrid
server/channel buffer is created, which violates many a foundational
invariant. (That it doesn't blow up right away is troublesome in its own
right and needs addressing stat, IMO.)

The attached changes are mainly meant to shore up the existing
implementation where it's lacking (and otherwise stay out of the way).
Once everything's firing, we should be able to:

  M-x browse-url-at-point RET on any irc:// link anywhere:

    (add-to-list 'browse-url-default-handlers
                 '("\\`ircs?://" . erc--handle-ircs-url))

  Follow irc:// links in eww, gnus, and beyond:

    (setq eww-use-browse-url
          (concat eww-use-browse-url "\\|\\`ircs?:"))

    (push '("\\bircs?://[a-z.@_+0-9%=?&/#-]+"
            0 t erc--handle-ircs-url 0)
          gnus-button-alist)

  Click on org links featuring the nonstandard "/chan/user" syntax:

    (erc--org-init)

Most importantly, we ought to be able to do these things without sharing
anything inadvertently, sensitive or not. A number of minor, supporting
changes that help provide such assurances are also included, such as
ensuring `erc-tls' defaults to a secure port when called from lisp code.

(Note that nothing's yet autoloaded for the snippets above, so you'll
have to require all the players beforehand if trying them out with
a real endpoint, such as "ircs://testnet.ergo.chat/#test".)

In the end, I'm hoping other folks will step forward who may be more
familiar with the libraries mentioned so that nicer renditions can
emerge.

Thanks,
J.P.


In GNU Emacs 29.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.34, cairo version 1.17.6)
 of 2022-07-06 built on localhost
Repository revision: e6504c3eda12c72268d2db6598764f043b74c24d
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12014000
System Description: Fedora Linux 36 (Workstation Edition)

Configured using:
 'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
 'CFLAGS=-O0 -g3'
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP X11 XDBE XIM XINPUT2 XPM GTK3 ZLIB

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils rmc iso-transl tooltip eldoc paren electric
uniquify ediff-hook vc-hooks lisp-float-type elisp-mode mwheel
term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image
regexp-opt fringe tabulated-list replace newcomment text-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch easymenu
timer select scroll-bar mouse jit-lock font-lock syntax font-core
term/tty-colors frame minibuffer nadvice seq simple cl-generic
indonesian philippine cham georgian utf-8-lang misc-lang vietnamese
tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek
romanian slovak czech european ethiopic indian cyrillic chinese
composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help abbrev obarray oclosure cl-preloaded button loaddefs
faces cus-face macroexp files window text-properties overlay sha1 md5
base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads dbusbind inotify lcms2
dynamic-setting system-font-setting font-render-setting cairo
move-toolbar gtk x-toolkit xinput2 x multi-tty make-network-process
emacs)

Memory information:
((conses 16 35545 5688)
 (symbols 48 5073 0)
 (strings 32 13303 1546)
 (string-bytes 1 429956)
 (vectors 16 9197)
 (vector-slots 8 145428 11407)
 (floats 8 21 25)
 (intervals 56 214 0)
 (buffers 992 10))
[0001-Default-to-TLS-port-when-calling-erc-tls-in-lisp-cod.patch (text/x-patch, attachment)]
[0002-Add-optional-server-param-to-erc-networks-determine.patch (text/x-patch, attachment)]
[0003-Improve-how-erc-handle-irc-url-treats-new-connection.patch (text/x-patch, attachment)]
[0004-POC-Make-erc-once-with-server-event-more-nimble.patch (text/x-patch, attachment)]
[0005-POC-Support-one-off-JOIN-handlers-in-ERC.patch (text/x-patch, attachment)]
[0006-POC-Use-erc-join-with-callback-in-URL-handler.patch (text/x-patch, attachment)]
[0007-POC-Demo-improved-ol-irc-integration.patch (text/x-patch, attachment)]
[0008-POC-etc-emacs-irc.desktop-New-file.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Tue, 12 Jul 2022 12:50:02 GMT) Full text and rfc822 format available.

Message #8 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Tue, 12 Jul 2022 14:49:43 +0200
"J.P." <jp <at> neverwas.me> writes:

> (Note that nothing's yet autoloaded for the snippets above, so you'll
> have to require all the players beforehand if trying them out with
> a real endpoint, such as "ircs://testnet.ergo.chat/#test".)

Sounds nice to me.

> In the end, I'm hoping other folks will step forward who may be more
> familiar with the libraries mentioned so that nicer renditions can
> emerge.

It's a large patch series -- perhaps asking questions about specific
libraries would be more productive.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




Severity set to 'wishlist' from 'normal' Request was from Stefan Kangas <stefan <at> marxist.se> to control <at> debbugs.gnu.org. (Wed, 13 Jul 2022 11:47:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Wed, 13 Jul 2022 14:46:02 GMT) Full text and rfc822 format available.

Message #13 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Wed, 13 Jul 2022 07:44:48 -0700
[Message part 1 (text/plain, inline)]
Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>> In the end, I'm hoping other folks will step forward who may be more
>> familiar with the libraries mentioned so that nicer renditions can
>> emerge.
>
> It's a large patch series -- perhaps asking questions about specific
> libraries would be more productive.

Hm, right. Seems I'll have to take my entitled prima dona act elsewhere.


Questions, then (TIA, people):

  1. The first patch strays outside ERC's turf. Should I open a separate
     bug report for it? [1].
  
  2. With how I have things now, we'd use `browse-url-default-handlers'
     to sidestep url.el's loader-finding logic, as performed by
     `url-scheme-get-property'. But that feels a little hacky since my
     new, generalized handler is just a wrapper that calls `url-irc'
     (the loader), which massages the arguments and then calls our
     original (somewhat revamped) handler.

     A cleaner way might be to perhaps make url-irc.el aware of the new
     handler. But for that we'd need `url-scheme-get-property' to map
     all the scheme variants we're interested in, like ircs, irc6, etc.,
     to that same loader. OTOH, that file's pretty ancient, so perhaps
     it's better to just leave it be?

  3. Should I include the actual setup code for the integrations? If so,
     where would that go? My initial plan was to just have it all live
     in the docs, perhaps under a new Info node. BTW (re integrations),
     I also threw in a .desktop file [2], knowing full well that folks
     may just perceive that as more clutter polluting the Emacs tree.
     Should I drop it? People wanting one can just make their own.

  4. I'll approach the Org people separately for this stuff, but just as
     a preview: my main question for them deals with their nonstandard
     "/user" variant of the URI syntax. Specifically, I'd like to know
     how it's supposed to work when a "?key" or multiple comma-separated
     channels (also nonstandard) are present in the URL. I'd also like
     to know how important it is we preserve this feature and how
     amenable they'd be to it (rapidly) going extinct [3].

Other, minor questions remain, some internal to ERC [4], but I'll spare
everyone the trouble for now.

Thanks!


[1] On a system for which `browse-url-can-use-xdg-open' returns non-nil,
    and with point somewhere over some text like "http://[::1]", do

      M-x browse-url-at-point RET

    What happens is that `browse-url-url-at-point' returns
    "http://http://" because `thing-at-point-url-at-point' doesn't seem
    to like IPv6 URLs. This ultimately leads to a

      (call-process "xdg-open" nil 0 nil "http://http://")

    which exits nonzero.

[2] For anyone interested, if your OS supports XDG desktop stuff, you
    can try the included etc/emacs-irc.desktop by doing something like

    a. Change the Exec directive to launch a local emacs -Q

       -Exec=emacs -l erc -f erc--handle-ircs-url %u
       +Exec=/home/me/emacs/master/src/emacs -Q -l erc -f ...
    
    b. $ desktop-file-install --rebuild-mime-info-cache \
         --dir=~/.local/share/applications etc/emacs-irc.desktop
    
    c. $ gtk-launch emacs-irc 'ircs://testnet.ergo.chat/#test'

[3] Not that it matters, but it took a fair bit of surgery across four
    patches to make "/user" behave as originally intended (according to
    my possibly warped impression). However, I'm pretty convinced it can
    only ever work reliably in conjunction with an IRC extension that's
    not (yet) widely adopted by servers and that ERC doesn't yet
    implement (although bug#49860 has something coming down the pike).

[4] There's also the matter of duplicate functionality WRT the autojoin
    module and URL-triggered channel joining. It'd be nice to find a way
    to defer to existing code when a URL specifies a channel. Obviously,
    when a connection already exists or autojoin is already enabled,
    this won't be an issue. But when that's not the case, what's the
    right move? (Disabling autojoin seems mighty popular.)

    One option is just to refuse to open a new connection without
    autojoin. Or, we could prompt the user for permission to enable it.
    Somewhat complicating this is the fact that autojoin (like all
    modules) is only designed to be enabled globally. (I have a patch to
    address this, but it's only aimed at defining new modules as local
    to a network context.)

[0000-v1-v2.diff (text/x-patch, attachment)]
[0001-Teach-thing-at-point-to-recognize-bracketed-IPv6-URL.patch (text/x-patch, attachment)]
[0002-Accept-bracketed-IPv6-hosts-in-ERC.patch (text/x-patch, attachment)]
[0003-Default-to-TLS-port-when-calling-erc-tls-in-lisp-cod.patch (text/x-patch, attachment)]
[0004-Add-optional-server-param-to-erc-networks-determine.patch (text/x-patch, attachment)]
[0005-Improve-new-connections-in-erc-handle-irc-url.patch (text/x-patch, attachment)]
[0006-POC-Make-erc-once-with-server-event-more-nimble.patch (text/x-patch, attachment)]
[0007-POC-Support-one-off-JOIN-handlers-in-ERC.patch (text/x-patch, attachment)]
[0008-POC-Use-erc-join-with-callback-in-URL-handler.patch (text/x-patch, attachment)]
[0009-POC-Demo-improved-ol-irc-integration.patch (text/x-patch, attachment)]
[0010-POC-etc-emacs-irc.desktop-New-file.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Wed, 13 Jul 2022 15:56:01 GMT) Full text and rfc822 format available.

Message #16 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Wed, 13 Jul 2022 08:55:20 -0700
"J.P." <jp <at> neverwas.me> writes:

>   1. The first patch strays outside ERC's turf. Should I open a separate
>      bug report for it? [1].

No need, as (IMHO) it's obviously correct.

>   3. Should I include the actual setup code for the integrations? If so,
>      where would that go? My initial plan was to just have it all live
>      in the docs, perhaps under a new Info node. BTW (re integrations),

My only comment is that it would be better if this all worked OOTB, but
also that it would be even better if it was easy to switch between erc
and rcirc in one centralized location (as opposed to having to redo the
song and dance for EWW, browse-url, gnus, etc.).

I'm not sure what's the best place to put it though.

>      I also threw in a .desktop file [2], knowing full well that folks
>      may just perceive that as more clutter polluting the Emacs tree.
>      Should I drop it? People wanting one can just make their own.

What does the .desktop file imply here?  Does it just make things easier
to setup or does it come with it's own menu entry in desktop
environments, etc.?  (I don't use any desktop environment myself.)

If it just makes setting things up easier, I don't see why we shouldn't
include it.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Thu, 14 Jul 2022 07:01:02 GMT) Full text and rfc822 format available.

Message #19 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 56514 <at> debbugs.gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Thu, 14 Jul 2022 00:00:28 -0700
[Message part 1 (text/plain, inline)]
Stefan Kangas <stefankangas <at> gmail.com> writes:

> "J.P." <jp <at> neverwas.me> writes:
>
>>   1. The first patch strays outside ERC's turf. Should I open a separate
>>      bug report for it? [1].
>
> No need, as (IMHO) it's obviously correct.

Okay, nice. FWIW, I've since added another test case covering those
bracketed links sometimes found in markup languages.

>>   3. Should I include the actual setup code for the integrations? If so,
>>      where would that go? My initial plan was to just have it all live
>>      in the docs, perhaps under a new Info node. BTW (re integrations),
>
> My only comment is that it would be better if this all worked OOTB, but
> also that it would be even better if it was easy to switch between erc
> and rcirc in one centralized location (as opposed to having to redo the
> song and dance for EWW, browse-url, gnus, etc.).
>
> I'm not sure what's the best place to put it though.

Me neither. But unifying everything seems like a worthy goal and the
responsible thing to do. Although, ERC, as usual, will then have to
decide whether to include compat code or just not support some aspects
of URL handling on older versions of Emacs.

It seems if we could somehow get all IRC-related URL types, like irc6,
to look in lisp/url/url-irc.el for a loader, tweaking the existing code
to serve these other variants would then be pretty straightforward
(assuming that doesn't buck the original design too violently).

>>      I also threw in a .desktop file [2], knowing full well that folks
>>      may just perceive that as more clutter polluting the Emacs tree.
>>      Should I drop it? People wanting one can just make their own.
>
> What does the .desktop file imply here?  Does it just make things easier
> to setup or does it come with it's own menu entry in desktop
> environments, etc.?  (I don't use any desktop environment myself.)
>
> If it just makes setting things up easier, I don't see why we shouldn't
> include it.

As you suspect, some desktop environments use *.desktop files as a means
of declaring default apps for opening various file types and URLs.

IMO, the main problem is that it's difficult to know what folks expect
to happen when clicking an irc:// link (in Firefox, say). For example,
my current version tries to use an existing Emacs instance and falls
back to creating one with emacs -Q. But people may not run an Emacs
server or else may not want an existing one disturbed by IRC silliness.
Others may want to load their own ERC config instead of being handed a
plain vanilla ERC (which is currently the case).

For these reasons, I find it unlikely we'd want to include this. But, if
things go the other way, now or in the future, it'd be nice to have it
depend on a unified interface rather than something client-specific.

Anyway, thanks for your input. It's very much appreciated.

[0000-v2-v3.diff (text/x-patch, attachment)]
[0001-Teach-thing-at-point-to-recognize-bracketed-IPv6-URL.patch (text/x-patch, attachment)]
[0002-Refactor-erc-select-read-args.patch (text/x-patch, attachment)]
[0003-Default-to-TLS-port-when-calling-erc-tls-from-lisp.patch (text/x-patch, attachment)]
[0004-Add-optional-server-param-to-erc-networks-determine.patch (text/x-patch, attachment)]
[0005-Improve-new-connections-in-erc-handle-irc-url.patch (text/x-patch, attachment)]
[0006-POC-Make-erc-once-with-server-event-more-nimble.patch (text/x-patch, attachment)]
[0007-POC-Support-one-off-JOIN-handlers-in-ERC.patch (text/x-patch, attachment)]
[0008-POC-Use-erc-join-with-callback-in-URL-handler.patch (text/x-patch, attachment)]
[0009-POC-Demo-improved-ol-irc-integration.patch (text/x-patch, attachment)]
[0010-POC-etc-emacs-irc.desktop-New-file.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Tue, 08 Nov 2022 14:19:02 GMT) Full text and rfc822 format available.

Message #22 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 56514 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Tue, 08 Nov 2022 06:09:13 -0800
[Message part 1 (text/plain, inline)]
v4.

- Dropped the request-tracking POC stuff because those patches only
  benefit the Org integration, which needs special attention anyway.

- Added unifying changes to url-irc and browse-url that treat ERC and
  rcirc equally.


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?

  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?

  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?

  4. Are any of these non-ERC changes newsworthy enough for etc/NEWS?

Thanks!

[0000-v3-v4.diff (text/x-patch, attachment)]
[0001-Teach-thing-at-point-to-recognize-bracketed-IPv6-URL.patch (text/x-patch, attachment)]
[0002-Accommodate-ircs-URLs-in-url-irc-and-browse-url.patch (text/x-patch, attachment)]
[0003-Refactor-erc-select-read-args.patch (text/x-patch, attachment)]
[0004-Default-to-TLS-port-when-calling-erc-tls-from-lisp.patch (text/x-patch, attachment)]
[0005-Add-optional-server-param-to-erc-networks-determine.patch (text/x-patch, attachment)]
[0006-Improve-new-connections-in-erc-handle-irc-url.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Tue, 08 Nov 2022 14:42:01 GMT) Full text and rfc822 format available.

Message #25 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: ircs:// integration for rcirc (bug#56514)
Date: Tue, 08 Nov 2022 06:41:43 -0800
Hi Philip,

Just a heads up: I'm in the process of possibly tweaking url-irc (and
browse-url) to better support irc:// links in internal Emacs apps. If
you're interested, this mostly concerns the second patch here:

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=56514#22

Basically, I wanted a way to tell `url-irc-erc' whether to connect via
TLS without relying on port numbers and without changing the signature
of `url-irc-function'. Rather than mess with `func-arity' or the like,
I've opted to just hijack an existing variable from the url(-vars)
library, `url-current-object', which seems ready made for this purpose.
The idea is to simply bind it to the parsed URL object during calls to
`url-irc-function'. Please let me know if you see any downsides
to doing this or if a smarter approach comes to mind.

BTW, as the patch shows, I've left the rcirc side alone. But if you want
to handle ircs:// links without bothering with all the
`url-current-object' business above, simply arranging to switch to 'tls
whenever the port is 6697 should have you pretty well covered, I think.
Let me know if that doesn't make sense.

Thanks,
J.P.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Tue, 08 Nov 2022 15:17:01 GMT) Full text and rfc822 format available.

Message #28 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: "J.P." <jp <at> neverwas.me>, 56514 <at> debbugs.gnu.org
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Tue, 8 Nov 2022 07:16:02 -0800
"J.P." <jp <at> neverwas.me> 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" <jp <at> neverwas.me>
> 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" <jp <at> neverwas.me>
> 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" <jp <at> neverwas.me>
> 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" <jp <at> neverwas.me>
> 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.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Wed, 09 Nov 2022 13:42:02 GMT) Full text and rfc822 format available.

Message #31 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org,
 Lars Ingebrigtsen <larsi <at> gnus.org>
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Wed, 09 Nov 2022 05:41:34 -0800
[Message part 1 (text/plain, inline)]
Stefan Kangas <stefankangas <at> gmail.com> writes:

> "J.P." <jp <at> neverwas.me> 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.

Thinking about this more, I guess it's fine if a modern ERC running on
an older Emacs uses the port alone to decide whether to connect over
TLS. As such, I've abandoned the whole `url-irc-function' thing in favor
of adding a proper argument, as suggested. The small fraction of users
with their own `url-irc-function' (if any) may feel some churn though.

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

Makes sense. I have thus added the missing ingredients and wired them
up.

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

Added.

> I also added some notes inline below:

Much appreciated!

>> From 0d191d30b15ea2d5b6042f51c6cf421b82feb7e5 Mon Sep 17 00:00:00 2001
>> From: "F. Jason Park" <jp <at> neverwas.me>
>> 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.

Installed.

>> From 6fd2f75707f123abfbcfae2d4f2837efed5b7adc Mon Sep 17 00:00:00 2001
>> From: "F. Jason Park" <jp <at> neverwas.me>
>> 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.

Added.

> What about `irc6' and `irc6s'?  Should they have aliases?

I guess I was trying to avoid growing lisp/loaddefs.el on account of a
couple URL schemes that haven't caught on in the wild (and don't seem
poised to). Still, I might as well ask around with some IRC folk just to
be sure.

>> From a9b47f5a6079fb3030c9e1514b4cbbda86dafff8 Mon Sep 17 00:00:00 2001
>> From: "F. Jason Park" <jp <at> neverwas.me>
>> 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.

Right, I definitely plan on mentioning this and most other ERC changes
in some fashion.

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

I've removed the option entirely because I've come to realize it's
unlikely a new user would ever set a port parameter to an IANA name in
the first place (via :port, `erc-port', or whatever). And existing users
accustomed to doing so obviously already know what to expect (namely,
quasi-obsolete port numbers, like 194).

>> From 3658e89614cbe3b5b27f09271b7bc738a1c7ec38 Mon Sep 17 00:00:00 2001
>> From: "F. Jason Park" <jp <at> neverwas.me>
>> Date: Mon, 11 Jul 2022 05:14:57 -0700
>> Subject: [PATCH 6/6] Improve new connections in erc-handle-irc-url
> [...]
>> +
>> +@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.

Agreed! That's basically nonsense (and so removed).

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

ERC has always supported the auth:pass@ stuff, but my comment was
confusing, so I've deleted it.


Thanks so much for looking at these changes!

[0000-v4-v5.diff (text/x-patch, attachment)]
[0002-Accommodate-ircs-URLs-in-url-irc-and-browse-url.patch (text/x-patch, attachment)]
[0003-Refactor-erc-select-read-args.patch (text/x-patch, attachment)]
[0004-Default-to-TLS-port-when-calling-erc-tls-from-lisp.patch (text/x-patch, attachment)]
[0005-Add-optional-server-param-to-erc-networks-determine.patch (text/x-patch, attachment)]
[0006-Improve-new-connections-in-erc-handle-irc-url.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Wed, 09 Nov 2022 13:47:02 GMT) Full text and rfc822 format available.

Message #34 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: ircs:// integration for rcirc (bug#56514)
Date: Wed, 09 Nov 2022 05:46:11 -0800
"J.P." <jp <at> neverwas.me> writes:

> Rather than mess with `func-arity' or the like, I've opted to just
> hijack an existing variable from the url(-vars) library,
> `url-current-object', which seems ready made for this purpose. The
> idea is to simply bind it to the parsed URL object during calls to
> `url-irc-function'.

Please disregard the above (meaning most everything from my previous
email). Turns out I forgot all about Compat (ironically), which should
make this all a nonissue.

> simply arranging to switch to 'tls whenever the port is 6697 should
> have you pretty well covered, I think.

Actually, this bit here still applies if by chance you want rcirc to
handle ircs:// links. (Not saying you should.)

Thanks and apologies for the noise.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Wed, 09 Nov 2022 17:10:01 GMT) Full text and rfc822 format available.

Message #37 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: "J.P." <jp <at> neverwas.me>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: ircs:// integration for rcirc (bug#56514)
Date: Wed, 09 Nov 2022 17:09:29 +0000
"J.P." <jp <at> neverwas.me> writes:

>> simply arranging to switch to 'tls whenever the port is 6697 should
>> have you pretty well covered, I think.
>
> Actually, this bit here still applies if by chance you want rcirc to
> handle ircs:// links. (Not saying you should.)

I think this would be a nice thing to have (not that I encounter ircs://
links that often...).

> Thanks and apologies for the noise.

No problem, I was more confused than disturbed in any way.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Fri, 11 Nov 2022 14:06:02 GMT) Full text and rfc822 format available.

Message #40 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 56514 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Fri, 11 Nov 2022 06:05:16 -0800
[Message part 1 (text/plain, inline)]
v6. Fixed compat function. Removed convenience function for browsing
URLs. Deleted nonsensical paragraph from doc (overdue). Added test
scenario.

[0000-v5-v6.diff (text/x-patch, attachment)]
[0001-Accommodate-ircs-URLs-in-url-irc-and-browse-url.patch (text/x-patch, attachment)]
[0002-Refactor-erc-select-read-args.patch (text/x-patch, attachment)]
[0003-Default-to-TLS-port-when-calling-erc-tls-from-lisp.patch (text/x-patch, attachment)]
[0004-Add-optional-server-param-to-erc-networks-determine.patch (text/x-patch, attachment)]
[0005-Improve-new-connections-in-erc-handle-irc-url.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Wed, 16 Nov 2022 14:24:02 GMT) Full text and rfc822 format available.

Message #43 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 56514 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Wed, 16 Nov 2022 06:22:59 -0800
Quick note:

> diff --git a/lisp/erc/erc-compat.el b/lisp/erc/erc-compat.el
> index 03bd8f1352..340d90ba96 100644
> --- a/lisp/erc/erc-compat.el
> +++ b/lisp/erc/erc-compat.el
> @@ -32,6 +32,7 @@
>  ;;; Code:
> [...] 
> +
> +(when (< emacs-major-version 29)
> +  (unless (assoc "\\`irc6?s?://" browse-url-default-handlers)
> +    (push '("\\`irc6?s?://" . erc-compat--29-browse-url-irc)
> +          browse-url-default-handlers)))

This won't work on 27, so we'll probably have to do something like

  (cond ((fboundp 'browse-url-irc)) ; 29
        ((boundp 'browse-url-default-handlers) ; 28
         (cl-pushnew '("\\`irc6?s?://" . erc-compat--29-browse-url-irc)
                     browse-url-default-handlers))
        ((boundp 'browse-url-browser-function) ; 27
         (require 'browse-url)
         (let ((existing browse-url-browser-function))
           (setq browse-url-browser-function
                 (if (functionp existing)
                     (lambda (u &rest r)
                       (apply (if (string-match-p "\\`irc6?s?://" u)
                                  #'erc-compat--29-browse-url-irc
                                existing)
                              u r))
                   (cons '("\\`irc6?s?://" . erc-compat--29-browse-url-irc)
                         existing))))))

> +
>  (provide 'erc-compat)




bug marked as fixed in version 29.1, send any further explanations to 56514 <at> debbugs.gnu.org and "J.P." <jp <at> neverwas.me> Request was from "J.P." <jp <at> neverwas.me> to control <at> debbugs.gnu.org. (Thu, 17 Nov 2022 06:10:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Thu, 15 Dec 2022 12:24:05 GMT) Full text and rfc822 format available.

bug unarchived. Request was from "J.P." <jp <at> neverwas.me> to control <at> debbugs.gnu.org. (Fri, 30 Dec 2022 13:04:01 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Fri, 30 Dec 2022 14:21:02 GMT) Full text and rfc822 format available.

Message #52 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 56514 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Fri, 30 Dec 2022 06:20:46 -0800
FYI, these changes introduced a bug related to the default non-TLS port
for interactive entry-point invocations. It's hopefully being addressed
by

  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=60428

Thanks.





bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 28 Jan 2023 12:24:05 GMT) Full text and rfc822 format available.

bug unarchived. Request was from "J.P." <jp <at> neverwas.me> to control <at> debbugs.gnu.org. (Mon, 06 Nov 2023 01:12:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Mon, 06 Nov 2023 02:37:01 GMT) Full text and rfc822 format available.

Message #59 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: "J.P." <jp <at> neverwas.me>
To: 56514 <at> debbugs.gnu.org
Cc: emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50; Improve ERC's URI scheme integration for
 irc:// links
Date: Sun, 05 Nov 2023 18:34:59 -0800
[Message part 1 (text/plain, inline)]
There's been some mention on the tracker recently regarding `func-arity'
and misguided expectations. If it's important to stamp out misuses in
the Emacs tree, then I suppose the one in `url-irc' qualifies. The
attached patch should fix it, I think.

Technically, this bug was introduced in Emacs 29.1, but it's probably
not worth disturbing the release branch over.

[0001-Don-t-use-func-arity-to-trigger-API-warning-in-url-i.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#56514; Package emacs. (Sat, 11 Nov 2023 10:17:02 GMT) Full text and rfc822 format available.

Message #62 received at 56514 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: "J.P." <jp <at> neverwas.me>
Cc: 56514 <at> debbugs.gnu.org, emacs-erc <at> gnu.org
Subject: Re: bug#56514: 29.0.50;
 Improve ERC's URI scheme integration for irc:// links
Date: Sat, 11 Nov 2023 12:15:08 +0200
> Cc: emacs-erc <at> gnu.org
> From: "J.P." <jp <at> neverwas.me>
> Date: Sun, 05 Nov 2023 18:34:59 -0800
> 
> There's been some mention on the tracker recently regarding `func-arity'
> and misguided expectations. If it's important to stamp out misuses in
> the Emacs tree, then I suppose the one in `url-irc' qualifies. The
> attached patch should fix it, I think.
> 
> Technically, this bug was introduced in Emacs 29.1, but it's probably
> not worth disturbing the release branch over.

Yes, please install on master, and thanks.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 09 Dec 2023 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 110 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.