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