unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place
@ 2022-11-23  3:37 Thuna
  2023-05-01 11:59 ` Philip Kaludercic
  0 siblings, 1 reply; 5+ messages in thread
From: Thuna @ 2022-11-23  3:37 UTC (permalink / raw)
  To: 59501

[-- Attachment #1: the patch --]
[-- Type: text/x-patch, Size: 3839 bytes --]

From 43bd8eb367f33a022fcc6554102ca38204296e7f Mon Sep 17 00:00:00 2001
From: Thuna <thuna.cing@gmail.com>
Date: Wed, 23 Nov 2022 04:14:36 +0100
Subject: [PATCH] rcirc: Fix messages printing in the wrong place

* lisp/net/rcirc.el (rcirc-send-message): Print the message before
sending it to the server.
(rcirc-print): Get the time with subsecond precision.
* lisp/calendar/parse-time.el (parse-time-string
parse-iso8601-time-string): Accept optional second FORM arguments,
with the same meaning as in `decode-time'.  Mention as such in the
docstring.
---
 lisp/calendar/parse-time.el | 16 ++++++++++------
 lisp/net/rcirc.el           |  6 +++---
 2 files changed, 13 insertions(+), 9 deletions(-)

diff --git a/lisp/calendar/parse-time.el b/lisp/calendar/parse-time.el
index f3ad513925..15713980cb 100644
--- a/lisp/calendar/parse-time.el
+++ b/lisp/calendar/parse-time.el
@@ -147,7 +147,7 @@ parse-time-rules
 ;;;###autoload(put 'parse-time-rules 'risky-local-variable t)
 
 ;;;###autoload
-(defun parse-time-string (string)
+(defun parse-time-string (string &optional form)
   "Parse the time in STRING into (SEC MIN HOUR DAY MON YEAR DOW DST TZ).
 STRING should be an ISO 8601 time string, e.g., \"2020-01-15T16:12:21-08:00\",
 or something resembling an RFC 822 (or later) date-time, e.g.,
@@ -156,9 +156,11 @@ parse-time-string
 return a \"likely\" value even for somewhat malformed strings.
 The values returned are identical to those of `decode-time', but
 any unknown values other than DST are returned as nil, and an
-unknown DST value is returned as -1."
+unknown DST value is returned as -1.
+
+See ‘decode-time’ for the meaning of FORM."
   (condition-case ()
-      (iso8601-parse string)
+      (iso8601-parse string form)
     (wrong-type-argument
      (let ((time (list nil nil nil nil nil nil nil -1 nil))
 	   (temp (parse-time-tokenize (downcase string))))
@@ -199,12 +201,14 @@ parse-time-string
 		     (setf (nth (pop slots) time) new-val))))))))
        time))))
 
-(defun parse-iso8601-time-string (date-string)
+(defun parse-iso8601-time-string (date-string &optional form)
   "Parse an ISO 8601 time string, such as \"2020-01-15T16:12:21-08:00\".
 Fall back on parsing something resembling an RFC 822 (or later) date-time.
 This function is like `parse-time-string' except that it returns
-a Lisp timestamp when successful."
-  (when-let ((time (parse-time-string date-string)))
+a Lisp timestamp when successful.
+
+See ‘decode-time’ for the meaning of FORM."
+  (when-let ((time (parse-time-string date-string form)))
     (encode-time time)))
 
 (provide 'parse-time)
diff --git a/lisp/net/rcirc.el b/lisp/net/rcirc.el
index 99b9888fda..1fdf41a35e 100644
--- a/lisp/net/rcirc.el
+++ b/lisp/net/rcirc.el
@@ -1233,9 +1233,9 @@ rcirc-send-message
   (let ((response (if noticep "NOTICE" "PRIVMSG")))
     (rcirc-get-buffer-create process target)
     (dolist (msg (rcirc-split-message message))
-      (rcirc-send-string process response target : msg)
       (unless silent
-        (rcirc-print process (rcirc-nick process) response target msg)))))
+        (rcirc-print process (rcirc-nick process) response target msg))
+      (rcirc-send-string process response target : msg))))
 
 (defvar-local rcirc-input-ring nil
   "Ring object for input.")
@@ -2034,7 +2034,7 @@ rcirc-print
                (not (string= sender (rcirc-nick process))))
     (let* ((buffer (rcirc-target-buffer process sender response target text))
            (time (if-let ((time (rcirc-get-tag "time")))
-                     (parse-iso8601-time-string time)
+                     (parse-iso8601-time-string time t)
                    (current-time)))
            (inhibit-read-only t))
       (with-current-buffer buffer
-- 
2.37.4


[-- Attachment #2: Type: text/plain, Size: 1830 bytes --]

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.

^ permalink raw reply related	[flat|nested] 5+ messages in thread

* bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place
  2022-11-23  3:37 bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place Thuna
@ 2023-05-01 11:59 ` Philip Kaludercic
  2023-05-01 12:10   ` Eli Zaretskii
  0 siblings, 1 reply; 5+ messages in thread
From: Philip Kaludercic @ 2023-05-01 11:59 UTC (permalink / raw)
  To: Thuna; +Cc: 59501, 'Eli Zaretskii'

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?





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place
  2023-05-01 11:59 ` Philip Kaludercic
@ 2023-05-01 12:10   ` Eli Zaretskii
  2023-05-01 12:16     ` Philip Kaludercic
  2023-05-04  8:07     ` Philip Kaludercic
  0 siblings, 2 replies; 5+ messages in thread
From: Eli Zaretskii @ 2023-05-01 12:10 UTC (permalink / raw)
  To: Philip Kaludercic; +Cc: 59501, thuna.cing

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





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place
  2023-05-01 12:10   ` Eli Zaretskii
@ 2023-05-01 12:16     ` Philip Kaludercic
  2023-05-04  8:07     ` Philip Kaludercic
  1 sibling, 0 replies; 5+ messages in thread
From: Philip Kaludercic @ 2023-05-01 12:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59501, thuna.cing

Eli Zaretskii <eliz@gnu.org> writes:

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

Done,

> Also, don't forget the Copyright-paperwork-exempt thingy when you
> install.

Will do.  Thuna: since you have a few other patches as well, would you
be interested in signing the CA so that there are no issues in the
future?

> Thanks.

-- 
Philip Kaludercic





^ permalink raw reply	[flat|nested] 5+ messages in thread

* bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place
  2023-05-01 12:10   ` Eli Zaretskii
  2023-05-01 12:16     ` Philip Kaludercic
@ 2023-05-04  8:07     ` Philip Kaludercic
  1 sibling, 0 replies; 5+ messages in thread
From: Philip Kaludercic @ 2023-05-04  8:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: 59501-done, thuna.cing

Eli Zaretskii <eliz@gnu.org> writes:

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

I've pushed the change, closing this report.





^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2023-05-04  8:07 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-23  3:37 bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place Thuna
2023-05-01 11:59 ` Philip Kaludercic
2023-05-01 12:10   ` Eli Zaretskii
2023-05-01 12:16     ` Philip Kaludercic
2023-05-04  8:07     ` Philip Kaludercic

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).