GNU bug report logs - #45872
27.1; rcirc nick tracking

Previous Next

Full log

Message #23 received at 45872 <at> debbugs.gnu.org (full text, mbox):

From: Ken Raeburn <raeburn <at> redhat.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 45872 <at> debbugs.gnu.org
Subject: Re: bug#45872: 27.1; rcirc nick tracking
Date: Mon, 26 Jul 2021 17:46:58 -0400

On 7/24/21 10:56 AM, Philip Kaludercic wrote:

> Ken Raeburn <raeburn <at> 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 <at> 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 <at> 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 <at> irc.server buffer to talk to johnsmith <at> 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 <at> irc.server buffer, but another NICK message might 
try to rename that to johnsmith|away <at> irc.server again and would fail.

Ken

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.