Re: 28.0.50; buffer-naming collisions involving bouncers in ERC

emacs-erc

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

Re: 28.0.50; buffer-naming collisions involving bouncers in ERC

From:	J.P.
Subject:	Re: 28.0.50; buffer-naming collisions involving bouncers in ERC
Date:	Thu, 11 Nov 2021 07:15:41 -0800
User-agent:	Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux)

Update #4

With the six-month anniversary of this bug around the corner, another
progress report seemed appropriate.


Administrative

- I've cleared the /cc list for these updates because everyone on it is
  already subscribed to emacs-erc anyway

- The version numbers for the fake ELPA packages introduced in update #3
  have changed to something like 5.4.1.48598.20211024.5

- The repo path for the patches has changed as well [1], but the
  download URL and the packages.el endpoint are still good [2]

- A checkpoint in the form of a random snapshot accompanies this post


Session IDs

  Mentioned in update #2, the addition of an :id param for entry-point
  commands `erc' and `erc-tls' remains in place. However, the local
  variable `erc-session-id' previously used to store it is no more.
  Instead, a composite type called `erc--sid' (currently a struct) takes
  care of this, and a local variable called `erc--session' holds the
  instances [3].

  At the moment, the base scheme for these sessions includes:

  1. a timestamp indicating when the session was created
  2. a human friendly ID, unique across all sessions

  And the default flavor [4] adds a couple more ingredients:

  3. a sequence of components from which to construct 2
  4. the length of the visible/active portion of 3


Server buffers

  The option `erc-rename-buffers' was implemented rather oddly and only
  operated on server buffers (which the doc string doesn't mention).
  Regardless, this bug's patch set moves to deprecate it and change its
  default value to t. But out of respect for tradition, the former
  default of nil will still be honored (provided an :id wasn't passed to
  `erc-open').

  As for anyone unlucky enough to have accidentally set this to the old
  default permanently: I suppose they'll have to settle for a more
  reliable version of the old <n>-based uniquification behavior (for as
  long as they ignore the deprecation warning, anyway). IOW, they too
  should be free of any buffer-association problems.


Buffer targets

  The variable `erc-default-recipients' and its various helpers can't be
  relied upon to produce consistent behavior if we're to respect the
  existing API [5]. The aspects in question have been around almost a
  quarter century, and even though I'd wager no one's ever used them, we
  likely can't go about "fixing" them now. Instead, I've provided what
  are hopefully more consistent alternatives for use in newer code. I've
  held off on weaving them into existing code, but doing so would free
  us from continually checking whether targets are channels or queries.

  These "alternatives" are currently just a local variable called
  `erc--buffer-target' and a struct called `erc--target'. The former
  holds instances of the latter, which is composed of:

  1. a string with the original name as received from the server
  2. a casemapped symbol for quick `eq' testing
  3. a boolean indicating whether this target is a channel
  4. a boolean indicating whether this target is a local channel

  I didn't add any public getters or setters here either but certainly
  can if needed. We could also make 3 and (maybe) 4 distinct subtypes,
  but I don't see any clear advantage in doing so.


Auth-source

  I've also attempted to unify auth-source lookups and make their
  results more predictable based on context. IMO, both the session
  parameters and the "type" of credentials sought (NickServ, certfp,
  PASS, etc.) really do matter and shouldn't be painted with the same
  brush. I'm not terribly enthused by my current approach, so please
  offer suggestions/alternatives/shade.


Auto-join

  A recent commit improved the situation here for the better [6], but it
  also altered the default behavior, which at least one person on Libera
  has pointed out. (Actually, with regard to the behavior in question,
  the commit merely restored an earlier practice of favoring announced
  names over dialed ones.) Anyway, in the spirit of minimizing churn, it
  may be more prudent to fall back on *always* matching dialed servers.
  I've recently added a patch to that effect as the first in this
  series, but it (along with most everything else) needs proper vetting.


Notes
~~~~~

[1] AFAIK, GitLab doesn't provide patch-file based interdiffing, so
    comparing iterations is a sad affair, but here's the updated path
    anyway:

    https://gitlab.com/jpneverwas/erc-tools/-/tree/master/bugs/48598/patches/wip

    (I also keep a standalone ERC repo with patches from another bug
    applied periodically. If doing the same for this bug would make
    staying abreast of changes easier, someone please say so.)

[2] https://jpneverwas.gitlab.io/erc-tools/48598/patches.tar.gz

[3] I've stuck with the term "session" to describe the kind of logical
    IRC connection that outlasts physical connections but (currently)
    dies along with Emacs. If someone has a better suggestion, I'm all
    ears. For the struct, I went with SID because it's shorter than ESID
    (effective) or LSID (logical), etc. Also, all new functions and
    variables (save for options) follow the internal double-hyphen
    convention. I figure we can always add getters/setters later as
    needed.

[4] As things stand, a session can either be "assigned" by the user or
    "derived" from session parameters available for discovery by MOTD's
    end (the logical connection boundary). For the default "derived"
    variant, IDs are rendered as paths, presumably from some hierarchy
    whose first two levels are the network and the normalized nick. The
    length (4) can normally only be incremented. When it is, the id (2)
    is recomputed. The same goes for whenever the components (3) change,
    like in the case of a re-NICK.

[5] I'm speaking specifically about the fact that this variable often
    holds more than one item and that these can be (but usually aren't)
    non-strings. These peculiar facets were present in the very first
    commit to the CVS repo back in 2001 and haven't changed since.

    https://gitlab.com/jpneverwas/og-erc/-/blame/master/erc.el#L4990

[6] https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=9bb8d90cdd

0001-Fall-back-on-dialed-server-names-in-erc-join.patch
Description: Text Data