From: Amin Bandali <bandali@gnu.org>
To: "J.P." <jp@neverwas.me>
Cc: 29108@debbugs.gnu.org, emacs-erc@gnu.org
Subject: bug#29108: 25.3; ERC SASL support
Date: Tue, 29 Nov 2022 00:19:22 -0500 [thread overview]
Message-ID: <87iliyz6at.fsf__13729.9767973431$1669699236$gmane$org@gnu.org> (raw)
In-Reply-To: <87wn7jgkne.fsf@neverwas.me>
Hey!
J.P. writes:
[...]
>
> Thanks for bailing me out. (This was fast becoming the "Swingers
> answering machine" of bug threads.)
Ahaha no problem ;-)
>> All but one of them were committed without any additional changes; and
>> that one was 0006-Add-non-IRCv3-SASL-module-to-ERC.patch, where I just
>> added the missing entries for doc/misc/erc.texi and etc/ERC-NEWS to
>> the commit message.
>
> Oof. Thanks. I also forgot the bug number on
>
> 0007-Accept-functions-in-place-of-passwords-in-ERC.patch
>
> despite being kindly warned of that eventuality.
Ah, no worries; I missed that as well.
[...]
>
> Right. Too cryptic. I've adjusted things in the second patch but am
> happy to redo/revise, as always. (The first patch contains a bug fix.)
>
[...]
>
> Good call. I've attempted something like that in a separate "examples"
> section (2nd patch). I'm hesitant about the last, "multi-network"
> example, though. It sort of implies we're committing to supporting
> let-binding as a means of specifying per-network local-module options,
> going forward, which maybe also puts us on the hook for (eventually)
> providing a mechanism to make options bookkeeping easier for would-be
> local-module authors. OTOH, neither of those is as yet a realistic
> problem.
>
> Speaking of maintenance burdens, I think `erc-sasl-password' is too
> overloaded and unwieldy, particularly WRT the "non-nil symbol" form. And
> falling back on `:id' is redundant because `erc-auth-source-search'
> already does that. So, as penance for my ugly API design, I've attached
> a (third) patch that tries to corral some of the crazy by adding an
> optional auth-source query function to house the more nuanced
> functionality (for those actually wanting it) while sparing everyone
> else the needless complexity. (That's the idea, anyway.)
Thanks! Yeah, I don't really see supporting let-binds as too big of a
potential future burden. Worst case scenario, if/when local modules
are fully implemented and we and/or module authors find supporting
let-binding impractical, or there are clear advantages in not having
them, we could drop them in a major version bump (ERC 6.0 anyone?)
along with any other potential breaking change we might want to make.
Also your simplification sounds good. I pushed the v2 of all three
patches from your other reply to emacs-29. Thanks again!
>> Many thanks for all of your work on implementing and landing SASL
>> support for ERC, a feature that many ERC users (myself included)
>> have wished for and looked forward to seeing in ERC for years!
>>
>> -amin
>
> My pleasure! (Although I should've been quicker to admit that my older
> POC efforts weren't suitable for prime time without serious reworking.)
>
Cheers!
-a
next prev parent reply other threads:[~2022-11-29 5:19 UTC|newest]
Thread overview: 54+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-01 20:07 bug#29108: 25.3; ERC SASL support Alex Branham
2017-11-10 2:24 ` Noam Postavsky
2019-10-23 9:24 ` Lars Ingebrigtsen
2019-10-23 10:34 ` Alex Branham
2019-10-23 11:19 ` Lars Ingebrigtsen
2019-10-23 12:19 ` Stefan Kangas
2019-10-23 12:57 ` Noam Postavsky
2019-10-23 13:32 ` Stefan Kangas
2019-11-02 14:10 ` Stefan Kangas
2020-08-03 9:39 ` Lars Ingebrigtsen
2021-07-28 16:59 ` Ulrich Mueller
2021-07-28 17:21 ` Eli Zaretskii
2021-07-28 22:42 ` J.P.
2021-08-09 9:59 ` J.P.
2021-08-09 10:22 ` Ulrich Mueller
2021-08-09 10:56 ` J.P.
2021-08-09 12:39 ` J.P.
2021-08-23 13:47 ` J.P.
[not found] ` <87o89oi87g.fsf@neverwas.me>
2021-08-23 14:01 ` Lars Ingebrigtsen
[not found] ` <87zgt8s1jt.fsf@gnus.org>
2021-08-24 13:42 ` J.P.
2022-09-18 18:32 ` bug#29108: [J.P.] Add "non-IRCv3" SASL to ERC J.P.
2022-09-20 6:07 ` bug#29108: 25.3; ERC SASL support J.P.
[not found] ` <875yhifujk.fsf_-_@neverwas.me>
2022-09-21 13:13 ` J.P.
2022-10-14 3:05 ` J.P.
[not found] ` <878rljxfxs.fsf@neverwas.me>
2022-10-26 13:14 ` J.P.
[not found] ` <87k04m4th8.fsf@neverwas.me>
2022-11-08 14:10 ` J.P.
[not found] ` <87o7thlepf.fsf@neverwas.me>
2022-11-09 4:08 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-09 13:49 ` J.P.
[not found] ` <874jv81bn2.fsf@neverwas.me>
2022-11-09 17:50 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87iljoqaor.fsf@disroot.org>
2022-11-10 5:28 ` J.P.
[not found] ` <87sfirml89.fsf@neverwas.me>
2022-11-10 18:04 ` Adam Porter
2022-11-10 21:50 ` J.P.
2022-11-11 5:51 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-11-14 22:28 ` Adam Porter
[not found] ` <87sfiq7a3j.fsf@neverwas.me>
2022-11-11 1:25 ` Adam Porter
2022-11-11 5:56 ` Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <878rkighkn.fsf@disroot.org>
2022-11-14 22:29 ` Adam Porter
2022-11-13 15:36 ` J.P.
[not found] ` <87o7taoohd.fsf@neverwas.me>
2022-11-14 6:45 ` J.P.
2022-11-14 15:20 ` J.P.
[not found] ` <87y1sdk1fg.fsf@neverwas.me>
2022-11-16 14:51 ` J.P.
[not found] ` <875yfflzps.fsf@neverwas.me>
2022-11-17 6:30 ` J.P.
[not found] ` <877czuks8k.fsf@neverwas.me>
2022-11-17 15:28 ` J.P.
2022-11-18 2:26 ` J.P.
[not found] ` <878rk9576b.fsf@neverwas.me>
2022-11-18 14:06 ` J.P.
[not found] ` <87leo8z79j.fsf@neverwas.me>
2022-11-19 14:48 ` J.P.
[not found] ` <87tu2vroeh.fsf@neverwas.me>
2022-11-20 14:29 ` J.P.
[not found] ` <87wn7pog1l.fsf@neverwas.me>
2022-11-21 15:09 ` J.P.
[not found] ` <87y1s4mjj6.fsf@neverwas.me>
2022-11-22 14:01 ` J.P.
[not found] ` <87r0xvks03.fsf@neverwas.me>
2022-11-24 2:49 ` Amin Bandali
[not found] ` <87r0xtnk24.fsf@gnu.org>
2022-11-25 14:43 ` J.P.
[not found] ` <87wn7jgkne.fsf@neverwas.me>
2022-11-28 0:08 ` J.P.
2022-11-29 5:19 ` Amin Bandali [this message]
[not found] ` <87iliyz6at.fsf@gnu.org>
2022-11-29 15:05 ` J.P.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='87iliyz6at.fsf__13729.9767973431$1669699236$gmane$org@gnu.org' \
--to=bandali@gnu.org \
--cc=29108@debbugs.gnu.org \
--cc=emacs-erc@gnu.org \
--cc=jp@neverwas.me \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.