xoddf2 writes: > J.P. writes: > >> [...] >> >> I've improved upon this further (v3 attached) by adding a housekeeping >> task to monitor the initial server process from creation. Such a move >> may be regrettable because it adds yet more complexity to the already >> dizzying auto-reconnect landscape. However, I couldn't find a suitable >> way to cover common process errors that aren't presented to the sentinel >> but still need to engage the reconnect logic. >> >> If this leads to a futile game of whack-a-mole, we'll obviously need to >> try a different approach. But if we do more-or-less build on what I've >> got so far, we'll definitely need to ensure it agrees with 27 and 28 >> before spending serious energy on refinement and tests. >> >> Thanks. > > Version 3 of the patch works, both with an otherwise unconfigured ERC > and with a full configuration connecting to my bouncer. > > I used this setting in both cases: > (setq erc-server-reconnect-function 'erc-server-delayed-check-reconnect) Really appreciate your trying this out. > The first 2 versions did not work at all. Right, and the last one still fails under various (hopefully less common) conditions, such as an outbound firewall dropping rather than rejecting packets. But the main problem (IMO) is unneeded complexity, and that stems from a fundamental design flaw in ERC: initializing new buffers and mode/module resources before creating connections, hence resorting to a probe to check for connectivity, which is roundabout and error prone. But until people become willing to accept the many breaking changes that a redesign would spell, I'm afraid we're stuck relying on these unfriendly contortions. As for next steps, I've polished up this patch some and have marked it for preliminary inclusion in what will become ERC 5.6. Thanks again.