|
From: | Ken Raeburn |
Subject: | bug#45872: 27.1; rcirc nick tracking |
Date: | Mon, 26 Jul 2021 17:46:58 -0400 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0 |
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.
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
[Prev in Thread] | Current Thread | [Next in Thread] |