bug#45872: 27.1; rcirc nick tracking

[Philip Kaludercic <philipk@posteo.net>]

[-- Attachment #1: Type: text/plain, Size: 1589 bytes --]

Ken Raeburn <raeburn@redhat.com> writes:

> On 7/24/21 10:56 AM, Philip Kaludercic wrote:
>
>> Ken Raeburn <raeburn@redhat.com> writes:
>
>> I forgot to update this ticket... I found that rcirc-buffer-alist
>> included a nick that had text properties set, and scanning the list
>> didn't find a match. I used advice-add to postprocess the list after
>> rcirc-handler-NICK using string-equal to work around it, and that
>> seems to do the job (as long as I can stay connected).
>>
>> I haven't checked in a while to see if it's been fixed. If not, a
>> better fix might be stripping out the text properties before putting a
>> nick into the list.
>> That shouldn't be an issue, but I wonder where the text properties come
>> from. Could you find out what text properties these were that were
>> confusing rcirc?
>
> It's setting font-lock-face to rcirc-other-nick. Oh... but I'm mixing
> this up with some other issue, I think. My apologies... the text
> properties are stored, but they're just a distraction. The access
> methods like assoc-string do ignore them.
>
> Looking back at the 27.1 code I'm still running, I don't think there's
> anything even trying to update rcirc-buffer-alist in response to
> NICK. Rename the buffer, yes, but not change the key it's listed
> under. If a buffer johnsmith@irc.server is initially stored in the
> alist under the key "johnsmith" (or #("johnsmith" 0 9 (font-lock-face
> (rcirc-other-nick)))) then it'll still be stored under that key even
> if the buffer is renamed to johnsmith|away@irc.server.

That is true, the following should fix that:


[-- Attachment #2: Type: text/plain, Size: 779 bytes --]

diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 60751c14e2..e5663d3fe6 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -3149,7 +3149,11 @@ rcirc-handler-NICK
 	(with-current-buffer chat-buffer
 	  (rcirc-print process sender "NICK" old-nick new-nick)
 	  (setq rcirc-target new-nick)
-	  (rename-buffer (rcirc-generate-new-buffer-name process new-nick)))))
+	  (rename-buffer (rcirc-generate-new-buffer-name process new-nick))))
+      (setf rcirc-buffer-alist
+            (cons (cons new-nick chat-buffer)
+                  (delq (assoc-string old-nick rcirc-buffer-alist t)
+                        rcirc-buffer-alist))))
     ;; remove old nick and add new one
     (with-rcirc-process-buffer process
       (let ((v (gethash old-nick rcirc-nick-table)))

[-- Attachment #3: Type: text/plain, Size: 845 bytes --]


Since the handler hasn't been changed since 2005, you should be able to
apply the change and see if it works.

> So one failure to rename the buffer is those cases where the key in
> rcirc-buffer-alist doesn't match, because a previous rename didn't
> update the key, and the handle hasn't been renamed back to its
> original value as stored in as a key in the alist.
>
> If the buffer rename back to remove the "|away" is missed, then I
> can't use the johnsmith|away@irc.server buffer to talk to
> johnsmith@irc.server any more, as I described in my original
> report. The handle info stored in the buffer is out of date. I can use
> "/msg johnsmith" and it'll create a new johnsmith@irc.server buffer,
> but another NICK message might try to rename that to
> johnsmith|away@irc.server again and would fail.
>
> Ken
>

-- 
	Philip Kaludercic