GNU bug report logs - #56340
Change erc dependencies

Previous Next

Full log

View this message in rfc822 format

From: "J.P." <jp <at> neverwas.me>
To: dick.r.chiang <at> gmail.com
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 56340 <at> debbugs.gnu.org, Amin Bandali <bandali <at> gnu.org>, emacs-erc <at> gnu.org
Subject: bug#56340: Change erc dependencies
Date: Sat, 16 Jul 2022 07:17:31 -0700

[Message part 1 (text/plain, inline)]

As an experiment, I've tried rearranging things into a more traditional
layout, with most of the compile-time dependencies moved to a dedicated
file [1]. This is mainly for show and does nothing for the close
coupling and hard dependencies that have long plagued ERC from a design
standpoint [2]. (There's definitely still something to be said for just
having it all live in erc-backend.)

Still, part of the impetus for collecting all the heavy stuff in one
place was to avoid having to constantly check for hidden snags down the
line. For example, AFAIK, the byte compiler doesn't catch stuff like the
following, which are present in the original, "Don't do this" patch:

Running

  $ emacs -Q -batch -f batch-byte-compile ./lisp/erc/erc-goodies.el

and inspecting the output reveals missing inline expansions for calls to
`erc-log', which are numerous, and which normally resemble something
like

  (require 'erc)
  (byte-compile (macroexpand
                 `(lambda (msg)
                    ,(funcall (get 'erc-log 'compiler-macro)
                              nil 'msg))))

The same goes for other files as well. For example, after doing

  $ emacs -Q -batch -f batch-byte-compile ./lisp/erc/erc-networks.el

notice the missing expansions for `erc--target' accessors in
lisp/erc/erc-networks.elc. Again, where we'd normally expect to see

  (require 'erc)
  (byte-compile (macroexpand
                 `(lambda (targ)
                    ,(funcall (get 'erc--target-string 'compiler-macro)
                              'erc--target 'targ))))

we're instead left with normal function calls. FWIW, the layout in the
attached patch doesn't suffer from these complications. Of course,
that's only one way to confront this stuff, perhaps even the dumbest.
People at home with a clue, please chime in with your insights and shade
(or be haunted 'til your dying day). Thanks!


Overflow
~~~~~~~~

[1] If we did stick with a new file, what's the best name for such a
    thing? I just went with `erc-common', for now, but perhaps something
    ending in -macs or -core would be more faithful to the platform?

[2] However, I was really hoping to start inching toward eventually
    making headway on a goal that's been with ERC since the old CVS
    days, and that's decoupling protocol handling from the display
    machinery, likely by abstracting away the particulars of network
    processes and I/O. This would open the door for "pluggable backends"
    supporting IRC-adjacent client protocols, such as those in use by
    WeeChat and Quassel (or even commercial entities, like IrcCloud).
    Or, at the very least, it'd allow us to start exploring proxy
    protocols, like IRC over WebSockets and bouncer multiplexing
    schemes.

    But erc-backend.el in its current form is the opposite of modular.
    It's hardwired to speak IRC over stream sockets. And while I'd
    really wanted to hold off on shuffling things around until we had a
    solid plan in place, I've come to accept the futility of that
    delusion. As such, I'm hoping we can use whatever shake up emerges
    from this bug report as a somewhat stable stepping stone to nudge
    things in a more modular direction over the next few minor releases.

[0001-Move-ERC-s-core-dependencies-to-separate-file.patch (text/x-patch, attachment)]

Previous Next

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