Lars Ingebrigtsen <larsi@gnus.org> writes:

> "J.P." <jp@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.)