bug#67220: 30.0.50; ERC 5.6: Prefer parameter-driven MODE processing in ERC

[J.P.]

This commit

  e69bd59ec59784b2f646e93355d4d63f41426cfc
  
  Honor arbitrary CHANTYPES in ERC
  
  * lisp/erc/erc.el (erc-channel-p): Favor "CHANTYPES" ISUPPORT item
  before falling back to well known prefixes.
  * test/lisp/erc/erc-tests.el (erc-channel-p): Add test.  Arbitrarily
  bundled with bug#60954.

introduced "smarter" handling of CHANTYPES but overlooked a subtlety
regarding how ERC interprets empty vs. missing ISUPPORT values. As
implied in a comment for the function `erc--parse-isupport-value',

  ;; https://tools.ietf.org/html/draft-brocklesby-irc-isupport-03#section-2
  ;;
  ;; > The server SHOULD send "X", not "X="; this is the normalized form.
  ;;
  ;; Note: for now, assume the server will only send non-empty values,

ERC punts on this. Indeed, it's always treated "X=" as having a value
and thus deserving of ("X" . "") in `erc-server-parameters', whereas
it's always seen "X" as more of a flag/switch with no associated value,
hence ("X").

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.)

Thanks.

0001-5.6-Ignore-the-TGT-LIST-parameter-in-erc-open.patch
Description: Text Data

0002-5.6-Normalize-ISUPPORT-params-with-empty-values-in-E.patch
Description: Text Data

0003-5.6-Use-modern-fallback-for-channel-name-detection-i.patch
Description: Text Data