From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Thuna Newsgroups: gmane.emacs.bugs Subject: bug#59501: [PATCH] rcirc: Issue with printing messages in the wrong place Date: Wed, 23 Nov 2022 04:37:37 +0100 Message-ID: <87cz9e8hoe.fsf@gmail.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25013"; mail-complaints-to="usenet@ciao.gmane.io" To: 59501@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 23 04:38:15 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oxgaV-0006Ju-2h for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 23 Nov 2022 04:38:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oxgaN-0003GD-P3; Tue, 22 Nov 2022 22:38:07 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxgaI-0003Ft-BM for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 22:38:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxgaI-0005d3-2p for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 22:38:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oxgaH-0008VL-P0 for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 22:38:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Thuna Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 23 Nov 2022 03:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 59501 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.166917467032672 (code B ref -1); Wed, 23 Nov 2022 03:38:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 23 Nov 2022 03:37:50 +0000 Original-Received: from localhost ([127.0.0.1]:53072 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxga6-0008Ut-2H for submit@debbugs.gnu.org; Tue, 22 Nov 2022 22:37:50 -0500 Original-Received: from lists.gnu.org ([209.51.188.17]:49262) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oxga3-0008Uj-1x for submit@debbugs.gnu.org; Tue, 22 Nov 2022 22:37:47 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oxga2-0003EL-SN for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 22:37:46 -0500 Original-Received: from mail-ej1-x634.google.com ([2a00:1450:4864:20::634]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oxga0-0005W2-R3 for bug-gnu-emacs@gnu.org; Tue, 22 Nov 2022 22:37:46 -0500 Original-Received: by mail-ej1-x634.google.com with SMTP id vv4so30716402ejc.2 for ; Tue, 22 Nov 2022 19:37:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:message-id:date:subject:to:from:from:to:cc:subject :date:message-id:reply-to; bh=OpaI/RBQOSqCZEEbZ+fcHHvaSREJNx1KlF7Hmht9KNg=; b=AnUDaYX68ezrJ00ACUmCGVgHjl7Cxu4CkvO2RBHbsfMDUWVy+UFaS+pFbZTAji8TYM SQlFAtZ3aNujriG4ZtYtoWT6aN+UA8wA5RH6dJMalPeA8l/sUtZ2cRcwSDpbbjuSR4DG pktUUDOBhvjaAAb72ASJXfrYWEanECKhAzwJ8G/WUAFdavOeCqIIJy0lAK2jFiLK4lWp LXdXzlqi91lyCUPawkefezwgsJzRfD8xJjylzW3Tw/6Gnwv6VHQJ7FUNYoTmUEtoXHCB htSVHPq4sKEQHfvv+uj8DrRTo1CNU6NXOCK7QZa/SQO6jR5Rsvq9cGN67ZWa6DN+BiiW vHkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=mime-version:message-id:date:subject:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=OpaI/RBQOSqCZEEbZ+fcHHvaSREJNx1KlF7Hmht9KNg=; b=uQ0iC1bj4lEWTRK2ghHPpQOtvyifBpXy6beZmwqTeEszLHSNuiPa58ttIdWq5TuB95 3AljouG4gex3AV4hUFtIR7IrxPAJjKI3kkr2Ic4AVxjNH3HMwpYU72czBaJ3aiDctPCY g/4uOuhtkyw4BOyoSTm90iXMkwiW/gHPNPePso/mHNbfCUfzOqBkN+fw831L2uXlwodH jp5bkgu0fj/dAtyOIsfEjzm0tArg60lFCaH7PQR5jqL7Jt4Z+fT95fr3UERbmRZOfDPM 0ysiftRLFzFbIZfpjWUupkxUVhpub3G/7mmoLKE3wUrqoPFelXnnkFXMDtYYCtVDNN8m jemQ== X-Gm-Message-State: ANoB5pmeNGAhDQU57EFn7adOeQprzaEdjePqPLs+Daxxc0Ot7eC02dVH OljMDQFnSUQGINik4Y3nAob0Qormykc= X-Google-Smtp-Source: AA0mqf5ddaDTd4OsX0KoP1P1Ap9gDTZUnCk06Url9ZmPpIeaugF1q52nXDesVMWQ3sAPtmytGGyJiQ== X-Received: by 2002:a17:906:5583:b0:78d:b3ef:656c with SMTP id y3-20020a170906558300b0078db3ef656cmr6779597ejp.627.1669174659349; Tue, 22 Nov 2022 19:37:39 -0800 (PST) Original-Received: from thuna (eduroam-092.unibocconi.it. [90.147.70.92]) by smtp.gmail.com with ESMTPSA id jt12-20020a170906ca0c00b007aec44edcfcsm6672264ejb.75.2022.11.22.19.37.38 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 22 Nov 2022 19:37:38 -0800 (PST) Received-SPF: pass client-ip=2a00:1450:4864:20::634; envelope-from=thuna.cing@gmail.com; helo=mail-ej1-x634.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:248704 Archived-At: --=-=-= Content-Type: text/x-patch; charset=utf-8 Content-Disposition: attachment; filename=0001-rcirc-Fix-messages-printing-in-the-wrong-place.patch Content-Transfer-Encoding: quoted-printable Content-Description: the patch >From 43bd8eb367f33a022fcc6554102ca38204296e7f Mon Sep 17 00:00:00 2001 From: Thuna 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) =20 ;;;###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:0= 0\", 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 =E2=80=98decode-time=E2=80=99 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)))) =20 -(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 =E2=80=98decode-time=E2=80=99 for the meaning of FORM." + (when-let ((time (parse-time-string date-string form))) (encode-time time))) =20 (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)))) =20 (defvar-local rcirc-input-ring nil "Ring object for input.") @@ -2034,7 +2034,7 @@ rcirc-print (not (string=3D sender (rcirc-nick process)))) (let* ((buffer (rcirc-target-buffer process sender response target tex= t)) (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 --=20 2.37.4 --=-=-= Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable I have occasionally had replies show before my messages, so I=20 decided to look into it. It looks like rcirc looks at the time=20 of the message, compares it to the `rcirc-time' text property of=20 other messages, and places it so that the property is properly=20 ordered.=20 =20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D Disregard this, the patch does not=20 > fix it. I decided to keep it in because the problem is still=20 > possible, but not it's not what's responsible for this specific=20 > issue.=20 The issue with this is, because the recieved messages' precision=20 can be less than the sent messages' precision (`current-time'=20 returns the time down to milliseconds but servers may choose to=20 only keep it down to seconds), this causes some issues when a=20 message is recieved after a message was sent but still within the=20 same second.=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=20 =20 An example of this, with the value of the text property=20 `rcirc-time' at the left of the message itself, is:=20 > (25469 29640 874652 270000) > 02:13 ,ping > (25469 29641) > 02:13 =E2=90=95 > (25469 29642 502966 649000) > 02:13 ,ping > (25469 29643) > 02:13 =E2=90=95 > (25469 29643 755653 540000) > 02:13 ,ping > (25469 29644) > 02:13 =E2=90=95 > (25469 29645) > 02:13 =E2=90=95 > (25469 29645 103860 988000) > 02:13 ,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. --=-=-=--