bug#45872: 27.1; rcirc nick tracking

[Ken Raeburn]

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