bug#45872: 27.1; rcirc nick tracking

[Ken Raeburn <raeburn@redhat.com>]

On 7/23/21 8:02 AM, Philip Kaludercic wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Ken Raeburn <raeburn@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