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

Previous Next

Full log

View this message in rfc822 format

From: Ken Raeburn <raeburn <at> redhat.com>
To: Philip Kaludercic <philipk <at> posteo.net>, Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 45872 <at> debbugs.gnu.org
Subject: bug#45872: 27.1; rcirc nick tracking
Date: Fri, 23 Jul 2021 14:07:43 -0400

On 7/23/21 8:02 AM, Philip Kaludercic wrote:
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
>
>> Ken Raeburn <raeburn <at> redhat.com> writes:
>>
>>> One of my IRC contacts uses frequent nick changes to indicate away
>>> status, e.g., "johnsmith" when available, "johnsmith|away",
>>> "johnsmith|vacation", whatever. I've noticed that sometimes rcirc will
>>> fail to rename the buffer used for private messages between us, and so
>>> I'll wind up with a buffer "johnsmith|away" showing something along the
>>> lines of:
>>>
>>>    ... *** johnsmith NICK johnsmith|away
>>>    ... *** johnsmith|away NICK johnsmith
>>>
>>> but the buffer won't have been renamed back to "johnsmith@<server>",
> Do you have some idea in what cases the buffer is not renamed?  In
> principle, the NICK handler (rcirc-handler-NICK) should handle this
> case, but there might be issues if you disconnect and reconnect.

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.

Ken

Previous Next

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