procyberian/emacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

; Set explicit hook depth for erc-once-with-server-event

Browse source 
* lisp/erc/erc.el (erc-once-with-server-event): Set hook depth to -95.
* test/lisp/erc/erc-scenarios-base-association-nick.el: Improve
comment.
* test/lisp/erc/resources/erc-d/erc-d-tests.el
(erc-d--render-entries): Remove do-nothing assertion since its purpose
was unclear and likely dubious, as was incidentally highlighted by the
addition of a function not present on older Emacsen, which this test
still needs to run on.
This commit is contained in:
F. Jason Park 2024-04-25 05:09:50 -07:00
parent a156c98df0
commit 068e44ed75
3 changed files with 13 additions and 16 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
lisp/erc/erc.el
View file

@ -1595,7 +1595,7 @@ capabilities."
(remove-hook hook fun t))
(fmakunbound fun)
(funcall f proc parsed)))
(add-hook hook fun nil t)
(add-hook hook fun -95 t)
fun))
(defun erc--warn-once-before-connect (mode-var &rest args)

24
test/lisp/erc/erc-scenarios-base-association-nick.el
View file

@ -28,22 +28,22 @@
;; You register a new nick in a dedicated query buffer, disconnect,
;; and log back in, but your nick is not granted (maybe you just
;; turned off SASL). In any case, ERC obtains a backtick'd version.
;; turned off SASL). In any case, ERC obtains a backticked version.
;; You open a query buffer for NickServ, and ERC gives you the
;; existing one. And after you identify, all buffers retain their
;; names, although your net ID has changed internally.
;;
;; If ERC would've instead failed (or intentionally refused) to make
;; the association, you would've ended up with a new NickServ buffer
;; named after the new net ID as a suffix (based on the backtick'd
;; nick), for example, NickServ@foonet/tester`. And the original
;; (disconnected) NickServ buffer would've gotten suffixed with *its*
;; net-ID as well, e.g., NickServ@foonet/tester. And after
;; identifying, you would've seen ERC merge the two as well as their
;; server buffers. While this alternate behavior may arguably be a
;; more honest reflection of reality, it's also quite inconvenient.
;; For a clearer example, see the original version of this file
;; introduced by "Add user-oriented test scenarios for ERC".
;; If ERC had instead failed (or intentionally refused) to make the
;; association, you would find yourself with a new NickServ buffer
;; named with a suffix reflecting the new net ID (based on the
;; backticked nick), for example, NickServ@foonet/tester`. And the
;; original (disconnected) NickServ buffer would also receive a suffix
;; with *its* net-ID, e.g., NickServ@foonet/tester. Upon identifying
;; yourself, you'd see ERC merge both buffers along with their server
;; buffers. While this alternate behavior might more accurately
;; reflect reality, it introduces significant inconvenience. For a
;; clearer example, see the original version of this file introduced
;; by "Add user-oriented test scenarios for ERC".
(ert-deftest erc-scenarios-base-association-nick-bumped ()
:tags '(:expensive-test)

3
test/lisp/erc/resources/erc-d/erc-d-tests.el
View file

@ -367,9 +367,6 @@
(should (equal (funcall it) "foo3foo")))
(ert-info ("Exits clean")
(when (interpreted-function-p
(alist-get 'f (erc-d-dialog-vars dialog))) ; may be compiled
(should (aref (alist-get 'f (erc-d-dialog-vars dialog)) 2)))
(should-not (funcall it))
(should (equal (erc-d-dialog-vars dialog)
`((:a . 1)