bug#45872: 27.1; rcirc nick tracking

[Philip Kaludercic]

Ken Raeburn <raeburn@redhat.com> writes:

> 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.

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?

> Ken
>

-- 
        Philip Kaludercic