GNU bug report logs - #49860
28.0.50; add IRCv3 building blocks to ERC

Previous Next

Full log

View this message in rfc822 format

From: "J.P." <jp <at> neverwas.me>
To: Björn Bidar <bjorn.bidar <at> thaodan.de>
Cc: emacs-erc <at> gnu.org, 49860 <at> debbugs.gnu.org
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Date: Tue, 16 Jul 2024 20:17:38 -0700

Hi Björn,

Björn Bidar <bjorn.bidar <at> thaodan.de> writes:

> How would IRv3 extension be implement as minor mode would work?
> For example deactivating them does not work without reconnecting.
> Further they are also interconnected you need some to activate others.

It's true that minor modes tend to be user-facing with user-initiated
activation: the user pulls a lever to toggle it on and off. With this
design, the protocol pulls the lever, sometimes by way of other
extensions when "interconnected," as you say. However, the user still
controls which advertised subset gets activated. What _won't_ work is
trying to run

  (erc-v3--foo +1)

out of the blue and expecting ERC to activate `foo' somehow. That must
be done via the protocol (and ultimately via user configuration).

My intention in describing these extensions as conforming to the
minor-mode interface (to whatever extent such a thing exists, even as a
loosely defined set of requirements) was merely as shorthand to imply
they provide setup and teardown code, a mode variable, etc. affecting
functionality layered atop a major mode. But while this _does_ satisfy
those fundamental requirements (and thus "implement" the interface),
perhaps that's more of a technicality, and stressing the point will only
cause confusion. Therefore, in the future, I will relegate all such
mention of minor modes to a mere footnote. Thanks for raising this
concern.

> I think there are some where deactivating them doesn't make sense
> to me such as for example the server-time extension where the client
> will know when a message was send as opposed to not knowing it and
> assuming that the time the message was send is the time the client
> receives the message.

Well, some module attempting to deactivate them itself via

  (erc-v3--foo -1)

definitely won't work. But manually coaxing the protocol to do so on
your behalf, i.e.,

  /CAP REQ -server-time RET

is indeed supported, albeit probably nonsensical and not recommended.

Deactivating them because they've been DEL'd, however, is an actual
requirement and obviously protocol-driven. Being asked to do that for
`server-time' in particular is admittedly unlikely. I suppose in
pathological cases, like a replication failover or a clock-sync/skew
emergency, the network may need to disable stamps temporarily so they're
not relayed to users (where they could cause havoc in logs).

Anyway, ERC has been offering a mostly functional POC for users to try
for years now. You can find the info elsewhere in this bug thread, just
in case you're interested or are desperate to read some questionable
code. However, I'm guessing "not very" since my records indicate you're
a Circe user! (But I appreciate your input regardless.)

Cheers,
J.P.

Previous Next

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