emacs-erc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: bug#70928: 30.0.50; ERC 5.6: Reuse query buffers for round-trip nick


From: J.P.
Subject: Re: bug#70928: 30.0.50; ERC 5.6: Reuse query buffers for round-trip nick changes in ERC
Date: Fri, 24 May 2024 20:13:30 -0700
User-agent: Gnus/5.13 (Gnus v5.13)

"J.P." <jp@neverwas.me> writes:

> While it's true we can't technically be certain revived queries are
> being piloted by the same individuals (at least not until ERC becomes
> account aware), enough folks have complained about this over the years
> that I think it's legitimate to disregard that uncertainty by default.

Looking into this further, I'm getting the unfortunate impression
there's a deeper, underlying problem afoot and that it's rooted in how
ERC updates participant tables in query buffers. In short: it's
haphazard and difficult to predict. And the end result is not only that
the party you're conversing with may not be reachable [1] but that the
manifest model itself doesn't regard their presence or absence as
particularly important enough to attend to consistently. And while it's
true that the behavior in question is rather ancient, I don't think it's
too deeply ingrained to resist addressing, mainly because the degree to
which it's unwieldy and unreliable makes it unlikely any serious third
party package would bank on it. [2]

Anyway, here's the breakdown of the current behavior:

  - Issuing a "/QUERY bob" won't create a user for bob in the new
    buffer's `erc-channel-members' table nor in the server-wide table,
    `erc-server-users', even if you share a channel with bob.

  - A /WHOIS creates a user for bob if they're online. But the same
    doesn't apply to a /WHO because ERC doesn't currently handle
    responses for non-channel targets.

  - A direct query message from a user will also add them.

  - If a user is joined to a channel and then quits, an existing entry
    will be removed from both tables. However, the same doesn't apply if
    they part all channels or are kicked.

  - If they (re)join a channel, the user *won't* be added to any
    existing query buffer's table, only the server-wide and channel
    tables.

  - An ERR_NOSUCHNICK (401) won't remove a user from any tables.

Here's how I imagine things working in a saner ERC:

  - A user's presence in a channel will dictate whether they exist in
    the server buffer's `erc-server-users' table.

  - Issuing a /query will create a user entry in the query buffer's
    `erc-channel-members' table if they exist in the server-wide table
    (meaning they're present in some channel).

  - Users parting or being kicked from a channel will see their data
    removed from all query tables (and the server table) if they're no
    longer joined to any other channels.

  - Insertion hooks running in query buffers can always expect to see a
    speaker's user's in its `erc-channel-members' table. If they're
    absent, a temporary user will be created for the duration of
    response handling.

  - A new, optional module will be added to mimic the effect of the
    Monitor extension and to serve as a fallback after ERC adds support
    (see bug#49860). When it's active, users in queries who aren't also
    in a channel will be periodically polled for and kept up to date.

  - A client's own user for its current nick will be absent in all query
    tables but present, once discovered, in the server-wide table for
    the remainder of the session.

The attached patches attempt to implement the proposed changes. Comments
welcome.

Thanks.


[1] This bookkeeping issue is particularly pertinent in regard to future
    support for the IRCv3 Monitor extension, whose express purpose is to
    offer a pub-sub service that keeps clients abreast of such changes
    as they happen on the server.

[2] Although, as usual, I think we should make the legacy behavior
    accessible by compat flag for a couple versions.

Attachment: 0000-v1-v2.diff
Description: Text Data

Attachment: 0001-5.6-Return-nil-from-more-ERC-response-handlers.patch
Description: Text Data

Attachment: 0002-5.6-Delete-original-speedbar-frame-in-erc-nickbar-mo.patch
Description: Text Data

Attachment: 0003-5.6-Reuse-old-query-buffers-for-round-trip-renicks-i.patch
Description: Text Data

Attachment: 0004-5.6-Mention-if-an-ERC-module-is-local-in-its-doc-str.patch
Description: Text Data

Attachment: 0005-5.6-Update-ERC-query-participants-on-JOIN-and-after-.patch
Description: Text Data

Attachment: 0006-5.6-Retain-client-s-own-user-in-erc-server-users.patch
Description: Text Data

Attachment: 0007-5.6-Add-ERC-module-querypoll-as-monitor-fallback.patch
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]