[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong plac
From: |
Eli Zaretskii |
Subject: |
bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place |
Date: |
Mon, 01 May 2023 15:10:34 +0300 |
> From: Philip Kaludercic <philipk@posteo.net>
> Cc: 59501@debbugs.gnu.org, "'Eli Zaretskii'" <eliz@gnu.org>
> Date: Mon, 01 May 2023 11:59:57 +0000
>
> Thuna <thuna.cing@gmail.com> writes:
>
> > I have occasionally had replies show before my messages, so I decided
> > to look into it. It looks like rcirc looks at the time of the
> > message, compares it to the `rcirc-time' text property of other
> > messages, and places it so that the property is properly ordered. >
> > ============================= Disregard this, the patch does not > fix
> > it. I decided to keep it in because the problem is still > possible,
> > but not it's not what's responsible for this specific > issue. The
> > issue with this is, because the recieved messages' precision can be
> > less than the sent messages' precision (`current-time' returns the
> > time down to milliseconds but servers may choose to only keep it down
> > to seconds), this causes some issues when a message is recieved after
> > a message was sent but still within the same second. >
> > ============================= An example of this, with the value of
> > the text property `rcirc-time' at the left of the message itself, is:
> >> (25469 29640 874652 270000) > 02:13 <thuna`> ,ping
> >> (25469 29641) > 02:13 <fsbot> ␕
> >> (25469 29642 502966 649000) > 02:13 <thuna`> ,ping
> >> (25469 29643) > 02:13 <fsbot> ␕
> >> (25469 29643 755653 540000) > 02:13 <thuna`> ,ping
> >> (25469 29644) > 02:13 <fsbot> ␕
> >> (25469 29645) > 02:13 <fsbot> ␕
> >> (25469 29645 103860 988000) > 02:13 <thuna`> ,ping
> >
> > As you can see, the response to the last ping arrived after the ping
> > itself, but because of the precision difference, rcirc sorted the
> > messages wrong.
> >
> > The issue was with `parse-time-string'. It (and by proxy
> > `parse-iso8601-time-string'), uses `iso8601-parse' with nil FORM,
> > resulting in the subsecond precision being thrown out. To fix this, I
> > added FORM arguments to those two functions as well.
>
> Sorry for missing this message, this patch looks like the right fix. I
> have recently been noticing issues related to this myself.
>
> Would it be OK to apply this to emacs-29?
Yes, but please fix the doc string to not use non-ASCII quotes.
Also, don't forget the Copyright-paperwork-exempt thingy when you
install.
Thanks.