bug#57955: 29.0.50; Allow session-local ERC modules
"J.P." <[email protected]>
| Newsgroups | gmane.emacs.bugs,gmane.emacs.erc.general |
|---|---|
| Message-ID | <[email protected]> |
Hi Michael, Michael Albinus <[email protected]> writes: > Without knowing erc in general and your patch in detail: this sounds > like you could profit from connection-local variables. Did you check > this? Not quite yet (only superficially). At first glance, I'm not sure they're a perfect fit for this specific issue, but I'll definitely investigate further. Either way, I'm thinking they'd be a great solution (or inspiration) for an initiative we have on the horizon, namely, devising a means of applying user options in a more granular, contextual manner [1]. Also (if you happen to recall), a few of our recent exchanges ended with me pledging to follow through on one thing or another. And yet, most of those promises remain unfulfilled. Please know that I do plan on addressing them "eventually" and that I very much appreciate your help (and your patience). Thanks, J.P. [1] In case you're interested, by "context," I'm referring to various logical (somewhat overlapping) IRC boundaries, such as - message: event-local, i.e., source-wise and message-type-wise - channel: target-local - network: connection-local Basically, I'm looking for something akin to a "context variable" facility, except not so much for managing concurrency but instead for transparently stashing and restoring message-processing environments matched against headers and protocol state. More info: https://lists.gnu.org/archive/html/emacs-erc/2021-10/msg00003.html