GNU logs - #49860, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: "J.P." <jp@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 04 Aug 2021 01:10:02 +0000
Resent-Message-ID: <handler.49860.B.162803939730344 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 49860 <at> debbugs.gnu.org
From: "J.P." <jp@HIDDEN>
Date: Tue, 03 Aug 2021 18:04:42 -0700
Message-ID: <87pmuuvx3p.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=136.175.108.76; envelope-from=jp@HIDDEN;
 helo=mail-108-mta76.mxroute.com
X-Spam_score_int: -18
X-Spam_score: -1.9
X-Spam_bar: -
X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.4 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.4 (--)

Let's try this again (previous attempt vanished down the memory hole).

-------------------- Start of forwarded message --------------------
From: "J.P." <jp@HIDDEN>
To: bug-gnu-emacs@HIDDEN
Subject: 28.0.50; add IRCv3 building blocks to ERC
Date: Tue, 03 Aug 2021 02:22:59 -0700
Cc: emacs-erc@HIDDEN

Hi,

It's high time we explored bringing IRCv3 to ERC. I say we approach this
by focusing first on those innovations most likely to alleviate the more
pernicious problems endangering this client, such as

  * text processing bottlenecks
  * buffer association / session management / connection bookkeeping
  * maintenance debt

and leave the bells and whistles (fun stuff) for the next generation of
contributors [1].


Text processing

Perhaps most evident during history playback, sluggish message handling
looks poised to become a persistent and pervasive drag. This will likely
only worsen as the average length, complexity, and frequency of messages
increases. In the short term, I'd like to offer UI feedback indicating
the relative progress of remaining work by leveraging the heads-up that
batch provides [2].

Of course, this won't improve raw performance or relieve any I/O
pressure [3], but it will enrich the user experience overall. Also worth
prioritizing (even if it prolongs wait times, IMO) would be ensuring
some allowance for minimal interactivity (like basic navigation) while
processing is ongoing.


Bookkeeping

IRCv3 provides a much needed solution for determining and tracking
session ownership and uniqueness, and that's account awareness. While
useful for keeping tabs on other users, it also offers standardized,
real-time knowledge of a user's own authentication status [4]. This is
critical for laying to rest long festering issues [5] widely felt during
the recent move from Freenode to Libera.


Codebase

The flexibility and granularity demanded by the spec (different sets of
extensions for different sessions) forces us to make ERC more limber and
session-focused. This means ensuring the right seams and machinery exist
for adapting to context/environment at runtime. The CLOS dispatch
facility may be the obvious choice, but any combination of solutions
providing comparable flexibility would be a marked improvement over the
status quo.


A call to action
~~~~~~~~~~~~~~~~

To kick things off, I'm asking for a seasoned contributor to volunteer
their experience and elbow grease and to roll up their sleeves and get
stuck in with me down here in debbugstan. I vow to do whatever it takes
to shoulder most of the burden, whether that means cobbling together a
blueprint to get the ball rolling and/or doing the lion's share of the
intel legwork [6]. Please find it in yourself to step forward and answer
the call.

Thanks,
J.P.


Notes
~~~~~

[1] Even the traditional set of building blocks I hope to introduce
    should open the door to a wealth of opportunities. For example, by
    caching and tracking things like away statuses, idle times, and
    account IDs, we can dynamically update buffers to have nicks go dim
    or italic and otherwise react as updates arrive. (For anyone
    saying "please no": as with all things ERC, such enhancements would
    be optional/opt-in. The point is the possibilities are many.)

[2] https://ircv3.net/specs/extensions/batch

[3] Eventually, it may be nice to actually shoot for performance gains,
    perhaps by spawning child processes that ingest raw batched text and
    return structured data nearly ready for insertion. Also along these
    lines would be an optional "agent" subprocess to buffer I/O and
    wrangle PINGs while Emacs is otherwise preoccupied. (Some of the
    server-initiated message types introduced by IRCv3 are pretty
    chatty.)

[4] https://ircv3.net/specs/extensions/account-notify

[5] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=48598

[6] Actually, I've been engaged in the latter (note taking, knocking on
    doors) for the better part of a year, now. As for the former, a
    provisional/experimental (but usable) implementation may soon find
    its way to this thread, if only to kick start the conversation.


In GNU Emacs 28.0.50 (build 1, x86_64-redhat-linux-gnu, GTK+ Version 3.24.30, cairo version 1.17.4)
 of 2021-07-20 built on localhost
Repository revision: 1b251ed4e8550c889d17fe7d88f58aa2fbc95fe0
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12011000
System Description: Fedora 34 (Workstation Edition)

Configured using:
 'configure --enable-check-lisp-object-type --enable-checking=yes,glyphs
 --build=x86_64-redhat-linux-gnu --host=x86_64-redhat-linux-gnu
 --program-prefix= --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin
 --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share
 --includedir=/usr/include --libdir=/usr/lib64 --libexecdir=/usr/libexec
 --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man
 --infodir=/usr/share/info --with-dbus --with-gif --with-jpeg --with-png
 --with-rsvg --with-tiff --with-xft --with-xpm --with-x-toolkit=gtk3
 --with-gpm=no --with-xwidgets --with-modules --with-harfbuzz
 --with-cairo --with-json build_alias=x86_64-redhat-linux-gnu
 host_alias=x86_64-redhat-linux-gnu CC=gcc 'CFLAGS=-O0 -g3'
 LDFLAGS=-Wl,-z,relro
 PKG_CONFIG_PATH=:/usr/lib64/pkgconfig:/usr/share/pkgconfig'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON
LCMS2 LIBOTF LIBSELINUX LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY
INOTIFY PDUMPER PNG RSVG SECCOMP SOUND THREADS TIFF TOOLKIT_SCROLL_BARS
X11 XDBE XIM XPM XWIDGETS 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
  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
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml mml-sec epa derived epg epg-config gnus-util rmail
rmail-loaddefs auth-source cl-seq eieio eieio-core cl-macs
eieio-loaddefs password-cache json map text-property-search time-date
subr-x seq byte-opt gv bytecomp byte-compile cconv 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
iso-transl tooltip eldoc electric uniquify ediff-hook vc-hooks
lisp-float-type 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 elisp-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 cl-generic
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 charscript charprop
case-table epa-hook jka-cmpr-hook help simple abbrev obarray
cl-preloaded nadvice button loaddefs faces cus-face macroexp files
window text-properties overlay sha1 md5 base64 format env code-pages
mule custom widget hashtable-print-readable backquote threads
xwidget-internal dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting cairo move-toolbar gtk x-toolkit
x multi-tty make-network-process emacs)

Memory information:
((conses 16 51359 6165)
 (symbols 48 6620 1)
 (strings 32 18257 1521)
 (string-bytes 1 615936)
 (vectors 16 13438)
 (vector-slots 8 179083 10089)
 (floats 8 21 47)
 (intervals 56 260 0)
 (buffers 992 10))

-------------------- End of forwarded message --------------------

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: "J.P." <jp@HIDDEN>
Subject: bug#49860: Acknowledgement (28.0.50; add IRCv3 building blocks to
 ERC)
Message-ID: <handler.49860.B.162803939730344.ack <at> debbugs.gnu.org>
References: <87pmuuvx3p.fsf@HIDDEN>
X-Gnu-PR-Message: ack 49860
X-Gnu-PR-Package: emacs
Reply-To: 49860 <at> debbugs.gnu.org
Date: Wed, 04 Aug 2021 01:10:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 49860 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
49860: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D49860
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: "J.P." <jp@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Aug 2021 14:19:02 +0000
Resent-Message-ID: <handler.49860.B49860.162825952212793 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 49860 <at> debbugs.gnu.org
Cc: emacs-erc@HIDDEN
From: "J.P." <jp@HIDDEN>
References: <87pmuuvx3p.fsf@HIDDEN>
Date: Fri, 06 Aug 2021 07:18:21 -0700
In-Reply-To: <87pmuuvx3p.fsf@HIDDEN> (J. P.'s message of "Tue, 03 Aug
 2021 18:04:42 -0700")
Message-ID: <87y29eslle.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Hi,

I've gone ahead and started laying some groundwork [1]. Although parts
may look rather cemented in place, please don't let that deter anyone
from proposing a new direction, even if that means a complete overhaul.

In the meantime, I'm offering a usable POC-turned-WIP [2] that I'll
continue to update and report on until told otherwise. The basic
approach is rather conservative, with compatibility driving most
decisions. As such, external packages like erc-hl-nicks appear to hold
up just fine, though that's merely a happy side effect. (BTW, I've been
using some form of this as a daily driver for some time now, not that
anyone should care.)

Since waiting for collaborators to emerge from the woodwork may take
forever, I've decided to start shaving off small pieces and submitting
them as separate bugs. Some of these changes won't make much sense
without the larger context, but so be it. And while it may appear like
prevailing attitudes toward bold changes in ERC country would render
such an exercise absurd and quixotic, I think the sheer presence of lots
of little crumbs out on the dance floor leading back here can only help
long term.

Thanks,
J.P.

P.S. Perhaps this bug's severity should be reconsidered because some v3
extensions, like SASL, may soon be de facto required by major networks.

Notes
~~~~~

[1] Latest: https://jpneverwas.gitlab.io/erc-tools/49860/patches.tar.gz
            https://jpneverwas.gitlab.io/erc-tools/49860/logs.tar.gz

    Snapshots for refuseniks:

    https://debbugs.gnu.org/cgi/bugreport.cgi?att=1;msg=6;filename=patches.tar.gz;bug=49860
    https://debbugs.gnu.org/cgi/bugreport.cgi?msg=6;bug=49860;filename=logs.tar.gz;att=2

[2] To try this thing without patching/building, just install as usual:

      (require 'package)

      (push '("erc-tools"
              . "https://jpneverwas.gitlab.io/erc-tools/archive/")
            package-archives)

    Then M-x list-packages RET, and find the bottom-most entry for this
    bug, which should look something like:

      erc 49860.20210805.5 available An Emacs Internet Relay Chat ...

    And hit [Install] in the popup. After that, just add:

      (require 'erc-v3)
      (push 'v3 erc-modules)

      ;; Optionally, add this demo module showing some v3 features in action
      (push 'eldoc erc-modules)

    And connect as you normally would. (If you need SASL, see the
    commentary in erc-v3-sasl.el).

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: Olivier Certner <ocert.dev@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Aug 2021 18:08:01 +0000
Resent-Message-ID: <handler.49860.B.16282732383091 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: "J.P." <jp@HIDDEN>
Cc: 49860 <at> debbugs.gnu.org, emacs-erc@HIDDEN
From: Olivier Certner <ocert.dev@HIDDEN>
Date: Fri, 06 Aug 2021 20:07:01 +0200
Message-ID: <5074327.2cGJQEq9Kv@ravel>
In-Reply-To: <87y29eslle.fsf@HIDDEN>
References: <87pmuuvx3p.fsf@HIDDEN> <87y29eslle.fsf@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"
Received-SPF: pass client-ip=212.27.42.5; envelope-from=ocert.dev@HIDDEN;
 helo=smtp5-g21.free.fr
X-Spam_score_int: -20
X-Spam_score: -2.1
X-Spam_bar: --
X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.6 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.6 (--)

Hi J.P.,

Just a small word to say that I didn't have time to review your work (this you 
have noticed...) and probably will not for the next 2 months. I may have a 
small window to try catching up at beginning of September, that's all I can 
hope for at this point. In the meantime, good luck and keep up with this work.

Thanks,
Olivier

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: Olivier Certner <ocert.dev@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Aug 2021 18:08:02 +0000
Resent-Message-ID: <handler.49860.B49860.16282732353074 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: "J.P." <jp@HIDDEN>
Cc: 49860 <at> debbugs.gnu.org, emacs-erc@HIDDEN
X-Debbugs-Original-Cc: bug-gnu-emacs@HIDDEN, emacs-erc@HIDDEN, 49860 <at> debbugs.gnu.org
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.16282732353074
          (code B ref 49860); Fri, 06 Aug 2021 18:08:02 +0000
Received: (at 49860) by debbugs.gnu.org; 6 Aug 2021 18:07:15 +0000
Received: from localhost ([127.0.0.1]:51323 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mC4FX-0000nW-9t
	for submit <at> debbugs.gnu.org; Fri, 06 Aug 2021 14:07:15 -0400
Received: from smtp5-g21.free.fr ([212.27.42.5]:58412)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <ocert.dev@HIDDEN>) id 1mC4FT-0000nJ-1W
 for 49860 <at> debbugs.gnu.org; Fri, 06 Aug 2021 14:07:13 -0400
Received: from ravel.localnet (unknown [109.210.79.244])
 (Authenticated sender: ocert.dev@HIDDEN)
 by smtp5-g21.free.fr (Postfix) with ESMTPSA id 913FB5FF20;
 Fri,  6 Aug 2021 20:07:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=free.fr;
 s=smtp-20201208; t=1628273229;
 bh=OrW8cWNa4YkGZSoeqK5dpGn3L6NUnWvHT5Hkjwt0QY8=;
 h=From:To:Cc:Subject:Date:In-Reply-To:References:From;
 b=Nz0vaVwTLMkfDV5+DTQ4YitFcJpnLQd1ai9+kDQ0Z504gJowUes8h6L7h4/R7Dhvz
 pHS0pfEgG1MfVytYd9/v7A04BXgeTR7WPXL398w0qNzteUVtAEYGN6hiGvZoKU2th2
 CXLBy7cnLnlCZbdBnWjPxtlPtSz1hD7Vk4JDxfWhdvmtJCCRr77rRYp/W9tvLKXGVI
 IGktR+jQd8SrYwmii4k19sLiA6zdupuDx1b4n7kRPuimwdyAtTjbHBcZmcmhM+L5qb
 0ehlFn/YNoxtIyflUPaO+ZNQjrWZ+ewCyMhLSJYBsqKkQWEQgOmOtNjVaMf3ayxmvP
 tdxv28KkLNDLg==
From: Olivier Certner <ocert.dev@HIDDEN>
Date: Fri, 06 Aug 2021 20:07:01 +0200
Message-ID: <5074327.2cGJQEq9Kv@ravel>
In-Reply-To: <87y29eslle.fsf@HIDDEN>
References: <87pmuuvx3p.fsf@HIDDEN> <87y29eslle.fsf@HIDDEN>
MIME-Version: 1.0
Content-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi J.P.,

Just a small word to say that I didn't have time to review your work (this you 
have noticed...) and probably will not for the next 2 months. I may have a 
small window to try catching up at beginning of September, that's all I can 
hope for at this point. In the meantime, good luck and keep up with this work.

Thanks,
Olivier

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: "J.P." <jp@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 06 Aug 2021 23:44:02 +0000
Resent-Message-ID: <handler.49860.B49860.162829343410630 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Olivier Certner <ocert.dev@HIDDEN>
Cc: emacs-erc@HIDDEN, 49860 <at> debbugs.gnu.org
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.162829343410630
          (code B ref 49860); Fri, 06 Aug 2021 23:44:02 +0000
Received: (at 49860) by debbugs.gnu.org; 6 Aug 2021 23:43:54 +0000
Received: from localhost ([127.0.0.1]:51567 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mC9VK-0002lO-IC
	for submit <at> debbugs.gnu.org; Fri, 06 Aug 2021 19:43:54 -0400
Received: from mail-108-mta255.mxroute.com ([136.175.108.255]:36625)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jp@HIDDEN>) id 1mC9VF-0002l5-GP
 for 49860 <at> debbugs.gnu.org; Fri, 06 Aug 2021 19:43:53 -0400
Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com)
 (Authenticated sender: mN4UYu2MZsgR)
 by mail-108-mta255.mxroute.com (ZoneMTA) with ESMTPSA id
 17b1dd9db7500074ba.001 for <49860 <at> debbugs.gnu.org>
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256);
 Fri, 06 Aug 2021 23:43:41 +0000
X-Zone-Loop: 3ca821a81fb073e61f5b5b9e3b2ce920dbc25a6dac2e
X-Originating-IP: [149.28.56.236]
From: "J.P." <jp@HIDDEN>
References: <87pmuuvx3p.fsf@HIDDEN> <87y29eslle.fsf@HIDDEN>
 <5074327.2cGJQEq9Kv@ravel>
Date: Fri, 06 Aug 2021 16:43:38 -0700
In-Reply-To: <5074327.2cGJQEq9Kv@ravel> (Olivier Certner's message of "Fri, 06
 Aug 2021 20:07:01 +0200")
Message-ID: <874kc2rvf9.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain
X-AuthUser: masked@HIDDEN
X-Zone-Spam-Resolution: no action
X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0,
 FROM_HAS_DN=0, RCPT_COUNT_THREE=0, TO_DN_SOME=0, FREEMAIL_TO=0,
 MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0, MIME_TRACE=0, RCVD_COUNT_ZERO=0,
 FREEMAIL_ENVRCPT=0, MID_RHS_MATCH_FROM=0, NEURAL_SPAM=0]
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Olivier Certner <ocert.dev@HIDDEN> writes:

> Just a small word ...

Thanks Olivier. Small words mean a lot. I appreciate the encouragement
and the forecast and look forward to hearing your thoughts down the
road.

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 7 Aug 2021 01:59:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 06 21:59:28 2021
Received: from localhost ([127.0.0.1]:51638 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mCBcW-000600-8v
	for submit <at> debbugs.gnu.org; Fri, 06 Aug 2021 21:59:28 -0400
Received: from mail-108-mta52.mxroute.com ([136.175.108.52]:39201)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jp@HIDDEN>) id 1mCBcR-0005zi-NG
 for control <at> debbugs.gnu.org; Fri, 06 Aug 2021 21:59:27 -0400
Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com)
 (Authenticated sender: mN4UYu2MZsgR)
 by mail-108-mta52.mxroute.com (ZoneMTA) with ESMTPSA id 17b1e55eefe00074ba.001
 for <control <at> debbugs.gnu.org>
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256);
 Sat, 07 Aug 2021 01:59:13 +0000
X-Zone-Loop: e0f2d74ea711cf62a02d9ab2431a9c92188f9456e801
X-Originating-IP: [149.28.56.236]
Date: Fri, 06 Aug 2021 18:59:11 -0700
Message-Id: <87tuk2qakw.fsf@HIDDEN>
To: control <at> debbugs.gnu.org
From: "J.P." <jp@HIDDEN>
Subject: control message for bug #49860
X-AuthUser: masked@HIDDEN
X-Zone-Spam-Resolution: no action
X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0,
 NEURAL_SPAM=0, FROM_HAS_DN=0, MIME_GOOD=-0.1, FROM_EQ_ENVFROM=0,
 MIME_TRACE=0, RCVD_COUNT_ZERO=0, RCPT_COUNT_ONE=0, MID_RHS_MATCH_FROM=0,
 TO_DN_NONE=0]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

severity 49860 normal
quit

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 7 Aug 2021 02:02:06 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Fri Aug 06 22:02:06 2021
Received: from localhost ([127.0.0.1]:51644 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1mCBf4-00066o-KU
	for submit <at> debbugs.gnu.org; Fri, 06 Aug 2021 22:02:06 -0400
Received: from mail-108-mta123.mxroute.com ([136.175.108.123]:34357)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jp@HIDDEN>) id 1mCBf3-00066L-4q
 for control <at> debbugs.gnu.org; Fri, 06 Aug 2021 22:02:05 -0400
Received: from filter004.mxroute.com ([149.28.56.236] filter004.mxroute.com)
 (Authenticated sender: mN4UYu2MZsgR)
 by mail-108-mta123.mxroute.com (ZoneMTA) with ESMTPSA id
 17b1e58711800074ba.001 for <control <at> debbugs.gnu.org>
 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES128-GCM-SHA256);
 Sat, 07 Aug 2021 02:01:57 +0000
X-Zone-Loop: 9f5b676e15e452948d558ab826dca0c30a70e6c4f21e
X-Originating-IP: [149.28.56.236]
From: "J.P." <jp@HIDDEN>
To: control <at> debbugs.gnu.org
Subject: control message for bug #49860
Date: Fri, 06 Aug 2021 19:01:45 -0700
Message-ID: <87r1f6qagm.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-AuthUser: masked@HIDDEN
X-Zone-Spam-Resolution: no action
X-Zone-Spam-Status: No, score=-0.1, required=15, tests=[ARC_NA=0,
 FROM_HAS_DN=0, MIME_GOOD=-0.1, TO_DN_NONE=0, NEURAL_SPAM=0,
 RCPT_COUNT_ONE=0, RCVD_COUNT_ZERO=0, FROM_EQ_ENVFROM=0, MIME_TRACE=0,
 MID_RHS_MATCH_FROM=0]
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

tags 49860 + patch
quit

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: Status of IRCv3 support?
References: <87pmuuvx3p.fsf@HIDDEN>
In-Reply-To: <87pmuuvx3p.fsf@HIDDEN>
Resent-From: Alexis <flexibeast@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 29 Apr 2024 09:50:02 +0000
Resent-Message-ID: <handler.49860.B49860.171438418321687 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 49860 <at> debbugs.gnu.org
Cc: emacs-erc@HIDDEN
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.171438418321687
          (code B ref 49860); Mon, 29 Apr 2024 09:50:02 +0000
Received: (at 49860) by debbugs.gnu.org; 29 Apr 2024 09:49:43 +0000
Received: from localhost ([127.0.0.1]:56242 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1s1Ndn-0005dj-Hf
	for submit <at> debbugs.gnu.org; Mon, 29 Apr 2024 05:49:43 -0400
Received: from mail-pf1-x430.google.com ([2607:f8b0:4864:20::430]:47340)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <flexibeast@HIDDEN>) id 1s1Ndm-0005dd-0D
 for 49860 <at> debbugs.gnu.org; Mon, 29 Apr 2024 05:49:42 -0400
Received: by mail-pf1-x430.google.com with SMTP id
 d2e1a72fcca58-6eff2be3b33so3957286b3a.2
 for <49860 <at> debbugs.gnu.org>; Mon, 29 Apr 2024 02:49:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1714384156; x=1714988956; darn=debbugs.gnu.org;
 h=mime-version:message-id:date:user-agent:subject:cc:to:from:from:to
 :cc:subject:date:message-id:reply-to;
 bh=SG6nmVfOdsisOydpuopAkaFt1Sae7eH3gMdhZcjCEqE=;
 b=YSQV5upcujkJ/ukceUW3RFXfEH/ij/Ug0pCh7R3pTYteBjyJ84Byt6DtAl/V82kE7V
 jOyih1EoW+035BuQI94EcBeAP7JLqNP6dk9Vn2Kl5QkitStYzZk3Mc+Ck5DGtYYCVB1I
 VoxfL/jwA3cSYxaisLdS4NPkFTCo9Pl7JtgaRBFgHUu9Sx7JtvRhw4kmoZfnVcG+EH8W
 1vQ4sJUkfGsNoOL8wDq/U4cW3zrwHML5DvnGoTS0RZz7V36KnJcaw4K2yU1fA+AUoMOm
 /ZOv8A0gKowU2EUd+9CxHNwu3+bMEgJhJ/bl/f2WCQiUX2iRNDSe4Ur8xL5AQz7k9A69
 2wew==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1714384156; x=1714988956;
 h=mime-version:message-id:date:user-agent:subject:cc:to:from
 :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=SG6nmVfOdsisOydpuopAkaFt1Sae7eH3gMdhZcjCEqE=;
 b=ZFvev1zjbAZ8r27HhbLHQuLQQEz6kmtAY/JQZb1eBLogaoj8gDq8k2O3KkwXqdh8GT
 pZN1veLgYU5KMl6egQFFOI6e1pv1EBQrTga9poBe6CoZLPimgindn72OMmJpsifsrA83
 KxR2EF+JPmlT/oEx3gRfzOK9/E/LKRqY/FLV7YIOKfr+6dg4omkj33udiqoqJjeXOg+m
 MBQRs7x0I7yffvLRfF9B4muW1n9ixeTwrVWGR/aCBtjTqHhUJEYrUkMOQkob50oGxWYC
 C0X5QJVAnDKAaeFthmFf+NFUEslMoKt2T/CFliBmc2+TBxwDXB+fZIHkC7lU6mDzhZkH
 q7ag==
X-Gm-Message-State: AOJu0YwHwep/RAWQs2VdPydz2o7zhaMdEkPzTsaxTdmnnJfDUinJvfUp
 6zz6p/wPYuX6ZoqbPs3aHux0TtEY4IPnUW5hzweGicP0jWbn2UdwRly9AjEf
X-Google-Smtp-Source: AGHT+IEeQjNa+eueehf1GaHFjvlneGi7NSfHfnbiDl3si7yNEM+nX3L584GVr1UNmklUebx0s7pjLg==
X-Received: by 2002:a05:6a00:4b44:b0:6ec:fe38:d94 with SMTP id
 kr4-20020a056a004b4400b006ecfe380d94mr11540729pfb.33.1714384155518; 
 Mon, 29 Apr 2024 02:49:15 -0700 (PDT)
Received: from localhost ([120.21.2.138]) by smtp.gmail.com with ESMTPSA id
 r13-20020aa79ecd000000b006ed045af796sm18837313pfq.88.2024.04.29.02.49.14
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Mon, 29 Apr 2024 02:49:15 -0700 (PDT)
From: Alexis <flexibeast@HIDDEN>
User-Agent: mu4e 1.12.4; emacs 29.3
Date: Mon, 29 Apr 2024 19:49:12 +1000
Message-ID: <87zftc4hyf.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


i'm using the soju bouncer, which supports the IRCv3 'chathistory'  extension. From what i can tell, this isn't supported in the ERC that ships with 29.3? If that's so, has any work been done on adding support in this regard?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: "J.P." <jp@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 03 May 2024 02:33:01 +0000
Resent-Message-ID: <handler.49860.B49860.17147035529125 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: Alexis <flexibeast@HIDDEN>
Cc: emacs-erc@HIDDEN, 49860 <at> debbugs.gnu.org
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.17147035529125
          (code B ref 49860); Fri, 03 May 2024 02:33:01 +0000
Received: (at 49860) by debbugs.gnu.org; 3 May 2024 02:32:32 +0000
Received: from localhost ([127.0.0.1]:46052 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1s2iiu-0002N7-1h
	for submit <at> debbugs.gnu.org; Thu, 02 May 2024 22:32:32 -0400
Received: from mail-108-mta58.mxroute.com ([136.175.108.58]:44987)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jp@HIDDEN>) id 1s2iir-0002N1-59
 for 49860 <at> debbugs.gnu.org; Thu, 02 May 2024 22:32:30 -0400
Received: from filter006.mxroute.com ([136.175.111.2] filter006.mxroute.com)
 (Authenticated sender: mN4UYu2MZsgR)
 by mail-108-mta58.mxroute.com (ZoneMTA) with ESMTPSA id 18f3c4b596e0008ca2.001
 for <49860 <at> debbugs.gnu.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Fri, 03 May 2024 02:32:02 +0000
X-Zone-Loop: dba1cd6a2748dfdfbca74a007c6845b66abb968b2857
X-Originating-IP: [136.175.111.2]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me
 ; s=x;
 h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:
 Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=BdwKc8EZH8U8oAm5MAkLvKPZykPrE0GxyWsVf/DheuM=; b=YBdXpzjYyNvBoyV4GhmeywBC/8
 HE6Em53wsd86WxcCCJKADopTVCMbeHPfcbvzc83B41aVRT8plLsIugSz4TFhs8dLvh9a1DRI/lEp9
 8pJZc+N9wiY8uyTV4GK2wJzUa5C5VzS8ysqbl6NpTG9YzfVZTmK+t+JGVRiucJv/2rXHlGd+Kz64n
 67zmRmwjwbXMC7oyYYA5WukDW5aQh784dNLMNWffkJBWqG/to44zEcjegpoyZXK1rM5/BMIP0yfwr
 Pusi8LetANONeJCJqD+x9tDKINpm6igRP7aRhIERbtY8znlc5HKchjDQ41nU9A+zNWeBPVTssa5dy
 ThkBSMWw==;
From: "J.P." <jp@HIDDEN>
In-Reply-To: <87zftc4hyf.fsf@HIDDEN> (Alexis's message of "Mon, 29 Apr 2024
 19:49:12 +1000")
References: <87zftc4hyf.fsf@HIDDEN>
Date: Thu, 02 May 2024 19:31:59 -0700
Message-ID: <87y18ry6ao.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Authenticated-Id: masked@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Alexis,

Apologies for the late reply.

Alexis <flexibeast@HIDDEN> writes:

> i'm using the soju bouncer, which supports the IRCv3 'chathistory' extension.
> From what i can tell, this isn't supported in the ERC that ships with
> 29.3?

That's correct.

> If that's so, has any work been done on adding support in this regard?

In terms of basic, foundational IRCv3, a number of design decisions
still have to be made before we can arrive at something installable. I
will try to summarize the work that's been done so far and propose a
rough roadmap/checklist soon. If you're curious or able to contribute,
please say so, and I'll make sure to Cc you.

For now, there are some WIP patches [1] for the various foundational
extensions as well as POCs for fancier ones like chathistory. On 29, you
can try them as an ELPA package by doing

  (require 'package)
  (push '("emacs-erc" . "https://emacs-erc.gitlab.io/bugs/archive/")
        package-archives)

followed by C-u M-x package-install RET erc-49860 RET. When that's done,
connect from emacs -Q with something like

  (require 'erc-v3)
  (erc-toggle-debug-irc-protocol)
  (setopt erc-modules `(eldoc fill-wrap nicks scrolltobottom v3
                        ,@erc-modules)
          erc-v3-extensions `(draft/multiline
                              draft/chathistory draft/event-playback
                              labeled-response ,@erc-v3-extensions)
          erc-scrolltobottom-all t)
  (erc-tls
   :server "bouncer.alexis-vps.el"
   :port 6670
   :nick "alexis"
   :user "alexis@laptop/testnet"
   :password "hunter2"
   :full-name "alexis")

Please be aware that many things simply won't work and that seemingly
random errors will occasionally occur. You'll also be met with many
annoying inconveniences, like having to hit C-v at the top of a target
buffer to fetch non-catch-up history (infinite scroll). Similarly,
buffers for all query targets you've conversed with recently will show
up for no good reason on connect because we don't (yet) persist any
state to disk. Another pain point is query buffers not being renamed
when users change nicks while you're disconnected. Additionally, expect
to see duplicate messages near the bounding "bookend" indicators,
which are themselves unsightly and yet visible by default.

If you do end up trying these builds for any sustained period, please
occasionally check for buffers named "*erc-foo-error*" and, if possible,
send their contents to me along with those of the "*erc-protocol*"
buffer. Remember, if a build breaks for whatever reason, you can always
"roll back" to a less broken one.

Anyway, if not already obvious, ERC needs contributors to make this
initiative happen. So if you know or hear of anyone willing to work on
the most frivolous corner of Emacs, please give them a nudge.

Thanks,
J.P.

[1] https://emacs-erc.gitlab.io/bugs/49860/patches.tar.gz

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: Alexis <flexibeast@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 09 May 2024 06:13:02 +0000
Resent-Message-ID: <handler.49860.B49860.171523513113422 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: "J.P." <jp@HIDDEN>
Cc: emacs-erc@HIDDEN, 49860 <at> debbugs.gnu.org
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.171523513113422
          (code B ref 49860); Thu, 09 May 2024 06:13:02 +0000
Received: (at 49860) by debbugs.gnu.org; 9 May 2024 06:12:11 +0000
Received: from localhost ([127.0.0.1]:53254 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1s4x0k-0003UQ-Md
	for submit <at> debbugs.gnu.org; Thu, 09 May 2024 02:12:10 -0400
Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]:47306)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <flexibeast@HIDDEN>) id 1s4x0f-0003U3-Nq
 for 49860 <at> debbugs.gnu.org; Thu, 09 May 2024 02:12:09 -0400
Received: by mail-pg1-x532.google.com with SMTP id
 41be03b00d2f7-5dca1efad59so425901a12.2
 for <49860 <at> debbugs.gnu.org>; Wed, 08 May 2024 23:11:39 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1715235094; x=1715839894; darn=debbugs.gnu.org;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:from:to:cc:subject:date:message-id:reply-to;
 bh=fGRFPW0MthJ3cdL9wpuN1Yn9e18oq9waoVYana760dI=;
 b=MwuvVuZBP2Txc/WJ9MA9gyMeun+8WgBKtXDAz1JyHU4bJE0vGLophy3wgXX9EeePW2
 miy5j6UwjqHE21MwXOmsMerC5tbBgbHQ+xekSNFgBDY5Pj6oOkseof6BHUVmV2M3nc04
 RuX0WsbLH9S3TzPaU5IHHwG5y6tYdTSsAhmGOjwYPU3HMd3v+zxQyXJYbyRrtHh2Mp/l
 zu3ZwlBBZnFPWu0BYFWAIwOQzAPQjMQr5iFFMTaLaSygxdhxUGcP59jZzWWIZoFmv+6e
 M5chsXGSUqmg0fkRu8f34UPxF1NDBsx/85hfo900Knh62Xh9jB/MEjrMshNV2Gd4Te6B
 XnkA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1715235094; x=1715839894;
 h=mime-version:message-id:date:references:in-reply-to:subject:cc:to
 :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
 bh=fGRFPW0MthJ3cdL9wpuN1Yn9e18oq9waoVYana760dI=;
 b=a3qCNr69aXHORiKsk7/7qnxkH8u/QymLAsduH84OX/Am4MNirNyNphsoEGqPjM173E
 m65NYeXOvLw98vwTMbaRr72rY21Md8+iBnvu6KPrXAr76laMXFtuqRGa6QRse5SBs55W
 GLXJwEj+c0eN5yGnCUN3SIYAq9gALXJfMS9q96vwx7n5yO0xcpiNhgQpXAWYPw5RAjga
 JQbeQ43zex3SFXY+2YUOlMQktigfC+79IKdZ7DZh2W/+xOuxHGFUU5kYJky97YDzzxNy
 BhX57eHGaQMUVLZSIuZ1MnMJuWnb6zIjZVIB+ZjoQKgXB9jT7wRoHLBo78QDZdxJObsh
 HX3w==
X-Gm-Message-State: AOJu0Yz0KR5F6c3Lj9roGst5i1sxJuUPv79xKD9dKRvpa3RKWuUtASbP
 vFwgEB1zYkVOwQMXMOTxs501RNKzbbFxCny/54x3dDOIEr1k/5Za
X-Google-Smtp-Source: AGHT+IHsFRE+b+T1LxJVlhEEWSrNLvMn8OQfnVGWJyBIpRfUrvMpE3V2fjE0ywO3laIrDJK9k+Medw==
X-Received: by 2002:a17:90a:cf14:b0:2ae:78cd:59fe with SMTP id
 98e67ed59e1d1-2b6169db51cmr1379986a91.31.1715235093725; 
 Wed, 08 May 2024 23:11:33 -0700 (PDT)
Received: from localhost ([120.21.79.152]) by smtp.gmail.com with ESMTPSA id
 98e67ed59e1d1-2b628ca4eaasm2487327a91.39.2024.05.08.23.11.32
 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256);
 Wed, 08 May 2024 23:11:33 -0700 (PDT)
From: Alexis <flexibeast@HIDDEN>
In-Reply-To: <87y18ry6ao.fsf@HIDDEN> (J. P.'s message of "Thu, 02 May
 2024 19:31:59 -0700")
References: <87zftc4hyf.fsf@HIDDEN> <87y18ry6ao.fsf@HIDDEN>
Date: Thu, 09 May 2024 16:11:29 +1000
Message-ID: <87a5kzseem.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)


Thanks for the update, and for explaining how to try out current 
work! i'm certainly happy to help with testing things out and 
reporting what i find, although unfortunately i'm not in a 
position to be able to contribute beyond that ....


Alexis.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: "J.P." <jp@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 16 Jul 2024 06:36:02 +0000
Resent-Message-ID: <handler.49860.B49860.17211117532552 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: 49860 <at> debbugs.gnu.org
Cc: emacs-erc@HIDDEN
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.17211117532552
          (code B ref 49860); Tue, 16 Jul 2024 06:36:02 +0000
Received: (at 49860) by debbugs.gnu.org; 16 Jul 2024 06:35:53 +0000
Received: from localhost ([127.0.0.1]:60850 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sTbmx-0000f5-MR
	for submit <at> debbugs.gnu.org; Tue, 16 Jul 2024 02:35:52 -0400
Received: from mail-108-mta158.mxroute.com ([136.175.108.158]:35703)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jp@HIDDEN>) id 1sTbmu-0000ev-T1
 for 49860 <at> debbugs.gnu.org; Tue, 16 Jul 2024 02:35:50 -0400
Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com)
 (Authenticated sender: mN4UYu2MZsgR)
 by mail-108-mta158.mxroute.com (ZoneMTA) with ESMTPSA id
 190ba4113ae00017a3.001 for <49860 <at> debbugs.gnu.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Tue, 16 Jul 2024 06:35:45 +0000
X-Zone-Loop: 83da3df486010145ea989d22bb92b618ec6922e0634a
X-Originating-IP: [136.175.111.3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me
 ; s=x;
 h=Content-Type:MIME-Version:Message-ID:Date:References:In-Reply-To:
 Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=bwlFGPqNhT8uns4f5axBCU8QD+uoRu8AeTNNjqdUDBw=; b=EJRFUOWGH7UlZXXpX7E+y3lL/k
 HfVeaOkR8t3kX1VTffcOcZiuT2ueprtviwX/nD2vsqEuvll1savhQEoqUNpzCvfgilJjtQEObWmSG
 21NoZm3fY35RKrM4H21bsltQbrpjsevNRerAU8rJIoK/SmM4rX8/gLiFGduiSG6GaXElfGIFbXb0w
 nrg1uxI8vYN40WP1rwUdCUvCZmKbcPWidszGuPvZvSioJSCwsgLzXS3aiHaTt1WhEjVL0RfAMjmNL
 fVr6NG2f2VGCiBWlzuLAVU76PToIwS4lGlHMoXClDS6xlxqTOAUIEa1G+ilIkieDpBlnjfbiJVpBO
 iuD5uiAw==;
From: "J.P." <jp@HIDDEN>
In-Reply-To: <87pmuuvx3p.fsf@HIDDEN> (J. P.'s message of "Tue, 03 Aug
 2021 18:04:42 -0700")
References: <87pmuuvx3p.fsf@HIDDEN>
Date: Mon, 15 Jul 2024 23:35:40 -0700
Message-ID: <87h6cp6dz7.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Authenticated-Id: masked@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Here's an update on the current state of the proposed implementation. As
of now, the target version remains ERC 5.7, which will coincide with
Emacs 31 at the earliest. To get involved in this initiative, please
comment in this thread or in the channel.


Modeling an IRCv3 extension
~~~~~~~~~~~~~~~~~~~~~~~~~~~

Modules are the primary means of extending ERC. They're basically
ERC-managed minor modes and customization groups. IRCv3 extensions are
likewise modular and also provide functionality that's activated in a
declarative manner. In many ways, it would make sense to model
extensions as local modules. However, extensions are protocol driven and
depend on coordination with the server. This means successful activation
depends on details discovered from the logical connection long after
modules are typically initialized. Extensions also generally describe
and affect a lower level of functionality than do traditional modules.

For the sake of simplicity, I believe we should frame extensions as
supplementary in nature and as providing additional functionality to
modules. For example, `nickbar' might display account names and away
statuses when extensions providing such awareness become active. And
even when an extension's functionality seems inherently coupled to a
module's feature set, I think we should resist the urge to let
extensions and modules activate or otherwise control one another [1].
For example, the `read-marker' extension seems naturally suited for
integration with `keep-place-indicator', so much so that a hypothetical
implementation would likely be a no-op when the module's disabled. In
these situations, I'd actually prefer silently dropping functionality
over engaging in active feedback, e.g., by enabling the module on the
user's behalf or issuing a didactic warning. Instead, we can explain
these nuanced relationships in the manual and mention in doc strings
that modules can exhibit alternative functionality when various
extensions are active.

With this in mind, I'm proposing we adopt a mostly traditional,
object-oriented approach to modeling extensions, specifically one that
marries a new struct-based type with the convenience and familiarity of
minor modes, all without exposing either as part of the public
interface. Users will instead mostly interact with extensions
indirectly, through a new `v3' module. The subset of extensions slated
for activation will itself be a user option. As for a serious library
API, I'd rather wait a release or two.

Under the proposed scheme, extensions will be actual minor modes with an
associated mode variable and a non-interactive toggle function (rather
than a traditional mode command). These modes will be kept internal and
modified slightly to meet the demands of your typical extension. Most
importantly, instead of being t, a mode variable's enabled value will be
an instance of a new `extension' "type," a hierarchical data structure
to be shared among all buffers of a session as a first-class citizen.
Its purpose: to describe the extension's health and lifecycle stage and
its relationship to other extensions. It may also contain arbitrary
application state relevant to the session.

The bulk of the technical challenges arising from this design are well
understood and thus solvable by prior art. For example, an extension's
definition includes its dependencies, which will be resolved and loaded
in topological order. The more novel challenges mostly involve making
the design play nice with ERC's existing architecture. For example,
modules persist state between IRC sessions by inspecting and possibly
assuming ownership of assets they manage from the prior session. This
ritual normally occurs just after major-mode activation and before
dialing. As mentioned previously, extensions are subject to discovery
and possibly negotiation, meaning if they're to manage modules, they'll
need the ritual to be postponed or prolonged so they can participate.
Complicating matters slightly is the proposed means of presenting users
access to extensions and IRCv3 functionality as a whole: being ERC, this
interface must be compatibility focused and optional by default. History
would thus dictate we do this by encapsulating it all behind a single
`v3' library and an accompanying local module.

Here's an example of an extension's definition:

  (erc-v3--define-capability spam
    :depends '(batch)
    :supports '(labeled-response multiline)
    :aliases '(draft/spam)
    :enablep #'erc-spam--extract-cap-values
    :slots ((foo 0 :type integer)
            (bar nil :type list))
    :keymap erc-v3--spam-mode-map
    (if erc-v3--spam
        (do-init-stuff)
      (undo-init-stuff)))

This can be thought of as a quasi "class" definition for a so-called
`capability', which is a type of `extension' that has additional methods
and attributes relevant to IRCv3 capability negotiation. Under the hood,
this defines a minor mode named `erc-v3--spam' whose activation function
and local mode variable share the same name. The lack of a "-mode"
suffix is an obfuscation tactic to dissuade users and package authors
from discovering and handling it directly. We can provide analogs for
user-defined extensions, if necessary.

Continuing with the example, the `:depends' and `:supports' items
declare hard and soft dependencies respectively, which are guaranteed to
precede this extension if selected for activation. If a hard dependency
is missing, ERC silently skips activation. Everything after the final
keyword pair becomes the body of the mode's toggle function. As
mentioned earlier, the non-nil (enabled) value of the mode variable is
actually an instance of a `capability' (subtype) and is instantiated via
the mode's activation toggle, which doubles as a constructor.


Historical insertions and deletions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

A few key extensions pretty much require some minimally invasive means
of inserting and deleting messages at various historical points in a
buffer (rather than just appending). I've heard various IRC experts
refer to this as the "mutable buffer" requirement. These operations
don't demand "random access" in the constant-time sense. In our case,
such insertions and deletions will be reserved for relatively rare
occasions, so we can likely afford to scan for a single UUID or a
timestamp when necessary. And of those operations stemming from a single
application action, all but the first will be sequential and won't need
scanning. This should afford us the liberty of not having to retain and
associate a marker with every inserted message but instead only track
important ones demarcating interesting regions, such as datelines and
history playback intervals.

The end goal of adding such an infrastructure is a richer, somewhat more
web-like and less terminal-like experience, in which a buffer's visible
contents update dynamically in response to arriving messages. By far the
biggest challenge to providing this functionality is accommodating
so-called "stateful" features, namely, those that treat messages as
quasi "recurrences" where the appearance and behavior of a message
depends on the appearance and behavior of the one preceding it. Modules
providing such features need a way to hook into supported splicing and
excising operations to run integrating code of a healing or "mending"
nature. In practice, this sort of manual interpolation will likely rely
on crude approximations and heuristics, although having a persistent
message store may help minimize any visible scarring.

Here are some examples of stateful features that require nuanced
mending:

- Invisibility. Many modules add their own `invisible' text-property
  tokens for controlling the visibility of affected portions of the
  buffer. For example, timestamp and fool visibility can overlap yet be
  toggled independently. This is made possible by the meticulous merging
  and teasing apart of adjacent regions of invisible properties so that
  intervening newlines and neutral regions also abide.

- Smart folding. A hypothetical future module might provide dynamic
  folding and hiding of successive "JOIN" and "QUIT" messages from the
  same user. When enabled, certain sequences of alternating message
  types would be automatically hidden but could later be revealed
  (unfolded) for inspection.

- Amalgamated reactions. Unseen reactions can show up as normal
  messages, e.g., "* bob reacted with a :thumbs up: to alice saying 'ok,
  you?' 30 min ago", but then vanish when marked as read or scrolled off
  screen (or clicked on), at which point their reaction will be
  aggregated in the summary displayed on the referenced message,
  down-buffer.

The current proposal for an infrastructure supporting such mending
operations boils down to intercepting the execution of insertion-hook
members in `erc-insert-line'. Basically, we'll have a function-valued
variable that modules can decorate as needed with local advice in order
to exert influence over insertion-hook members as they're visited by
`run-hook-wrapped'. In most cases, a wrapper will inspect surrounding
messages before and/or after insertion and take care to alter the
behavior of its own hook members as needed. An analogous and somewhat
simpler interface will be offered for deletions.

In general, the proposed approach is messy and inelegant, with plenty of
unwanted cross pollination and implementation leakage. While a tidier
and more abstraction-preserving pattern would be much preferred, we can
at least find some solace in knowing that these ungainly interfaces will
all be kept internal.


A backing store
~~~~~~~~~~~~~~~

An efficient storage mechanism for structured message data will allow us
to "repaint" portions of a buffer for various needs. This means we can
discard similar info currently retained in text properties and
buffer-local variables, often for relatively rare uses. For example, we
might want to retain the account name of a speaker on all their messages
in order to know whether they were logged in at the time a certain
message attributed to their nick was inserted (not so much for forensics
as UI enhancement). But if we can query that information at will, we can
instead dispense with keeping it in-buffer. We'll also be free to
destructively modify inserted messages in order to display them in an
abbreviated or idealized way instead of dressing them up in a veneer of
`display' props merely to ensure their underlying text remains
unadulterated (for faithful logging and killing, etc.).

It's worth emphasizing that this proposal does not currently advocate
for a meaningfully persistent nonvolatile storage solution spanning
Emacs sessions. Although the store should be resilient enough to survive
reconnects, its primary purpose will be to facilitate the lessening and
simplification of in-buffer, per-message data. It's also worth noting
that this addition won't really help with historical insertions and
deletions, which describe an orthogonal concern. And although the
current WIP implementation has yet to be fleshed out and wired in, it's
pretty much a given it'll rely on SQLite as a back end, meaning we'll be
needing a fallback solution for older Emacsen.


Generic response handlers
~~~~~~~~~~~~~~~~~~~~~~~~~

One key to minimizing the maintenance footprint of this initiative is
somehow finding a way to override long-established response-processing
behavior. Most of it originates from default response handlers, like
`erc-server-PRIVSMG', which run on abnormal response hooks, like
`erc-server-PRIVMSG-functions'. The traditional way of doing this
involves preempting the default handler (e.g., `erc-server-PRIVMSG') by
adding an overriding hook member that returns non-nil. I'm proposing we
add another, internal means of overriding such behavior, namely, by
converting a small subset of default handlers to generic functions.
Going this route should reduce the presence of response-hook members
managed by ERC while also sparing third-party members likely churn (as
well as the hassle of learning about hook depth, which currently only
affects insertion hooks).

Folks who worry about generics proliferation are usually referring to
public functions designed to be overridden by users. In our case, only a
handful of implementations for a given handler will ever exist, and
they'll all be internal, so the "polymorphic" dispatch penalty should be
kept relatively negligible. This penalty is usually at most a minor
concern for high-level code like ours that runs relatively infrequently.
For example, in Python 3.9, the penalty is roughly n log(n) when doing a
"BINARY_ADD" on two lists, which is why Pythonistas use "LIST_EXTEND"
(star syntax) when dealing with hot code paths because its complexity is
linear on account of not needing any dispatch.

One potential complication to be mindful of with these generic handlers
is how they'll intersect with handler aliases. For the purpose of code
reuse, some default handlers have aliases, like `erc-server-NOTICE' for
`erc-server-PRIVMSG'. When converted to generics, these handlers will
still always share the same code as their referent. To put it another
way, barring some terrible abuse of `&context' specializers, generics
can't help us override only one among a set of aliased handlers
(something that's occasionally desirable). For example, if we only want
to override "PRIVMSG" handling, we must code that into the method's
implementation, e.g., by running `cl-call-next-method' on receiving a
"NOTICE", so the message gets the default treatment. This may seem
obvious, but a historical quirk makes it easy to confuse with related
hook behavior because ERC doesn't `defvar-alias' them, so modifying one
never modifies others.


Reusable response handling
~~~~~~~~~~~~~~~~~~~~~~~~~~

A common gripe regarding ERC's response handling API is that there's no
way to pass refined, processed data down the line to other handlers.
Although annoying, it's only meaningful to the extent suitable library
functions exist to process such data. This proposal includes a plan to
address both deficiencies, but only in service of the use case explained
in the previous section about overriding default handlers. The idea is
to leverage a common message-handling paradigm that preserves work
artifacts derived from a raw message and other inputs. A shared message
object retains these products for the remainder of its life. The object
typically offers a set of methods and properties for handlers to perform
common operations on inputs, often repeatedly, without being wasteful
or fussing over complicated implementation details.

At present, ERC's main message type is the `erc-response', which at face
value is inadequate for this purpose. However, if we indulge the notion
of its "substitutability" in existing infrastructure and pretend that
functions and variables expecting a traditional `erc-response' won't
balk when handed a subtype, a wealth of possibilities emerge. (I suggest
we do this.) Ignoring whatever performance gains this reuse-focused
scheme may provide, the main win here, from a maintenance standpoint, is
that a module can override some or all of a default handler's duties
without additional upkeep. IOW, the "downstream" library no longer has
to study the default handler and replicate choice bits of copy pasta.
Rather, the library merely wires together whatever combination of
getters and properties it desires, a la carte.

The proposed implementation demonstrated below may seem a bit heavy on
magic, but it makes adapting existing code to these new, more specific
response objects relatively seamless and transparent (aside from the
requisite symbol renaming). The variant being proposed doesn't actually
use traditional methods but rather slot accessors themselves as caching
getters. Regardless, the key takeaway is that it introduces a set of
`erc-response' subtypes for commonly overridden responses, each with
relevant slots that it initializes lazily, on first use. Pros include
code reuse and encapsulation to better isolate concerns as well as
(likely infinitesimal) performance gains. Cons include additional
onboarding overhead for new contributors and a slightly elevated risk of
misuse due to faulty assumptions about its nonstandard struct behavior.

Here's an example response definition specific to a "PRIVMSG":

  (erc--define-zresponse (PRIVMSG NOTICE)
    :include erc--zstatused
    ( buffer (erc-get-buffer (if (erc--zPRIVMSG-query-p parsed)
                                 (car (erc--zresponse-nuh parsed))
                               (erc--zstatused-target parsed))
                             erc-server-process)
      :type buffer)
    ( query-p (equal (erc-downcase (erc--zstatused-target parsed))
                     (erc--zresponse-mynick-d parsed))
      :type boolean)
    ( speaker (car (erc--zPRIVMSG-nuh parsed))
      :type string)
    ( notice-p (string= (erc-response.command parsed) "NOTICE")
      :type boolean)
    ( input-p (string= (erc--zPRIVMSG-mynick-d parsed)
                       (car (erc--zPRIVMSG-nuh parsed)))
      :type boolean))

In the definition above, the init forms are basically single-use method
bodies for the generated accessors (subsequent calls return cached
results). The init forms themselves are free to reference other
accessors generated by this definition, which in turn initialize _their_
slots, if necessary, in a cascading fashion. The variable `parsed' is a
reference to the `zresponse' instance, i.e., "this"/"self". Some care
has been taken to replicate the inlining benefits and gv-place awareness
provided by definitions normally generated by `cl-defstruct' (although
review by an expert in this area would be most welcome).


Notes
~~~~~

[1] IMO, allowing services to "pull in" one another will only lead to
    unwanted complications. Systems that allow for this already have a
    sophisticated foundation in place to manage intricate interactions
    between producers and consumers.

    A note on terminology: I used to make a point of distinguishing
    between "active" and "enabled" when referring to modules: "enabled"
    meant present in `erc-modules' and "active" meant activated for the
    session as a minor mode. I've since abandoned trying to advocate for
    this usage or any such distinction and am fully resigned to the fact
    that others will always use them interchangeably.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 16 Jul 2024 22:20:01 +0000
Resent-Message-ID: <handler.49860.B49860.172116839722676 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: "J.P." <jp@HIDDEN>
Cc: emacs-erc@HIDDEN, 49860 <at> debbugs.gnu.org
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.172116839722676
          (code B ref 49860); Tue, 16 Jul 2024 22:20:01 +0000
Received: (at 49860) by debbugs.gnu.org; 16 Jul 2024 22:19:57 +0000
Received: from localhost ([127.0.0.1]:34557 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sTqWa-0005tf-IL
	for submit <at> debbugs.gnu.org; Tue, 16 Jul 2024 18:19:56 -0400
Received: from thaodan.de ([185.216.177.71]:58132)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bjorn.bidar@HIDDEN>) id 1sTqWY-0005tO-6Y
 for 49860 <at> debbugs.gnu.org; Tue, 16 Jul 2024 18:19:55 -0400
Received: from odin (dsl-trebng12-50dc75-154.dhcp.inet.fi [80.220.117.154])
 by thaodan.de (Postfix) with ESMTPSA id 5F80FD00030;
 Wed, 17 Jul 2024 01:19:45 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
 t=1721168385; bh=hXrWepAaAgqSvtTGCTk7H1TNVSzQzR3lSYJCE691z1Q=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=NizYep/cheqVshoYP3XrrKk+KeUxp2iSLnpBMHNOUad5QFejik3fXCC9p5bGn6nrU
 k76l88k/iuvm5i+iDsZXOQdbgBVgg9zOmyWgpUARgA2fW+iB99nNKYzyLVwkwfj1mt
 Tp9f/pinUI7lMMbZhA+L8XvIVaQaodWE3BfdYps+ilRpI0qcAjH3bsrUa4eDRXdsBq
 owntUbGC486s5jh6Xk9DKvQaOcuuOmuFjU8ySTU1qWDDcRlIRoJl1kzmJoLIlJPXjQ
 bnRjjhtE46/bVSWP0eD3WZIiu8gtFXsmOEXT7Rx1zt7K0iV4+KlLkJo6w5WdBFlSZR
 0I9se9CITt1E8nNgG1gSqqJsw779dnu5qratw06sEzHvfKka2rfUG3OSZfrvNfdDCh
 HdPFYZqn4Vb+Oqkw5ok6JUc04MAkoOnZUB1+rTF13JCxslGZtZM2evVAovQzUZ9miL
 zg+LzdGyoaDg7x2wqy+X+sXXCYZfsx1Htrqeuyt8fLHL969c2XYjtuooIDqWHT56EY
 +NRJyu6bEznI9+XPwt6JZAZMqPYk1S4nLK356Qbz/dK0h6fFXrXDBBZi8P0/iXny/e
 zpE1HQbKV1JWDnOCOddtIu0kP99ljinY1vVvXD+TYwln4eJvEVq21gbRGMkBBI3SIq
 j7NV6HdTf6jjbndChMhKfZag=
From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
In-Reply-To: <87h6cp6dz7.fsf@HIDDEN> (J. P.'s message of "Mon, 15 Jul
 2024 23:35:40 -0700")
References: <87pmuuvx3p.fsf@HIDDEN> <87h6cp6dz7.fsf@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
 w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
 CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
 HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
 CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
 K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
 HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
 XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
 gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
 AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
 TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
 B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
 pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
 HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
 AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
 dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
 KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
 GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
 S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Wed, 17 Jul 2024 01:19:44 +0300
Message-ID: <87wmllasjj.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  "J.P." <jp@HIDDEN> writes: > Under the proposed scheme, 
 extensions will be actual minor modes with an > associated mode variable
 and a non-interactive toggle function (rather > than a traditional mode
 command). These modes will [...] 
 Content analysis details:   (1.2 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
 1.2 INVALID_MSGID          Message-Id is not valid, according to RFC 2822
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

"J.P." <jp@HIDDEN> writes:

> Under the proposed scheme, extensions will be actual minor modes with an
> associated mode variable and a non-interactive toggle function (rather
> than a traditional mode command). These modes will be kept internal and
> modified slightly to meet the demands of your typical extension. Most
> importantly, instead of being t, a mode variable's enabled value will be
> an instance of a new `extension' "type," a hierarchical data structure
> to be shared among all buffers of a session as a first-class citizen.
> Its purpose: to describe the extension's health and lifecycle stage and
> its relationship to other extensions. It may also contain arbitrary
> application state relevant to the session.

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.

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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: "J.P." <jp@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 17 Jul 2024 03:18:01 +0000
Resent-Message-ID: <handler.49860.B49860.172118627231162 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: =?UTF-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
Cc: emacs-erc@HIDDEN, 49860 <at> debbugs.gnu.org
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.172118627231162
          (code B ref 49860); Wed, 17 Jul 2024 03:18:01 +0000
Received: (at 49860) by debbugs.gnu.org; 17 Jul 2024 03:17:52 +0000
Received: from localhost ([127.0.0.1]:34793 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sTvAt-00086Y-Te
	for submit <at> debbugs.gnu.org; Tue, 16 Jul 2024 23:17:52 -0400
Received: from mail-108-mta121.mxroute.com ([136.175.108.121]:38475)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <jp@HIDDEN>) id 1sTvAq-00086O-LT
 for 49860 <at> debbugs.gnu.org; Tue, 16 Jul 2024 23:17:50 -0400
Received: from filter006.mxroute.com ([136.175.111.3] filter006.mxroute.com)
 (Authenticated sender: mN4UYu2MZsgR)
 by mail-108-mta121.mxroute.com (ZoneMTA) with ESMTPSA id
 190beb2234100017a3.001 for <49860 <at> debbugs.gnu.org>
 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384);
 Wed, 17 Jul 2024 03:17:43 +0000
X-Zone-Loop: 52e5c7746786010bdf828ed9edf8caa1c90d118d03d3
X-Originating-IP: [136.175.111.3]
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=neverwas.me
 ; s=x;
 h=Content-Transfer-Encoding:Content-Type:MIME-Version:Message-ID:Date:
 References:In-Reply-To:Subject:Cc:To:From:Sender:Reply-To:Content-ID:
 Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
 :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe:
 List-Post:List-Owner:List-Archive;
 bh=MudfhPnErF+XGQcM5cMwMMLJ3tMU9Ng0LlIEm46U9oM=; b=joM+n+mYAdB6UGOA//qq+qoSDE
 xxskf2EomAKtSi9Raf4jBLQ7pb8enBjb/48Bwv2pfiqf+16iqajkdcXmYnDUrM83iKi/TVviN3lBG
 o6x31lscR4d9HL7blbu8jSdVkdG+70O3O9LtzNIrx3pdM0CnfA8YT2CcZeEh+yk/mfKrRcq7aQA8b
 KQqc1PsduGYrnTEfgJ7Jw7MwDnikcN7kKCq+amVLSUysq/C78ITIUsHVi0GlWd6to44UOdGCTyAnI
 sEYsuBe9BNIXA0sY3hxZd/4/zIGA/mRhfLmwB+g8gQ/w1T51WQt9ru58ff72G0Ey7yMJyTLx+p0UG
 q28Nz/rg==;
From: "J.P." <jp@HIDDEN>
In-Reply-To: <87wmllasjj.fsf@> ("=?UTF-8?Q?Bj=C3=B6rn?= Bidar"'s message
 of "Wed, 17 Jul 2024 01:19:44 +0300")
References: <87pmuuvx3p.fsf@HIDDEN> <87h6cp6dz7.fsf@HIDDEN>
Date: Tue, 16 Jul 2024 20:17:38 -0700
Message-ID: <874j8oiu5p.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Authenticated-Id: masked@HIDDEN
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

Hi Bj=C3=B6rn,

Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#49860: 28.0.50; add IRCv3 building blocks to ERC
Resent-From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Wed, 17 Jul 2024 04:53:02 +0000
Resent-Message-ID: <handler.49860.B49860.17211919507583 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 49860
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: patch
To: "J.P." <jp@HIDDEN>
Cc: emacs-erc@HIDDEN, 49860 <at> debbugs.gnu.org
Received: via spool by 49860-submit <at> debbugs.gnu.org id=B49860.17211919507583
          (code B ref 49860); Wed, 17 Jul 2024 04:53:02 +0000
Received: (at 49860) by debbugs.gnu.org; 17 Jul 2024 04:52:30 +0000
Received: from localhost ([127.0.0.1]:34879 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1sTweT-0001yF-RD
	for submit <at> debbugs.gnu.org; Wed, 17 Jul 2024 00:52:30 -0400
Received: from thaodan.de ([185.216.177.71]:52234)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <bjorn.bidar@HIDDEN>) id 1sTweQ-0001y1-Vm
 for 49860 <at> debbugs.gnu.org; Wed, 17 Jul 2024 00:52:28 -0400
Received: from odin (dsl-trebng12-50dc75-154.dhcp.inet.fi [80.220.117.154])
 by thaodan.de (Postfix) with ESMTPSA id E4D20D00038;
 Wed, 17 Jul 2024 07:52:15 +0300 (EEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thaodan.de; s=mail;
 t=1721191936; bh=+Qi6wTcO8oLnsX3i8kQfEAmHbfhGi2fmrAQstDjrbKY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date;
 b=05nwkoK4/YAdSAczud7yfWVkiBIevFQ/b2cerpaS9U5U+7KNNq2UZvMsBQ3r3oln4
 oOYAd4EfHUYZ5SyR9tVTtcH9G5BgtCU+crFLLWmqWZjsAXQZPcu+hEnKbnskST8lbN
 RMDjv9fsNdbkbPon+RBQg12LUMvSAjHSXfORmCCeiNi0Q8RcmlILvzeR+SExvmxOGT
 yDnE054MogkLSgnwSW0bn99xTTD2r8HPGxklcUiJowIlt9Es8T9jvwOFm07fb53W+w
 Ns5EOT+HTGPpZFXsQad/emWiBI/nRwOl98ZJFiAVIsbvv9Ihn5UIw11gzxnH8kfnxv
 KDJ7tp3ZlsgqMD9rPGbVxPw53P+xi5FcRAWu0gFZPb9NMt/0nXsPVwvfqA7he+64Hu
 JHobwRjq1kDHz6q1nwE6x5Qx1LXAxIH3JmVOxurTxCW/jn0PNdoEU1z09rhGy1FuJj
 UNMEm1WO8qIcTwABZ0unbJD14x+d8bXn4ObQzXJJrSHCQrhD3JxDF6zClJ2qkgbKh2
 OoMDQ88Q3ABAvUQvAnZhSMhuuqVIHfQoNZZeZx2jvnZ28h9YOZkrX1YstNtBwBYAww
 z+OKidcHo1BXiyiybG8vLnljnlhSkZXhfT8HIIvzz+Q4/dmqYxFVCEkfMK/i7Q3dnY
 iLOWj2DmWBwZhdOgHjFeCFSc=
From: =?UTF-8?Q?Bj=C3=B6rn?= Bidar <bjorn.bidar@HIDDEN>
In-Reply-To: <874j8oiu5p.fsf@HIDDEN> (J. P.'s message of "Tue, 16 Jul
 2024 20:17:38 -0700")
References: <87pmuuvx3p.fsf@HIDDEN> <87h6cp6dz7.fsf@HIDDEN>
 <874j8oiu5p.fsf@HIDDEN>
Autocrypt: addr=bjorn.bidar@HIDDEN; prefer-encrypt=nopreference; keydata=
 mDMEZNfpPhYJKwYBBAHaRw8BAQdACBEmr+0xwIIHZfIDlZmm7sa+lHHSb0g9FZrN6qE6ru60JUJq
 w7ZybiBCaWRhciA8Ympvcm4uYmlkYXJAdGhhb2Rhbi5kZT6IlgQTFgoAPgIbAwULCQgHAgIiAgYV
 CgkICwIEFgIDAQIeBwIXgBYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1/YmAhkBAAoJEFwbdKFl
 HF9oB9cBAJoIIGQKXm4cpap+Flxc/EGnYl0123lcEyzuduqvlDT0AQC3OlFKm/OiqJ8IMTrzJRZ8
 phFssTkSrrFXnM2jm5PYDoiTBBMWCgA7FiEEUfF263VHMB6nKairXBt0oWUcX2gFAmTX6T4CGwMF
 CwkIBwICIgIGFQoJCAsCBBYCAwECHgcCF4AACgkQXBt0oWUcX2hbCQEAtru7kvM8hi8zo6z9ux2h
 K+B5xViKuo7Z8K3IXuK5ugwA+wUfKzomzdBPhfxDsqLcEziGRxoyx0Q3ld9aermBUccHtBxCasO2
 cm4gQmlkYXIgPG1lQHRoYW9kYW4uZGU+iJMEExYKADsCGwMFCwkIBwICIgIGFQoJCAsCBBYCAwEC
 HgcCF4AWIQRR8XbrdUcwHqcpqKtcG3ShZRxfaAUCZNf2FQAKCRBcG3ShZRxfaCzSAP4hZ7cSp0YN
 XYpcjHdsySh2MuBhhoPeLGXs+2kSiqBiOwD/TP8AgPEg/R+SI9GI9on7fBJJ0mp2IT8kZ2rhDOjg
 gA6IkwQTFgoAOxYhBFHxdut1RzAepymoq1wbdKFlHF9oBQJk1+ntAhsDBQsJCAcCAiICBhUKCQgL
 AgQWAgMBAh4HAheAAAoJEFwbdKFlHF9oBgwA/iQHwe0VL4Df4GGTYlNjMSHFlIkBmN4UfYGLYj3E
 TrOUAQC51M+M3cjsL8WHdpBz6VAo6df9d+rVwhQ9vQuFHqevArg4BGTX6T4SCisGAQQBl1UBBQEB
 B0Cbohc3JEfn005/cm0AOGjSsW1ZxAkgaoVNjbpqk4MgNAMBCAeIeAQYFgoAIBYhBFHxdut1RzAe
 pymoq1wbdKFlHF9oBQJk1+k+AhsMAAoJEFwbdKFlHF9ooHABAKGmrGBic/Vys3BBrOQiRB3Z7izO
 HwhqTRpAqFZtXS2nAQDZhp/5aYw1TZjTzkm1KVt9QiYnjd/MvxRE9iaY6x4mDbgzBGTX6T4WCSsG
 AQQB2kcPAQEHQAgRJq/tMcCCB2XyA5WZpu7GvpRx0m9IPRWazeqhOq7uiO8EGBYKACAWIQRR8Xbr
 dUcwHqcpqKtcG3ShZRxfaAUCZNf71AIbIgCBCRBcG3ShZRxfaHYgBBkWCgAdFiEEUfF263VHMB6n
 KairXBt0oWUcX2gFAmTX+9QACgkQXBt0oWUcX2jeSwD6AtWn0cuo8IF35YRo4o3cDRJnUfJnbvJy
 GxyCDThR+zYBAKG6/jdwmZkBQZKslnDAbMMd2WfiZZT5JW3IWC4EaKMO7HkBAKYPGZ3UbfkRvfFK
 S+pQ9CgtNfkSJQBtT1Ob7Y6nsacgAQCpyXN7yppmhW/oBgivITPy9Lkg+V4NK9WZYZCU9Q7LBA==
Date: Wed, 17 Jul 2024 07:52:14 +0300
Message-ID: <87o76wboxt.fsf@>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: 1.2 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  "J.P." <jp@HIDDEN> writes: > Hi =?UTF-8?Q?Bj=C3=B6rn,?= > > =?UTF-8?Q?Bj=C3=B6rn?= Bidar
    <bjorn.bidar@HIDDEN> writes: > >> How would IRv3 extension be implement
    as minor mode would work? >> For example deactivating them does not work
   without reconnecting. [...] 
 
 Content analysis details:   (1.2 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 -0.0 SPF_PASS               SPF: sender matches SPF record
  1.2 INVALID_MSGID          Message-Id is not valid, according to RFC 2822
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.2 (/)

"J.P." <jp@HIDDEN> writes:

> Hi Bj=C3=B6rn,
>
> Bj=C3=B6rn Bidar <bjorn.bidar@HIDDEN> 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.
>
> 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 I was taking the word minor-mode to literal. My concerns
came from the point that in theory a user could call the minor mode
function while they are connected and cause issues.
Thank you for explaining further.

Having each extension be module can be nice however it also increases
the complexity and overhead that comes with two many small modules.

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

I'm indeed a Circe user however I'm interested in working IRCv3 in Emacs
and was thinking on how to implement in Emacs in the past.
At the end of the day working IRCv3 is very important, more important
than which mode to use, although ERC is a bit messy compared to Circe
from my point of view. But that's off-topic anyhow.

Message received at control <at> debbugs.gnu.org:

Received: (at control) by debbugs.gnu.org; 12 Feb 2025 03:27:09 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Feb 11 22:27:09 2025
Received: from localhost ([127.0.0.1]:59949 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1ti3P3-0001P2-7y
	for submit <at> debbugs.gnu.org; Tue, 11 Feb 2025 22:27:09 -0500
Received: from mail-ed1-x529.google.com ([2a00:1450:4864:20::529]:60838)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
 (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>)
 id 1ti3P0-0001O9-HG
 for control <at> debbugs.gnu.org; Tue, 11 Feb 2025 22:27:07 -0500
Received: by mail-ed1-x529.google.com with SMTP id
 4fb4d7f45d1cf-5de727f7f05so5092981a12.1
 for <control <at> debbugs.gnu.org>; Tue, 11 Feb 2025 19:27:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20230601; t=1739330820; x=1739935620; darn=debbugs.gnu.org;
 h=to:subject:message-id:date:mime-version:from:from:to:cc:subject
 :date:message-id:reply-to;
 bh=lVdP/hV6ych8peldV/dLMHMoFPyCH1d5x3Ani0BUN4s=;
 b=J23omxMp6kViL3zr9Jcnxzt2xhU57ZtOLeq5ED1buQf73F+6G5qSTA7jFYDq3HmeK8
 ICZsDNEPh5KWe5erPl/ow4cXqp2l++eYVtcNp4vLDatusH6uD9FnuRlh1/Op7UI4qyRV
 iuPLP4dlTe7/b7HR16y27oowzgfd90EA08qJuWeZGiiOs/z/z+W+3D+t/eQw0k2/EvPz
 ziA7Qooa/a1IyTAc7gQAoEsMnjo7WVcLNHGAmeuQ0jDcwpaluFua7wm/gNnCaFSuR808
 iGQqz5K4x0jHsnQ0k1YMSUwRVrINdWXMby4Mutnu9eMAVHGakRuDKNVonzHc2VsogrP3
 f6Aw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20230601; t=1739330820; x=1739935620;
 h=to:subject:message-id:date:mime-version:from:x-gm-message-state
 :from:to:cc:subject:date:message-id:reply-to;
 bh=lVdP/hV6ych8peldV/dLMHMoFPyCH1d5x3Ani0BUN4s=;
 b=bh1RE/aq3cJI14j/5x8zxBXo+i6tSmT6EZJmDs+SNKIZCdkkr4y93Q7uYhjl/cJ5nO
 FdpXEkPERvZfZYdRrVweRVZ+jDQix4NTdKO7S6+hZBoOuXq18tj+S8yVKYVALDEWaZ2D
 d5ll8TqlEA6KvRPYTjsp/5haVsJpZKHu31L659urnN10SPaoYSvSpt1nfa0PCj6dPW3s
 XdL//tbHcMc9ygXjqAgO7jG6NvMjJpMLUTfIGo9/stNTQtatsKYzQdAU6XOhdqqrSNsG
 DP4/IuEaLEo6X7aJBba1FzptvqfMXIh1njOpVmpLsyNCweSQlD0/OGcmC6DA/N2QIXw8
 A/UA==
X-Gm-Message-State: AOJu0YyzdJLtC+10OPsQo5tk3xxL8OjjV7/ssxnccD6MjuGeeZTJScKO
 Sw8Xz7ujBiFpjkcu22HVZWvoP/7EUssiHEEgiP8DsqjJwIYMKt1HZ9NAWg3xsU5kkpKuio+F5ir
 2TRC1kz6t3F0MeebRiD63fnsgr1J7oWIfaOb2xA==
X-Gm-Gg: ASbGncscX7UhS2YO2TWqttT+pTjNqsCfAEdWSi7s6R89nx4WYqupXfHLXow4xSOeKe0
 TpmPfttsG0xZ0GzLmYm0GtyBkF4B9ZhffjqRte5TaIrpoH/4WTyfgbJh5qOPsTdmhuWpO7v3o
X-Google-Smtp-Source: AGHT+IGD7MeAuh307/MtX7WaDKBaWhhJff+t6U94WnIStifr7FXTXNTuPVAAty9h1zqel3aLQG4xWDZzrsEa/AqMFDw=
X-Received: by 2002:a05:6402:40d6:b0:5dc:8f03:bb25 with SMTP id
 4fb4d7f45d1cf-5deadd7802amr1566806a12.6.1739330820165; Tue, 11 Feb 2025
 19:27:00 -0800 (PST)
Received: from 753933720722 named unknown by gmailapi.google.com with
 HTTPREST; Tue, 11 Feb 2025 19:26:59 -0800
From: Stefan Kangas <stefankangas@HIDDEN>
MIME-Version: 1.0
Date: Tue, 11 Feb 2025 19:26:59 -0800
X-Gm-Features: AWEUYZnLc3ETRQk4e-zAYBhR6iy-d9Y-cBSx5q-j7cF3qLL7LYR7E41vT-ypJVg
Message-ID: <CADwFkmmEtNmK11TUGs7qw55wkSEV1kEVy2-RA9dS5yT6wj4zLQ@HIDDEN>
Subject: control message for bug #49860
To: control <at> debbugs.gnu.org
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: control
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)

severity 49860 wishlist
quit

Last modified: Wed, 12 Feb 2025 03:30:02 UTC

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