Ken Raeburn writes: > On 7/24/21 10:56 AM, Philip Kaludercic wrote: > >> Ken Raeburn 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: