xoddf2 writes: > J.P. writes: > >> Hi xoddf2, >> >> [...] For starters, we need to find a recipe, all the way from >> emacs -Q, that triggers the unwanted behavior. That way, we can dispense >> with any possible complications arising from your init.el and any >> third-party packages [...] > > After running emacs-snapshot -Q, I yanked the below Emacs Lisp code into > the *scratch* buffer, evaluated it, then ran M-x erc. I left server and > port at default (irc.libera.chat and 6667, respectively), set nick to > aoddf2, and left the server password blank. I then joined ##test. I > said something in that channel from my usual client, disconnected the VM > from the network in NetworkManager Applet, and then waited a few > minutes. I reconnected and then waited again. ERC had still not > reconnected. Thanks for the logs and the lowdown As with many things IRC, there are two senses of "connectivity" at play here with regard to automatic reconnections: network and application. In your initial report, underlying connectivity is present in some form because ERC reaches the "Logging in as" stage and attempts to send an application payload, though there's no telling how far it actually gets. In your followup, network connectivity is absent due to your "disconnecting the VM", something confirmed by the logs. While I think this simulation is worth exploring, we probably shouldn't assume it's failing in a meaningfully similar way to the real-life connection you're losing to your bouncer, at least not without trying the settings you laid out initially and also seeking a better understanding of what the NM applet is actually doing when you flip the switch. So to keep things sane, we should probably treat auto-reconnecting across connectivity gaps as a wishlist item and auto-reconnecting atop healthy connections as an existing, previously unreported bug. As for the new feature, I've attached a POC patch that you can try if you're willing (usage is self-explanatory, but feel free to modify or iterate as needed). As for the other issue, I think we're going to need some genuine session logs to really get anywhere. That is, we'll likely need you to enable logging and tracing during a real session with your bouncer over a hopefully not-too-prolonged period to capture an actual reconnect sequence failing. But hold off on that for another round unless you're feeling adventurous. Thanks again.