From: "J.P." <jp@neverwas.me>
To: 67220@debbugs.gnu.org
Cc: emacs-erc@gnu.org
Subject: bug#67220: 30.0.50; ERC 5.6: Prefer parameter-driven MODE processing in ERC
Date: Tue, 20 Feb 2024 17:14:39 -0800 [thread overview]
Message-ID: <87o7cabou8.fsf__17761.7989176483$1708478166$gmane$org@neverwas.me> (raw)
In-Reply-To: <871q9fhl8j.fsf@neverwas.me> (J. P.'s message of "Tue, 13 Feb 2024 17:45:32 -0800")
"J.P." <jp@neverwas.me> writes:
> It turns out a not entirely frivolous use case for abiding by that RFC
> draft and *not* distinguishing between the two forms has arisen.
> Basically, a server may choose to support no channels whatsoever for a
> subset of clients, limiting them to direct messages only. To accommodate
> this, ERC will need to interpret both "CHANTYPES" and "CHANTYPES=" as
> expressing such a policy instead of sticking with its current behavior
> of only doing so for the "=" form and treating "CHANTYPES" as equivalent
> to ${default/fallback} (and thus also to "-CHANTYPES", which is clearly
> wrong).
>
> I think it's worth correcting this in ERC 5.6. Proposed changes
> attached. (The first patch is unrelated.)
These changes now live on master as
3d87e343276 * Use modern fallback for channel name detection in ERC
25d15391f26 * Normalize ISUPPORT params with empty values in ERC
If anyone experiences new difficulties related to detecting channel
names, these are likely to blame.
next prev parent reply other threads:[~2024-02-21 1:14 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-16 2:13 bug#67220: 30.0.50; ERC 5.6: Prefer parameter-driven MODE processing in ERC J.P.
2023-11-17 18:30 ` J.P.
[not found] ` <87zfzcnsg1.fsf@neverwas.me>
2023-11-18 22:14 ` J.P.
[not found] ` <87il5yogj7.fsf@neverwas.me>
2023-11-21 14:30 ` J.P.
[not found] ` <87il5vfab9.fsf@neverwas.me>
2023-11-24 22:13 ` J.P.
2024-01-19 1:21 ` J.P.
[not found] ` <87mst2unhi.fsf@neverwas.me>
2024-01-25 21:45 ` J.P.
2024-02-14 1:45 ` J.P.
[not found] ` <871q9fhl8j.fsf@neverwas.me>
2024-02-21 1:14 ` J.P. [this message]
[not found] ` <87o7cabou8.fsf@neverwas.me>
2024-04-13 22:17 ` J.P.
[not found] ` <877ch09acj.fsf@neverwas.me>
2024-04-23 22:35 ` 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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='87o7cabou8.fsf__17761.7989176483$1708478166$gmane$org@neverwas.me' \
--to=jp@neverwas.me \
--cc=67220@debbugs.gnu.org \
--cc=emacs-erc@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).