Received: (at 69837) by debbugs.gnu.org; 6 Apr 2024 11:23:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 06 07:23:10 2024 Received: from localhost ([127.0.0.1]:38474 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rt48c-0008DY-Cg for submit <at> debbugs.gnu.org; Sat, 06 Apr 2024 07:23:10 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60552) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rt48a-0008Cd-1w for 69837 <at> debbugs.gnu.org; Sat, 06 Apr 2024 07:23:08 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rt48N-0002X2-WD; Sat, 06 Apr 2024 07:22:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=82UHasahNoHgiO5fXZhB0naZKBJRO9WuP7rUgzVDlDk=; b=BK5dgeQO1JrB uG6TwJgsM/cI9Gz4+ibyB3m1t7/rtGSy8HC+ISpGfg5a3hHO3lphuUWJ+BrtsBvLyaOhoN3uNfaKO BeAueY6Bp9nW/POG9++OqJOQO/1gRo2hhvb20DJG0NiXGIE6GxJJsUxtxVPU1al8ZwRspe1JDlC9V AeQTU4h0KotGFHdEKPrUpjyiZWTSuM3OD6mXJnBFf3bYgYZ6cqSYuCPfherk1pTz3Rfejc56kBo+k TafaXvTJ968ikxq+2hHIw4ygexlJ/WgopYTAJHOP9xxd9DGtOk3SAcFDYBabhodn6xW2bukWXX3Z3 /aY267HJ65oMaotvL879fg==; Date: Sat, 06 Apr 2024 14:22:53 +0300 Message-Id: <86frvy3fci.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Adam Porter <adam@HIDDEN> In-Reply-To: <8e2fb7a9-202e-45c9-ab2d-c2cd6395d590@HIDDEN> (message from Adam Porter on Thu, 21 Mar 2024 03:36:02 -0500) Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <867ci15q8l.fsf@HIDDEN> <525dbe6a-b673-4993-aace-169d09c6b8f0@HIDDEN> <86h6h34gj6.fsf@HIDDEN> <8e2fb7a9-202e-45c9-ab2d-c2cd6395d590@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: 69837 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Thu, 21 Mar 2024 03:36:02 -0500 > Cc: 69837 <at> debbugs.gnu.org > From: Adam Porter <adam@HIDDEN> > > FWIW, I did some hacking on listen.el attempting to further understand > and work around this problem, and I've found what seems to be a usable > workaround (for my purposes, anyway). > > The attached code defines a macro within which I call > `listen-queue--vtable-update-object' (which merely incorporates the fix > to `vtable-update-object' from bug#69664). As well, I wrap > `make-vtable' in a function that also sets two buffer-local variables to > the values of `frame-terminal' and `window-width' at the time of the > vtable's creation. The macro locally overrides the functions > `frame-terminal' and `window-width' to return those saved values. > > This allows the cache key to match unconditionally, which allows the > vtable's objects to be updated even when its buffer is not visible. > > In my limited testing, it seems to work fine. In my estimation, the > consequences of doing this in the worst case would be that the rows for > the updated objects might be drawn with some columns at a slightly > incorrect width, which is easily rectified by reverting the table > (usually bound to "g"). As well, that worst case (e.g. imagining a > vtable whose buffer might be initially displayed on one terminal/monitor > and later on another with different characteristics) would seem to be > relatively rare (so for my project, it seems like an obviously good > thing to do). > > For Emacs itself, I'm not sure what the best fix would be. I suppose a > workaround like this could be implemented as a fallback in case the > cache key misses; it would seem better to update the object potentially > sub-optimally than to error and not update it at all. > > Another possibility would be to ignore the frame-terminal and > window-width in the cache key altogether (i.e. so they would always be > assumed to be the same), but I'm sure that Lars did it this way for a > reason, so that would seem unwise. > > Let me know how you'd like me to proceed. I think you should install your workaround. I don't see how it could be worse than what we have now. P.S. And sorry for a long silence.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 21 Mar 2024 08:36:52 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Mar 21 04:36:52 2024 Received: from localhost ([127.0.0.1]:34235 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rnDuu-0003KQ-Ca for submit <at> debbugs.gnu.org; Thu, 21 Mar 2024 04:36:52 -0400 Received: from hedgehog.birch.relay.mailchannels.net ([23.83.209.81]:34945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <adam@HIDDEN>) id 1rnDuq-0003KD-NX for 69837 <at> debbugs.gnu.org; Thu, 21 Mar 2024 04:36:50 -0400 X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 90387760717; Thu, 21 Mar 2024 08:36:07 +0000 (UTC) Received: from pdx1-sub0-mail-a313.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 0BFCF76113A; Thu, 21 Mar 2024 08:36:04 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1711010164; a=rsa-sha256; cv=none; b=yj2a6M6ioJV3sbj8H3jvLXgMzu2ymal+HJFOJGR1q2ZVYsXXFOkQKlnTtdjzZUQaonbn8T 41/xNhWDAMXxxRh6SyRc1ok+hqunK6Es0H3VE8nOpgz4GFfNMbTrKvgXxGjPwRusSaoI5z Hl6CHatgA5wCQWVSnwurjHaWtyAM35rS9vNR1ezazYKnVFEb60k1ak1ZTeTeBDrp7hmqgF 6Z/tum0lfQE+94744qYx3UuUEXJkWsddqNcnJhxt0qDrZ7RPabmaFvtAJC/5fLdSomMGei JVFlx/6D4nyIzgD1aJXKjNGr0bY422DrsNCYYoaYG0iJIqhPke+0PJfipYTRcw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1711010164; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references:dkim-signature; bh=oie3e9rXs64Zbj6h313lMhBrxfgUWAnHpHfOo56/8A4=; b=EBswDzSCfqA23zVKNeWVFpWfEf7zP+hSG0/aOb7yq8rsT4veUJp6b8SiSGMMxahi7KUWI5 SgpJKHoMQ7lXBJSlBuKOp4aoZBiadmFLtigay0WlF7w2rmVTmqB5CxqE+ezyGriattzpMt WNe2SimYwAvZ7RggsHNVqm9AwrxHzoinM/Tt/TbzyB4/iO+vXOp1zzpJNEHtlPXM5PNiAv s2vpa4WBiDgIif1bUltZhCeUtlOje4OosO/6GIRl2nfinqO9+IcIu5q+04DmYspkhD9gZp EfdvkG6XWcWgMYv5TZ/RRfcEILBRNRG1z7CUaiUxkZRdy0eVP2aI4i72P523oA== ARC-Authentication-Results: i=1; rspamd-76c7995f89-pdfmt; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@HIDDEN X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@HIDDEN X-MailChannels-Auth-Id: dreamhost X-Whimsical-Shoe: 389bafb731a68e39_1711010167369_468376420 X-MC-Loop-Signature: 1711010167369:3584957367 X-MC-Ingress-Time: 1711010167369 Received: from pdx1-sub0-mail-a313.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.119.164.55 (trex/6.9.2); Thu, 21 Mar 2024 08:36:07 +0000 Received: from [10.43.2.138] (unknown [193.56.116.15]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@HIDDEN) by pdx1-sub0-mail-a313.dreamhost.com (Postfix) with ESMTPSA id 4V0f1b4Gq7z5h; Thu, 21 Mar 2024 01:36:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1711010163; bh=oie3e9rXs64Zbj6h313lMhBrxfgUWAnHpHfOo56/8A4=; h=Content-Type:Date:Subject:To:Cc:From; b=CNcgkFryDiKEjanZFdUlE39LIRfKXQ5pxI5dKMF9KsfitY1O1xXFVB/2SruR+bid+ kw97iaKb9UqOpofMUb3LKWf9Zl08xNohI32IadhdBXPGevgb60V1IJZolDegJfcPP/ clnLnzMwiyi2hs8DmrQbRmD5vMBAwMbXaXY0dwj2aZ0ZiTLk3PM+UHagTY6nhI60hN VeqUNfWhNcIWKRcTfhQC44czWRvlYVrTnGTuj1LdkQ196NTE1jbCA+hcqgKDz2zbSl FvE5Yf9AjvxTQRkmOSJwTwaj8EY9xTOFUgYZtOA9015M7DIJhIdeTS6CvyksETvF2y jD3065cFJ5n8A== Content-Type: multipart/mixed; boundary="------------NRnrhQQONKbAk4B0uuD49IjU" Message-ID: <8e2fb7a9-202e-45c9-ab2d-c2cd6395d590@HIDDEN> Date: Thu, 21 Mar 2024 03:36:02 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows To: Eli Zaretskii <eliz@HIDDEN> References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <867ci15q8l.fsf@HIDDEN> <525dbe6a-b673-4993-aace-169d09c6b8f0@HIDDEN> <86h6h34gj6.fsf@HIDDEN> Content-Language: en-US From: Adam Porter <adam@HIDDEN> In-Reply-To: <86h6h34gj6.fsf@HIDDEN> X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 69837 Cc: 69837 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.4 (/) This is a multi-part message in MIME format. --------------NRnrhQQONKbAk4B0uuD49IjU Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hi Eli, FWIW, I did some hacking on listen.el attempting to further understand and work around this problem, and I've found what seems to be a usable workaround (for my purposes, anyway). The attached code defines a macro within which I call `listen-queue--vtable-update-object' (which merely incorporates the fix to `vtable-update-object' from bug#69664). As well, I wrap `make-vtable' in a function that also sets two buffer-local variables to the values of `frame-terminal' and `window-width' at the time of the vtable's creation. The macro locally overrides the functions `frame-terminal' and `window-width' to return those saved values. This allows the cache key to match unconditionally, which allows the vtable's objects to be updated even when its buffer is not visible. In my limited testing, it seems to work fine. In my estimation, the consequences of doing this in the worst case would be that the rows for the updated objects might be drawn with some columns at a slightly incorrect width, which is easily rectified by reverting the table (usually bound to "g"). As well, that worst case (e.g. imagining a vtable whose buffer might be initially displayed on one terminal/monitor and later on another with different characteristics) would seem to be relatively rare (so for my project, it seems like an obviously good thing to do). For Emacs itself, I'm not sure what the best fix would be. I suppose a workaround like this could be implemented as a fallback in case the cache key misses; it would seem better to update the object potentially sub-optimally than to error and not update it at all. Another possibility would be to ignore the frame-terminal and window-width in the cache key altogether (i.e. so they would always be assumed to be the same), but I'm sure that Lars did it this way for a reason, so that would seem unwise. Let me know how you'd like me to proceed. Thanks, Adam --------------NRnrhQQONKbAk4B0uuD49IjU Content-Type: text/x-emacs-lisp; charset=UTF-8; name="example.el" Content-Disposition: attachment; filename="example.el" Content-Transfer-Encoding: base64 KGNsLWRlZm1hY3JvIGxpc3Rlbi13aXRoLXZ0YWJsZS1hdCAocG9zaXRpb24gJnJlc3QgYm9k eSkKICAiRklYTUU6IERvY3N0cmluZy4iCiAgKGRlY2xhcmUgKGluZGVudCBkZWZ1bikpCiAg KGxldCAoKHBvc2l0aW9u4bWlIChnZW5zeW0pKSkKICAgIGAobGV0ICgoLHBvc2l0aW9u4bWl ICxwb3NpdGlvbikpCiAgICAgICAoc2F2ZS1leGN1cnNpb24KICAgICAgICAgKGdvdG8tY2hh ciAscG9zaXRpb27htaUpCiAgICAgICAgIChjbC1sZXRmKiAoKChzeW1ib2wtZnVuY3Rpb24g J2ZyYW1lLXRlcm1pbmFsKQogICAgICAgICAgICAgICAgICAgICAobGFtYmRhICgmb3B0aW9u YWwgXykKICAgICAgICAgICAgICAgICAgICAgICBsaXN0ZW4tdnRhYmxlLWZyYW1lLXRlcm1p bmFsKSkKICAgICAgICAgICAgICAgICAgICAoKHN5bWJvbC1mdW5jdGlvbiAnd2luZG93LXdp ZHRoKQogICAgICAgICAgICAgICAgICAgICAobGFtYmRhICgmb3B0aW9uYWwgXyBfKQogICAg ICAgICAgICAgICAgICAgICAgIGxpc3Rlbi12dGFibGUtd2luZG93LXdpZHRoKSkKICAgICAg ICAgICAgICAgICAgICAodGFibGUgKHZ0YWJsZS1jdXJyZW50LXRhYmxlKSkKICAgICAgICAg ICAgICAgICAgICAoKHN5bWJvbC1mdW5jdGlvbiAndnRhYmxlLWN1cnJlbnQtdGFibGUpCiAg ICAgICAgICAgICAgICAgICAgIChsYW1iZGEgKCkKICAgICAgICAgICAgICAgICAgICAgICB0 YWJsZSkpCiAgICAgICAgICAgICAgICAgICAgKChzeW1ib2wtZnVuY3Rpb24gJ3Z0YWJsZS0t cmVjb21wdXRlLW51bWVyaWNhbCkKICAgICAgICAgICAgICAgICAgICAgIydsaXN0ZW4tcXVl dWUtLXZ0YWJsZS0tcmVjb21wdXRlLW51bWVyaWNhbCkpCiAgICAgICAgICAgLEBib2R5KSkp KSkKCihkZWZ2YXItbG9jYWwgbGlzdGVuLXZ0YWJsZS1mcmFtZS10ZXJtaW5hbCBuaWwpCihk ZWZ2YXItbG9jYWwgbGlzdGVuLXZ0YWJsZS13aW5kb3ctd2lkdGggbmlsKQoKKGRlZnVuIGxp c3Rlbi1tYWtlLXZ0YWJsZSAoJnJlc3QgYXJncykKICAoYXBwbHkgIydtYWtlLXZ0YWJsZSBh cmdzKQogIChzZXRxLWxvY2FsIGxpc3Rlbi12dGFibGUtZnJhbWUtdGVybWluYWwgKGZyYW1l LXRlcm1pbmFsKQogICAgICAgICAgICAgIGxpc3Rlbi12dGFibGUtd2luZG93LXdpZHRoICh3 aW5kb3ctd2lkdGgpKSkK --------------NRnrhQQONKbAk4B0uuD49IjU--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.
Received: (at 69837) by debbugs.gnu.org; 20 Mar 2024 01:42:46 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Mar 19 21:42:46 2024
Received: from localhost ([127.0.0.1]:44177 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1rmkyb-0006Hm-UD
for submit <at> debbugs.gnu.org; Tue, 19 Mar 2024 21:42:46 -0400
Received: from heron.birch.relay.mailchannels.net ([23.83.209.82]:50489)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <adam@HIDDEN>) id 1rmkyY-0006HU-T2
for 69837 <at> debbugs.gnu.org; Tue, 19 Mar 2024 21:42:43 -0400
X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN
Received: from relay.mailchannels.net (localhost [127.0.0.1])
by relay.mailchannels.net (Postfix) with ESMTP id 2478EC1A77;
Wed, 20 Mar 2024 01:42:02 +0000 (UTC)
Received: from pdx1-sub0-mail-a201.dreamhost.com (unknown [127.0.0.6])
(Authenticated sender: dreamhost)
by relay.mailchannels.net (Postfix) with ESMTPA id 6518EC1E78;
Wed, 20 Mar 2024 01:42:00 +0000 (UTC)
ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1710898920; a=rsa-sha256;
cv=none;
b=STjK/6m6rzxBZYOi7UzOftD1otmEPOVkJHOPiVERdwBLhsd5NWi2YGtj+fD8ABohFHR8AK
WPf7Hb8y5/+yRdTRuYQUtDwA9/9fuMqgB8BxshRlh88XbDsgzMuHvbrpt0ODJjoYLsCkCa
nr3h6IQNjNCv7KoZom/Go50PcedOPsX9B6aPHg9Fm0IsqPh5qqsesmO7vSV3KsibCx4Omc
vmHmzcq4Ea1Df8ZbtlAWcW/85Q4zasq5HQX9EJK+ThLCq5BXiuU5DFDRBSXUopJEOotSSG
Q08p7VkMe0QN1j4xuUry09yQ9M0aA+sFI8tCU2iqfGyWoDrFubPbMrQMdHj38g==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed;
d=mailchannels.net; s=arc-2022; t=1710898920;
h=from:from:reply-to:subject:subject:date:date:message-id:message-id:
to:to:cc:cc:mime-version:mime-version:content-type:content-type:
content-transfer-encoding:content-transfer-encoding:
in-reply-to:in-reply-to:references:references:dkim-signature;
bh=4WOEYIvG3xIWWrvWm++jr9r+RZbjYF6xBcfqp6HwFKg=;
b=JT44iMr2g481eg8z8UOQR7OAbUsel8JJ1ADNiTmawLE9X3N7YKJeon6qi56aDovobj8w3l
RVnXCOtLvB9+BIRlUAVMwJ1E2doXIZdC158oGEWM1yPA7AwuQ0kw5GJYbc5WipuKmAlmXo
bpChB95BSokXtOHjjky+9N0g0WIYJ8hQV85qr7m5OF7wjxkCOiTgv0NiupTHJ4a/5xRwjZ
0JGN0gT2+L5idE9HoGe0mD6juB/+Y9onNQn3EICYU4YBYn1Ax6MFLx+E9Kq6ncE1XXulHk
IwicxcmWGRXjz+ILRTR4xHPvfd+Gb1MFVJMi8p1leoKe/8BsNG58NHVatZRgTw==
ARC-Authentication-Results: i=1; rspamd-b46fcdc5-78dvb;
auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@HIDDEN
X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN
X-MC-Relay: Neutral
X-MailChannels-SenderId: dreamhost|x-authsender|adam@HIDDEN
X-MailChannels-Auth-Id: dreamhost
X-Duck-Lyrical: 369227170945e4d6_1710898920707_907974603
X-MC-Loop-Signature: 1710898920706:1446767056
X-MC-Ingress-Time: 1710898920706
Received: from pdx1-sub0-mail-a201.dreamhost.com (pop.dreamhost.com
[64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384)
by 100.116.254.156 (trex/6.9.2); Wed, 20 Mar 2024 01:42:00 +0000
Received: from [10.60.0.82] (unknown [193.56.117.222])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)
key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256)
(No client certificate requested)
(Authenticated sender: adam@HIDDEN)
by pdx1-sub0-mail-a201.dreamhost.com (Postfix) with ESMTPSA id 4TzrtH70DFz76;
Tue, 19 Mar 2024 18:41:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net;
s=dreamhost; t=1710898920;
bh=4WOEYIvG3xIWWrvWm++jr9r+RZbjYF6xBcfqp6HwFKg=;
h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding;
b=A2QeIFWVcd+gt+dAUgHBtgIjLKIBUunnwL2nT32SgqWFQ5vo99PmxsD5bmecNe7TQ
M6NRYb3z8KfDoMZoCoUmJ7VSfnEiycc0Nbw+1qQExMdZD5UDPCFpcgjWdKevfViahp
Xoc0vBQW12SqCoQ+4hvBtzT8pJ1mNX9sQtnT5qQd2pvlqvP5e7x/ksPnvPOWQbULY7
FLcL6PtlSBEUYGaOj5lim5KbKfqtuZCYxvZZWO8DrXcLqpbMw4bIXj3bDsbxs3UYUL
8m4hDB8Kvp0FzxowMmjViD0ORvPWEmd4O6yuFNAahvh+mFRWDaTeLSBx1y8iHjdmAN
tSZS0CUcbXQBA==
Message-ID: <9076aafc-d30c-4093-999c-f39ead5c43f9@HIDDEN>
Date: Tue, 19 Mar 2024 20:41:59 -0500
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible
windows
Content-Language: en-US
To: Eli Zaretskii <eliz@HIDDEN>
References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN>
<867ci15q8l.fsf@HIDDEN> <525dbe6a-b673-4993-aace-169d09c6b8f0@HIDDEN>
<86h6h34gj6.fsf@HIDDEN>
From: Adam Porter <adam@HIDDEN>
In-Reply-To: <86h6h34gj6.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Spam-Score: 0.6 (/)
X-Debbugs-Envelope-To: 69837
Cc: 69837 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.4 (/)
Hi Eli,
On 3/18/24 12:05, Eli Zaretskii wrote:
> I'm sorry, I'm not familiar with the design of vtable, so I will
> have to ask you possibly stupid questions. Apologies in advance.
I'm not very familiar with it, either, so I will have to give you
possibly stupid answers. :) But I will try to give accurate ones.
>> 1. vtable-update-object looks in the vtable's cache to find the
>> cached information about the representation of the object being
>> updated or replaced.
>
> Is this cache used just to speed up something (and so if the object
> is not in the cache, Emacs will just work harder to obtain the same
> information), or is finding the object in the cache absolutely
> necessary for working with the object?
It appears that the caching is integral to the rendering of vtables. In
`vtable-insert`, a comment explains:
;; We maintain a cache per screen/window width, so that we render
;; correctly if Emacs is open on two different screens (or the
;; user resizes the frame).
Then `vtable--ensure-cache` is called, which returns either an existing
cache or a newly computed one, and its return value is bound and used
when inserting the table's header line and when inserting each object's
representation. So it seems that the rendering of objects always uses
the cached values.
>> 2. In the process of doing that, it calls vtable--cache-key, which
>> returns a cons cell containing the frame-terminal and
>> window-width.
>
> If working with an object needs its window-width, does it mean
> objects are tightly coupled to their windows? If so, what happens
> when the user or Emacs resizes the window? are the cached objects
> recomputed to reflect that?
AFAICT, if a vtable's buffer's window is resized, nothing happens
automatically. But if the vtable is reverted (causing it to be
completely re-rendered), the window's width is taken into account
compared to the width of the table, affecting the vtable's header line,
and possibly the widths of some columns, depending on the table's
specification (see functions `vtable--compute-width` and
`vtable--compute-widths`). And if an individual object is updated, it
fails if the window width has changed, since the cache key misses.
I suppose the cache serves to sometimes help avoid re-rendering all the
objects in the table, and it uses the window-width as part of the cache
key because the table's buffer could be shown in multiple windows, each
of which could have a different width, requiring a different rendering
of the table (though I can't say I understand exactly how that could
work, since ISTM that rendering it for one window would display the same
rendering in the other window).
>> 3. So if the selected frame is on the same terminal, and the
>> selected window has the same width, as the ones when the vtable was
>> last generated, the cache key will match. This will allow
>> vtable-update-object to access the cached values and look for the
>> object in them.
>
> This again seems to imply that an object is tightly coupled to its
> window, and changes affecting the window must recompute the cached
> value. Right?
I think the way it works is roughly like this:
- An object's value(s) affect the width of the columns in its
representation's row.
- A row's columns' widths (or their total width) is compared with the
width of the window to determine how to display the last column (or the
last one visible in the window?).
- So the inverse holds as well: the window's width affects the display
of (at least one of) an object's representation's columns.
So if an object is being re-rendered, and the window's width is the
same, the cache can be used (which also seems to record the line number
at which the object is rendered, which saves from having to iterate
through the table to find the buffer line). Otherwise, if the window's
width has changed, the cache misses; and since `vtable-update-object`
does not handle this case (it just causes an error), the object is not
updated. This would require the application to handle the error and
revert the whole table instead.
I would suppose that, in that case, the last-used window width (if it
were known) could be used to update the object, assuming that the width
is either the same or "good enough," to avoid having to re-render the
whole table; if the worst that happened is that a column at the edge of
the table were a bit too wide or narrow compared to the ideal, that
would often be preferable to re-rendering the whole table. (In my case,
I could have 1,000-2,000 rows in the table, in which case I would prefer
to avoid re-rendering the whole thing; leaving the columns at their
existing width is no problem, especially if some of them are already
past the width of the window--and in my case, the table is always wider
than the window.)
> Are these keys (window-width, terminal, etc.) only used to look up
> the object, or are they needed for processing the objects as well?
The window's width appears to be integral to the rendering of the
objects, both individually and when inserting the whole table at once.
The terminal is used as part of the cache key, probably because a
different display could have a different resolution (DPI), which would
make calculations on one invalid on another (I'm sure you know more
about how that works than I do).
>>> If not, can you show a recipe, starting from "emacs -Q", that
>>> reproduces the problem, so we could study it in more detail?
>>
>> I had hoped to avoid writing that much code to demonstrate it. But
>> if the explanation above doesn't suffice, let me know and I will.
>
> It doesn't have to be code, it could be a (possibly long) list of
> instructions what to type.
In my case, I'm using vtable in my `listen` package on ELPA. If I, e.g.
add all the tracks in my music library to a `listen-queue`, which is
rendered with vtable, it's helpful to be able to update just one track's
representation at a time (so that the currently playing track can have
an arrow next to it, and the previously playing one can have its arrow
removed), because rendering the whole table can take a few seconds.
(Smaller tables, e.g. a hundred tracks or so, render very quickly.)
If a concrete demo is still needed, let me know and I can hack something up.
Thanks,
Adam
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Mar 2024 17:25:14 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Mon Mar 18 13:25:14 2024 Received: from localhost ([127.0.0.1]:34733 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rmGjZ-0006qD-Fk for submit <at> debbugs.gnu.org; Mon, 18 Mar 2024 13:25:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46072) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rmGVi-0006Dv-0Y for 69837 <at> debbugs.gnu.org; Mon, 18 Mar 2024 13:10:54 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rmGQP-00050j-CD; Mon, 18 Mar 2024 13:05:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=YZKX0PyxUFcsFkvBy3d4ONUAUNNqDaX+GLfwlNy/NwM=; b=Ovtzzf5XCL/C TBkab9g2l8GuDJdttMmQytCpTUZkZIKqK6N29pCVS/4cIiJrXEFnekZa4GbdRgRbBBj8LSfemZRC7 bS9PPbMrC8tzDymNTPNkWZfp/0Mj4Z8p/eUg3pOWK3c+1s8K3bpzkoh8wCXZZmNmgJEvw4ZCBwWKm 2t9Ax/7Hi90przBBUnDdr2XLYFDOYD7AZSqF+icLnbqrop1661kW1oqFsWY5jyESzum6YQfG4XfqL EhDrBJNAdDjUwsmBEziSAyzI6Iae+9KDRJxwpMuLdKyKA3UOFNv2y3fmVwAFjrh3o3K1TFuECJbd4 w4byaG+ylFhNwhel+uoqoQ==; Date: Mon, 18 Mar 2024 19:05:17 +0200 Message-Id: <86h6h34gj6.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Adam Porter <adam@HIDDEN> In-Reply-To: <525dbe6a-b673-4993-aace-169d09c6b8f0@HIDDEN> (message from Adam Porter on Sun, 17 Mar 2024 21:05:56 -0500) Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <867ci15q8l.fsf@HIDDEN> <525dbe6a-b673-4993-aace-169d09c6b8f0@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: 69837 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sun, 17 Mar 2024 21:05:56 -0500 > Cc: 69837 <at> debbugs.gnu.org > From: Adam Porter <adam@HIDDEN> > > Hi Eli, > > On 3/17/24 01:25, Eli Zaretskii wrote: > >> Date: Sat, 16 Mar 2024 22:41:37 -0500 > >> From: Adam Porter <adam@HIDDEN> > >> > >> I've discovered that `vtable-update-object' only works in buffers that > >> are in visible windows. When trying to update vtables in buffers that > >> aren't, the object being updated or replaced fails to be found in the > >> cache, apparently because `vtable--cache-key' uses `window-width' in its > >> value (so maybe if, when the vtable buffer is not visible, the selected > >> window happens to have the same width as the window in which the vtable > >> buffer was previously displayed, it will work by chance). > > > > Does using with-selected-window help to solve the issue? > > Sometimes, but not reliably, because it doesn't matter whether the > window is selected (and the buffer might not have a window, anyway). > I'll try to give a step-by-step explanation: I'm sorry, I'm not familiar with the design of vtable, so I will have to ask you possibly stupid questions. Apologies in advance. > 1. vtable-update-object looks in the vtable's cache to find the cached > information about the representation of the object being updated or > replaced. Is this cache used just to speed up something (and so if the object is not in the cache, Emacs will just work harder to obtain the same information), or is finding the object in the cache absolutely necessary for working with the object? > 2. In the process of doing that, it calls vtable--cache-key, which > returns a cons cell containing the frame-terminal and window-width. If working with an object needs its window-width, does it mean objects are tightly coupled to their windows? If so, what happens when the user or Emacs resizes the window? are the cached objects recomputed to reflect that? > 3. So if the selected frame is on the same terminal, and the selected > window has the same width, as the ones when the vtable was last > generated, the cache key will match. This will allow > vtable-update-object to access the cached values and look for the object > in them. This again seems to imply that an object is tightly coupled to its window, and changes affecting the window must recompute the cached value. Right? Are these keys (window-width, terminal, etc.) only used to look up the object, or are they needed for processing the objects as well? > > If not, can you show a recipe, starting from "emacs -Q", that > > reproduces the problem, so we could study it in more detail? > > I had hoped to avoid writing that much code to demonstrate it. But if > the explanation above doesn't suffice, let me know and I will. It doesn't have to be code, it could be a (possibly long) list of instructions what to type.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Mar 2024 02:06:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 17 22:06:40 2024 Received: from localhost ([127.0.0.1]:53541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rm2Od-0003P5-QK for submit <at> debbugs.gnu.org; Sun, 17 Mar 2024 22:06:40 -0400 Received: from dormouse.elm.relay.mailchannels.net ([23.83.212.50]:47343) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <adam@HIDDEN>) id 1rm2Ob-0003Ov-6e for 69837 <at> debbugs.gnu.org; Sun, 17 Mar 2024 22:06:38 -0400 X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 258C98410BC; Mon, 18 Mar 2024 02:05:58 +0000 (UTC) Received: from pdx1-sub0-mail-a313.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id BC12984147F; Mon, 18 Mar 2024 02:05:57 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1710727557; a=rsa-sha256; cv=none; b=lVc2EDPyPcuZGqmkcfbHMf5vW1VJ7mz9A+CpAqDrr6t4+nsJGYI4VbOb7feGEq5OY79nUT d7FOWybt8szWRK0oRFxlEw+sm+GTOggLAtzDgWTN+HX5x2fflrrQGukhS2ro7G3Rz9oGNx 9STr2qYQ7y/jnRIE4oJOyC/O5RwVlmWUo7OCbi0ECaqDwAkSpfkVfDL+FHv5FrZNlCkuAA EctCRglZ9iQsdSUsfPOisiUHIRpD+qFsocW8RRGQTLuCfmzUDP9VEYmjcP98GYhsEfIewh 0aFiVtMwn2KU6lFsq67jp57bOV0XQcjj03XSUTFDBWBVUey84hdIwtqM67KHtg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1710727557; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=6z/yOJ423feOtGwHvCPC4ZgGT+nVfho2j6BY+6Dbnwg=; b=oMoROOHjEsUrbJqiC0Z/NGEj0ilBaFYDnC2sFiT64sgDvX+so6D8O7Xf1wB6+r5nQSCWJt zi/EFq3e2kQTZEeA+IPV70128+jQTYO7p56sZN81YbktxPQmTAFB3S4BUiQdSUdAdfTxMG CnXYtf3TjMIwU6lGyTcXTusn/TrJQVlJxc94e8j79uEZaVkBEYNKHnadWL6dFB0HpTk96d cmaNRUQHRuu2USok/crABzJrOSUnVRMnfCgobQnbkJX/CYQZyR7Iu2fYtfS94Nk1tjK3Yg Dj1ZW8tfp0j+eS7+2ipR3qbgYV8r1RqW5dch77FF11XBPYhtUdJcPBz1z3kNPg== ARC-Authentication-Results: i=1; rspamd-b46fcdc5-ctgkd; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@HIDDEN X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@HIDDEN X-MailChannels-Auth-Id: dreamhost X-Reign-Illegal: 1ce814c47c7d6b43_1710727558006_377840532 X-MC-Loop-Signature: 1710727558006:3868035229 X-MC-Ingress-Time: 1710727558006 Received: from pdx1-sub0-mail-a313.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.99.130.139 (trex/6.9.2); Mon, 18 Mar 2024 02:05:58 +0000 Received: from [10.28.0.30] (unknown [45.131.192.18]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@HIDDEN) by pdx1-sub0-mail-a313.dreamhost.com (Postfix) with ESMTPSA id 4TydVs2DnMz7w; Sun, 17 Mar 2024 19:05:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1710727557; bh=6z/yOJ423feOtGwHvCPC4ZgGT+nVfho2j6BY+6Dbnwg=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=ceZWCDkT6wmxKqMkGQtg71ryzBq7CxJtPMG5NB2hAaMpQ9iUa7056xtlS6zFzSaV+ HBuDs5e4ajlL1iDWKvruXFiS6eaq63tfKtCCg8ZAISps0cyqBTqKW3TgN+qI8ZCuwB NY4lsXo5mGA7nzcLusJ/mdnI8xciff85LkvZsRqouVo+75EKGZsCCBzP4IGbmLPQ45 zEUH2mE6/fxBlHN2Q5CRb6jOwy4OQjCGiFQPasbSxO+9gRa7Hlhjl1e6pQx5fDlfFC 8jmMUwF/xpOp3UUUyPgXO/Z0s1vW5SDeEoz1XnSGDEQOCMTREK33Jmx8/XXfA20vt4 Il9JEd+WEddyA== Message-ID: <525dbe6a-b673-4993-aace-169d09c6b8f0@HIDDEN> Date: Sun, 17 Mar 2024 21:05:56 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows Content-Language: en-US To: Eli Zaretskii <eliz@HIDDEN> References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <867ci15q8l.fsf@HIDDEN> From: Adam Porter <adam@HIDDEN> In-Reply-To: <867ci15q8l.fsf@HIDDEN> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.6 (/) X-Debbugs-Envelope-To: 69837 Cc: 69837 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -0.4 (/) Hi Eli, On 3/17/24 01:25, Eli Zaretskii wrote: >> Date: Sat, 16 Mar 2024 22:41:37 -0500 >> From: Adam Porter <adam@HIDDEN> >> >> I've discovered that `vtable-update-object' only works in buffers that >> are in visible windows. When trying to update vtables in buffers that >> aren't, the object being updated or replaced fails to be found in the >> cache, apparently because `vtable--cache-key' uses `window-width' in its >> value (so maybe if, when the vtable buffer is not visible, the selected >> window happens to have the same width as the window in which the vtable >> buffer was previously displayed, it will work by chance). > > Does using with-selected-window help to solve the issue? Sometimes, but not reliably, because it doesn't matter whether the window is selected (and the buffer might not have a window, anyway). I'll try to give a step-by-step explanation: 1. vtable-update-object looks in the vtable's cache to find the cached information about the representation of the object being updated or replaced. 2. In the process of doing that, it calls vtable--cache-key, which returns a cons cell containing the frame-terminal and window-width. 3. So if the selected frame is on the same terminal, and the selected window has the same width, as the ones when the vtable was last generated, the cache key will match. This will allow vtable-update-object to access the cached values and look for the object in them. But if the terminal is different, or if the selected window's width is different, the cache key will be different, so vtable-update-object will fail, even when it could potentially succeed. In my case, the vtable's buffer is (or can be) in a window that is in a non-current tab (using tab-bar-mode) in the same frame, so its window is not visible. And so if the selected window in the current tab has the same width as the vtable's window, vtable-update-object may work. But if the widths don't match, it will fail. (I suppose it may also fail if the vtable's buffer's window is visible but has changed width since the vtable was generated, but I haven't tested that.) > If not, can you show a recipe, starting from "emacs -Q", that > reproduces the problem, so we could study it in more detail? I had hoped to avoid writing that much code to demonstrate it. But if the explanation above doesn't suffice, let me know and I will. Thanks, Adam
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 17 Mar 2024 06:26:37 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sun Mar 17 02:26:37 2024 Received: from localhost ([127.0.0.1]:57548 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rljyf-0006Oe-CV for submit <at> debbugs.gnu.org; Sun, 17 Mar 2024 02:26:37 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46624) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1rljyd-0006OS-S0 for 69837 <at> debbugs.gnu.org; Sun, 17 Mar 2024 02:26:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <eliz@HIDDEN>) id 1rljxx-0006rW-64; Sun, 17 Mar 2024 02:25:53 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=/ika7uO3UwgBy/bhKl5peLcPdM0BbiHpGcLw1ip7T84=; b=Ig5jOTWloFGc MK9vyMmfjxL5c6hnQK59Rp9gGuzeIZejGTrCUBv8HJO4MTELSOUxiQ7kFck3tcQRTp8rETj2u3clV OJLjtvvLyfPCnbqmkcHPjwXoZI6cGgT8UThgIQY5H0DJ1+TxBwX4g9Y6Z0ta3l4WH9MtXub6e6Le9 4PI3agXtCkKv68bNc2Km0LISKKto769wRuolN+QUP0LIPxz++RVGydIjUsZj25TLozgYPEfhXjBUy gKQdigdTNMvKM5/F3H7SKnzJiRAZb+iU71WbKde3kWQaCjqTBpz42CRfaFtu3nBG7TztmXem/acoe ScNyabeI7DH1d1ORDmaQ3g==; Date: Sun, 17 Mar 2024 08:25:46 +0200 Message-Id: <867ci15q8l.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Adam Porter <adam@HIDDEN> In-Reply-To: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> (message from Adam Porter on Sat, 16 Mar 2024 22:41:37 -0500) Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: 69837 <at> debbugs.gnu.org X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -3.3 (---) > Date: Sat, 16 Mar 2024 22:41:37 -0500 > From: Adam Porter <adam@HIDDEN> > > I've discovered that `vtable-update-object' only works in buffers that > are in visible windows. When trying to update vtables in buffers that > aren't, the object being updated or replaced fails to be found in the > cache, apparently because `vtable--cache-key' uses `window-width' in its > value (so maybe if, when the vtable buffer is not visible, the selected > window happens to have the same width as the window in which the vtable > buffer was previously displayed, it will work by chance). Does using with-selected-window help to solve the issue? If not, can you show a recipe, starting from "emacs -Q", that reproduces the problem, so we could study it in more detail?
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at submit) by debbugs.gnu.org; 17 Mar 2024 03:42:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Sat Mar 16 23:42:25 2024 Received: from localhost ([127.0.0.1]:57464 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1rlhPl-000131-6E for submit <at> debbugs.gnu.org; Sat, 16 Mar 2024 23:42:25 -0400 Received: from lists.gnu.org ([209.51.188.17]:53290) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <adam@HIDDEN>) id 1rlhPh-00012r-UO for submit <at> debbugs.gnu.org; Sat, 16 Mar 2024 23:42:22 -0400 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 <adam@HIDDEN>) id 1rlhP6-0002UG-7D for bug-gnu-emacs@HIDDEN; Sat, 16 Mar 2024 23:41:44 -0400 Received: from weasel.tulip.relay.mailchannels.net ([23.83.218.247]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <adam@HIDDEN>) id 1rlhP4-0002e0-Ht for bug-gnu-emacs@HIDDEN; Sat, 16 Mar 2024 23:41:43 -0400 X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id 24A6E76231D for <bug-gnu-emacs@HIDDEN>; Sun, 17 Mar 2024 03:41:39 +0000 (UTC) Received: from pdx1-sub0-mail-a288.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id C659D762375 for <bug-gnu-emacs@HIDDEN>; Sun, 17 Mar 2024 03:41:38 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1710646898; a=rsa-sha256; cv=none; b=ryL07L7k7YYWlrphg8c1BZTdEKXQ20NayTAp4OoIs/ydsbP2bGV6ixzveNhULcjTWWcX4v ljsCrfLa43XkVRIOgE5MAZuDPw3IX8FZoFVqMMk0TcmpL6SnEAKzrPrLCWavjwJPlMpufA q3hGUVtGyMFyWCq7dtEKSmEVJFNDUWHwM6tQtAs2V0LlAEj82jBgZDCYPpWsMpmfAsOePB XwwW8Fjnd+1f8AEKvQpWRTDg27JebYSfMWdjftO50sQQI59srEzE2ihO0chz1V1rtGRM/v E2owC35W0k9cPIGBoSeisa+k7ZfzRnuu8sZeqy+/qCHnO5yayOKelf48abeHYA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1710646898; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding:dkim-signature; bh=7Oae++3M3NZJijoAv7J78G/5dCiIUb5Y7tqz7ibnWpU=; b=fgW3D+6Kb5feS5EJgWPOIdizGrj3JW0qY0KOSFXWJbdje0CifE+8/RG0y0icSvyZEo8AH0 fQjCjTfNUgMzINWHntAMljKGtcQ2nUd74jrTy9S8c67PW+t6PHLSk0LBSqDk3+4pSw9Pj9 D0kUWnMVdv8JexKdRJRprZ23a7iMN0gaeXBTD4HkHYIZZ5zx7EF5/AzhDnRSNSfee2H2UQ 2vPxcpah04FBWJrxGah4NO2Z8sqMMwtV1Rj8C1ndXWCwgJOG0w/ar/ALECpD+mqEXdMRfx ifgvJQEn4Js4natckRD1oIMto8HeQYhMWYHl/yAKdwV+XpKh73/iLPklFwNYKQ== ARC-Authentication-Results: i=1; rspamd-76c7995f89-5f9ct; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@HIDDEN X-Sender-Id: dreamhost|x-authsender|adam@HIDDEN X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@HIDDEN X-MailChannels-Auth-Id: dreamhost X-Abiding-Reaction: 1d9fd58c42ad13fd_1710646899020_4180681564 X-MC-Loop-Signature: 1710646899020:72690220 X-MC-Ingress-Time: 1710646899019 Received: from pdx1-sub0-mail-a288.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.119.164.55 (trex/6.9.2); Sun, 17 Mar 2024 03:41:39 +0000 Received: from [10.28.0.130] (unknown [45.131.192.18]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: adam@HIDDEN) by pdx1-sub0-mail-a288.dreamhost.com (Postfix) with ESMTPSA id 4Ty3gk3Zl7zDd for <bug-gnu-emacs@HIDDEN>; Sat, 16 Mar 2024 20:41:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1710646898; bh=7Oae++3M3NZJijoAv7J78G/5dCiIUb5Y7tqz7ibnWpU=; h=Date:To:From:Subject:Content-Type:Content-Transfer-Encoding; b=laOZRMhp1UZC/89EeUymIxK4zbk5OlHuJ/a+YMPn63e3XEjVcg6V0rcZQqgjv8bIm mNQqpkROSkzV6nqQSnJwJ4cZUOT7Ei65+D2QtwTQmi90ls+iTlUxyyAqG+hErZBqku XN4r8BVR8XszFs/XC8nLk/VZyZn+x0/27StffqnMHgj8JdLw4dfd0+0xd1Fuj6b5BP flHkNEIwDneoEbur1IFAaCG7R+/B+ODfnokVVG8IZADqFmF+R0sttZ4Lrabmfa7APm +qlzRm90yvWv9l7lDu8375EeVZE9wSL4m+32Uj7Mnds+EbIGhjgF2/Q1PD2y0FfDVn AgWwzV6b6ogrA== Message-ID: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> Date: Sat, 16 Mar 2024 22:41:37 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-US To: bug-gnu-emacs@HIDDEN From: Adam Porter <adam@HIDDEN> Subject: 29.2; vtable-update-object only works in visible windows Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: neutral client-ip=23.83.218.247; envelope-from=adam@HIDDEN; helo=weasel.tulip.relay.mailchannels.net X-Spam_score_int: -12 X-Spam_score: -1.3 X-Spam_bar: - X-Spam_report: (-1.3 / 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.7 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit <at> debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: <debbugs-submit.debbugs.gnu.org> List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe> List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/> List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org> List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help> List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe> Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org> X-Spam-Score: -2.7 (--) Hi, I've discovered that `vtable-update-object' only works in buffers that are in visible windows. When trying to update vtables in buffers that aren't, the object being updated or replaced fails to be found in the cache, apparently because `vtable--cache-key' uses `window-width' in its value (so maybe if, when the vtable buffer is not visible, the selected window happens to have the same width as the window in which the vtable buffer was previously displayed, it will work by chance). In my case, the vtable is being updated in the background from a timer, so its buffer may or may not be visible. It's preferable to call `vtable-update-object' to update two rows in it rather than reverting the whole table, because it can be relatively slow to revert the whole table when it's large. I'm not sure of the best way to fix this. Maybe the vtable's last-used window width could be cached and used for the cache key in case its buffer is not visible. I guess that would risk displaying the vtable sub-optimally if the next time it's displayed its window width is different, but that might be worth it; in that case, the user could always revert the table if necessary. I'm willing to work on a patch for this, but I'd appreciate any guidance, since I'm far from an expert on this library, and there are many nuances when it comes to buffers, windows, their attributes, etc. Thanks, Adam
Adam Porter <adam@HIDDEN>:bug-gnu-emacs@HIDDEN.
Full text available.bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.