[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#45872: 27.1; rcirc nick tracking

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]