1 files changed, 58 insertions, 0 deletions
diff --git a/test/lisp/erc/erc-scenarios-base-chan-modes.el b/test/lisp/erc/erc-scenarios-base-chan-modes.el
index 73fba65acf4..3183cd27370 100644
--- a/test/lisp/erc/erc-scenarios-base-chan-modes.el
+++ b/test/lisp/erc/erc-scenarios-base-chan-modes.el
@@ -81,4 +81,62 @@
       (should-not erc-channel-user-limit)
       (funcall expect 10 "<Chad> after"))))
 
+;; This asserts proper recognition of nonstandard prefixes advertised
+;; via the "PREFIX=" ISUPPORT parameter.  Note that without the IRCv3
+;; `multi-prefix' extension, we can't easily sync a user's channel
+;; membership status on receipt of a 352/353 by parsing the "flags"
+;; parameter because even though servers remember multiple prefixes,
+;; they only ever return the one with the highest rank.  For example,
+;; if on receipt of a 352, we were to "update" someone we believe to
+;; be @+ by changing them to a to @, we'd be guilty of willful
+;; munging.  And if they later lose that @, we'd then see them as null
+;; when in fact they're still +.  However, we *could* use a single
+;; degenerate prefix to "validate" an existing record to ensure
+;; correctness of our processing logic, but it's unclear how such a
+;; discrepancy ought to be handled beyond asking the user to file a
+;; bug.
+(ert-deftest erc-scenarios-base-chan-modes--speaker-status ()
+  :tags '(:expensive-test)
+  (erc-scenarios-common-with-cleanup
+      ((erc-scenarios-common-dialog "base/modes")
+       (erc-server-flood-penalty 0.1)
+       (dumb-server (erc-d-run "localhost" t 'speaker-status))
+       (erc-show-speaker-membership-status t)
+       (erc-autojoin-channels-alist '(("." "#chan")))
+       (expect (erc-d-t-make-expecter)))
+
+    (ert-info ("Connect to foonet")
+      (with-current-buffer (erc :server "127.0.0.1"
+                                :port (process-contact dumb-server :service)
+                                :nick "tester"
+                                :user "tester")
+        (funcall expect 5 "Here on foonet, we provide services")))
+
+    (with-current-buffer (erc-d-t-wait-for 5 (get-buffer "#chan"))
+
+      (ert-info ("Prefixes printed correctly in 353")
+        (funcall expect 10 "chan: +alice @fsbot -bob !foop"))
+
+      (ert-info ("Speakers honor option `erc-show-speaker-membership-status'")
+        (funcall expect 10 "<-bob> alice: Of that which hath")
+        (funcall expect 10 "<+alice> Hie you, make haste")
+        (funcall expect 10 "<!foop> hi"))
+
+      (ert-info ("Status conferred and rescinded")
+        (funcall expect 10 "*** foop (user@netadmin.example.net) has changed ")
+        (funcall expect 10 "mode for #chan to +v bob")
+        (funcall expect 10 "<+bob> alice: Fair as a text B")
+        (funcall expect 10 "<+alice> bob: Even as Apemantus")
+        (funcall expect 10 "mode for #chan to -v bob")
+        (funcall expect 10 "<-bob> alice: That's the way")
+        (funcall expect 10 "<+alice> Give it the beasts"))
+
+      ;; If it had instead overwritten it, our two states would be
+      ;; out of sync.  (See comment above.)
+      (ert-info ("/WHO output confirms server shadowed V status")
+        (erc-scenarios-common-say "/who #chan")
+        (funcall expect 10 '(: "bob" (+ " ") "H-"))
+        (funcall expect 10 "<-bob> alice: Remains in danger")
+        (erc-cmd-QUIT "")))))
+
 ;;; erc-scenarios-base-chan-modes.el ends here