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

[J.P.]

Stefan Kangas <stefankangas@gmail.com> writes:

> "J.P." <jp@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
Description: Text Data

0001-Teach-thing-at-point-to-recognize-bracketed-IPv6-URL.patch
Description: Text Data

0002-Refactor-erc-select-read-args.patch
Description: Text Data

0003-Default-to-TLS-port-when-calling-erc-tls-from-lisp.patch
Description: Text Data

0004-Add-optional-server-param-to-erc-networks-determine.patch
Description: Text Data

0005-Improve-new-connections-in-erc-handle-irc-url.patch
Description: Text Data

0006-POC-Make-erc-once-with-server-event-more-nimble.patch
Description: Text Data

0007-POC-Support-one-off-JOIN-handlers-in-ERC.patch
Description: Text Data

0008-POC-Use-erc-join-with-callback-in-URL-handler.patch
Description: Text Data

0009-POC-Demo-improved-ol-irc-integration.patch
Description: Text Data

0010-POC-etc-emacs-irc.desktop-New-file.patch
Description: Text Data