Received: (at 69837) by debbugs.gnu.org; 19 Nov 2025 13:21:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Nov 19 08:21:04 2025 Received: from localhost ([127.0.0.1]:36946 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLi7M-00030n-3g for submit <at> debbugs.gnu.org; Wed, 19 Nov 2025 08:21:04 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:60122) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <eliz@HIDDEN>) id 1vLi7I-0002zZ-F5 for 69837 <at> debbugs.gnu.org; Wed, 19 Nov 2025 08:21:01 -0500 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 1vLi7C-0005hr-It; Wed, 19 Nov 2025 08:20:54 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=noiIslnoYT6SFVchCpvqnUYdFru4dv94RYOR7zJZe7M=; b=Csp+jVBQQlRWaFHlxNi0 qod704x7bilmgjf9MSccXVefoCgij+TpNeBPScObIELUSN5HmOx4+LtjX5D12oyTNoBw9ac6WJHy+ d6uWUPSOlcmgnh0MgFJgqis332LMZZiKzyUqBtYm8w2p4WvCN9cGoys7W9k0Tq5NpwgPA2/PPXxft SBpiqfD+pUmaFTP9pSNDy92WcXtsUcprn4WU/53lLyzNk1IS5AYg2nLuzNTT2DsTAuik0vxFDiivP uAeb0X+ZAYkbwMQ8R+Fnz8HfBxik+p1SpG6JPnEN9UPZIUrE2unep0VYVcaR8F5wTvrZhWjLCoKDq cVCdWpxUKcxlaQ==; Date: Wed, 19 Nov 2025 15:20:52 +0200 Message-Id: <86a50ijgzv.fsf@HIDDEN> From: Eli Zaretskii <eliz@HIDDEN> To: Spencer Baugh <sbaugh@HIDDEN> In-Reply-To: <ier1pluhprc.fsf@HIDDEN> (message from Spencer Baugh on Tue, 18 Nov 2025 18:42:15 -0500) Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el, [PATCH] Simplify vtable cache handling References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> <ier7bvngenv.fsf_-_@HIDDEN> <CAN+1HbqQn4H834+dhAy-0CE8Dzb7UYbpw+tVEQPcV=8YQZRCNg@HIDDEN> <ier4iqrgcvi.fsf@HIDDEN> <CAN+1HbpwwmgOgp45z93CTu=MeBb_4UnTdKMykQ8f8RqOgDDUaw@HIDDEN> <ier1pluhprc.fsf@HIDDEN> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: adam@HIDDEN, 69837 <at> debbugs.gnu.org, shipmints@HIDDEN, stefankangas@HIDDEN 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 (---) > From: Spencer Baugh <sbaugh@HIDDEN> > Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii > <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> > Date: Tue, 18 Nov 2025 18:42:15 -0500 > > Stéphane Marks <shipmints@HIDDEN> writes: > > > Alright let's install yours and keep going then. > > I would if I could :) I think we still need to find someone else who > will kindly install this patch. Is this the patch in https://debbugs.gnu.org/cgi/bugreport.cgi?bug=69837#64 ? If so, I can install it.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 19 Nov 2025 00:30:53 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 19:30:53 2025 Received: from localhost ([127.0.0.1]:60723 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLW60-0006Pt-Ew for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 19:30:53 -0500 Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]:51580) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vLW5x-0006PX-NL for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 19:30:50 -0500 Received: by mail-vs1-xe32.google.com with SMTP id ada2fe7eead31-5dfc3c7de2dso3436916137.3 for <69837 <at> debbugs.gnu.org>; Tue, 18 Nov 2025 16:30:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763512244; x=1764117044; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=cq8qEF06Im5MPFWdP39hjoyjNHNrkTqWDqH+Mb7j8r8=; b=MzlKFDnSwh4VtPhjYHXpPzuDaD/rD3cSfx0tOTpzpCPYZFhRZ7loxdt9Rpx5B6sU3P gN3vQqDqxWFrX77w4ylj78Bqk1qEYy7pfaf/ApBKNgUTnfSuzPPTUJaK7etaadL2h0jU PS8WXvxDe4pgb9FJQxRMFGu7omexL8aWWhjEInA3+Z/YkOTmnyTKvbMyhxOg87QM5QLc tV34sEzdWMDDmAOG91A6b5iyt+JaIdanURzFmVSLhPI+wxeoISNh+6iq+dDDD8eKPqda ZsehvDnEn5DVNQVpiWKDqduNi2VFCLJMebaiKnfmUQ2A7w8TobSpdpPq8KIXembfQvl4 ec3w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763512244; x=1764117044; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=cq8qEF06Im5MPFWdP39hjoyjNHNrkTqWDqH+Mb7j8r8=; b=Vd1pN5w6fXJNJ6KdJfcoJxZB1K5PwUdiVTUtEc65elC0Ul3+TPQPu28yVjx++X2vUk xJ0Yc5+g6wfqfCOVCK1f3VpwuC9yqI+PkNCMj5sUxHwNyk7l2dbM09wfGZusukzDBkX0 etA6qQeHh4W6b1gz9q9vUID6LAPwL7hM9/ojaUjaW26PzCyOjxHsJD9QN3l3JeXlycoD h3KSuIhltqunZZkZJUdABd3EuserV69/qBjnzGfCpKYLIO2QOJUdtpRDv0IglH8Ir/Gx cyQrEehcLZfTn/4VflHVGSHCNBWF/wXpuN8lwxFBkRnrccqMpI4NUmdjc1/MeckNtLTr ZHYw== X-Forwarded-Encrypted: i=1; AJvYcCW1JEVcHyfysDJd3u2kKhO//l/gSUBhPCkxjzie4MTqgHX8XpzWtIWSOvso0uCUHlkmCQapEg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxnuvVE1uTwtFpIyO07clC03iZgYvcSIJg/vgeEd/cRNLmOdGBI O5ITsYDA8OGn2xH52ztTRTKoYut7pcEdhMW83Sp2EVG+WQf0M2IgIYceOfZGY0/SrzUu1dwsy+p 4KBtbxJyoEF9bw8tgxQTeeqyWqYDzTsI= X-Gm-Gg: ASbGncuyr7bgWaSf4ntX5JWbtz8K0kpZuOjYXyaOb/WQXfecA+qfLX2ekUGhs+eCOdb PHr5Rf68kc0Pc+jY+xqI9S1frDQHMkhpI1ABteVsoseEJEVPR5ApKw1n3DbvxDqrSZaZbD+GFYS nqJFwcfkc7hiA09iXODH26RMO8XL2k1Qj+IlR6rx6xLcFiy/CC/u6tsyAd01ZWiEkvd7TWrO6UT 9auTrvWzv/3bpnzz1TgS5H6YpIULXZUV1fGbd7BB9ejIGKYIH9dkHT0eYdmoJ8WE9+QA2c= X-Google-Smtp-Source: AGHT+IEiYNlTC+VH/GJ3maznVNdxF10kqDNCut083Wf3UlzQFdyH5JNqtTT2qE/Iu1SQlHN/+2TvCyciBc7hcz2/Ix8= X-Received: by 2002:a05:6102:32cf:b0:5db:e6fa:f7fe with SMTP id ada2fe7eead31-5dfc5677108mr7133883137.24.1763512244073; Tue, 18 Nov 2025 16:30:44 -0800 (PST) MIME-Version: 1.0 References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> <ier7bvngenv.fsf_-_@HIDDEN> <CAN+1HbqQn4H834+dhAy-0CE8Dzb7UYbpw+tVEQPcV=8YQZRCNg@HIDDEN> <ier4iqrgcvi.fsf@HIDDEN> <CAN+1HbpwwmgOgp45z93CTu=MeBb_4UnTdKMykQ8f8RqOgDDUaw@HIDDEN> <ier1pluhprc.fsf@HIDDEN> In-Reply-To: <ier1pluhprc.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Tue, 18 Nov 2025 19:30:33 -0500 X-Gm-Features: AWmQ_bn_2YhlKvuOkgt80Hc00WLM3QugVmDQ0BLpQJUKlCCbPvtw0p0Ret2d9xA Message-ID: <CAN+1Hbo=rsrmVAG_ZgdXENR9hHoTBnjtvpgE59uFtvHCGe4HiQ@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el, [PATCH] Simplify vtable cache handling To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000dd76f00643e7b0bb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --000000000000dd76f00643e7b0bb Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2025 at 18:42 Spencer Baugh <sbaugh@HIDDEN> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Tue, Nov 18, 2025 at 18:05 Spencer Baugh <sbaugh@HIDDEN> > wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <sbaugh@janest= reet.com> > wrote: > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh < > sbaugh@HIDDEN> wrote: > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > > > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh < > sbaugh@HIDDEN> wrote: > > > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > > > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh < > sbaugh@HIDDEN> wrote: > > > > > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > Alright! Hand becoming sufficiently usable! Sorry for th= e > delay. > > > > > > > > > > > > > > Spencer, can you take a quick look at the patch you > provided via > > > > > > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > > > > > > it does not pass the vtable tests (which we will beef up= , > and get rid of the typo in the first test name). > > > > > > > > > > > > Thanks for checking, apologies about that, it was just an > error > > > > > > introduced when I ported the patch forward from emacs-30 > (which is what > > > > > > we use at my site). > > > > > > > > > > > > Fixed it, this version should be correct. > > > > > > > > > > > > Thank you. Tests pass. > > > > > > > > > > > > I think we should eliminate the slot -cache and get rid of > the cache key entirely (the slot being superseded by the > > > > > vtable-cache > > > > > > text property). Each time the cache needs to be refreshed, > the user runs vtable-revert which repopulates the now > > sole > > > > > cache. > > > > > > Leaving the remnants of the old mechanism in place will > confuse people. I also think we should rename > > current-cache > > > to > > > > > just > > > > > > cache. If agreed, I'll finish this patch by removing the > remnants. > > > > > > > > > > Feel free to try it; please send your patch as a diff on top > of mine so > > > > > I can review it. > > > > > > > > > > Note that we still need something like the cache key just to > know when > > > > > we need to invalidate the cache. And when we revert the > vtable we > > > > > currently grab the cache out of the slot -cache; we'll need t= o > change > > > > > the code to grab the cache out of the text properties before > we erase > > > > > the previously inserted table. > > > > > > > > > > I don't think explicit cache invalidation is needed. If the > displays a vtable in another window of a different size, or > > resizes > > > > the > > > > > current window, they have to vtable-revert anyway, right? > > > > > > > > Yes. vtable-revert calls vtable-insert which doesn't clear the > cache if > > > > the cache key is the same, so it doesn't recompute the cached > data. > > > > > > > > Here's a simplified cache patch layered on top of yours. If you > agree, I think we should squash them. > > > > > > This causes us to recompute the cache every time we call > vtable-revert, > > > instead of reusing it. Isn't that expensive? > > > > > > What I'd like to do is introduce more thoughtful cache invalidation > logic as I'd proposed in the larger patch. The logic there > > was > > > complicated by the multi-cache infrastructure which is now gone. > I'll introduce that logic in another patch as I go through > > all the > > > other stuff I have accumulated to add. > > > > > > If we can agree on this patch, let's get it going and continue along= ? > > > > If you're going to be introducing more thoughtful cache invalidation > > logic, then please just post a patch that contains that. > > > > As it stands, the patch you just posted will cause a performance > > regression and so therefore should not be installed. > > > > Alright let's install yours and keep going then. > > I would if I could :) I think we still need to find someone else who > will kindly install this patch. I was hoping as part of volunteering to be the vtable maintainer that I'd be able to and agree to touch only that file (and documentation). > > --000000000000dd76f00643e7b0bb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><span style=3D"font-family:-apple-system,sans-serif">On T= ue, Nov 18, 2025 at 18:42 Spencer Baugh <<a href=3D"mailto:sbaugh@janest= reet.com">sbaugh@HIDDEN</a>> wrote:</span><br></div><div dir=3D"= auto"><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D= "gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding= -left:1ex">St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" t= arget=3D"_blank">shipmints@HIDDEN</a>> writes:<br> <br> > On Tue, Nov 18, 2025 at 18:05 Spencer Baugh <<a href=3D"mailto:sbau= gh@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</a>> wrote:<b= r> ><br> >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" t= arget=3D"_blank">shipmints@HIDDEN</a>> writes:<br> ><br> >=C2=A0 > On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <<= a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@janestreet= .com</a>> wrote:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@g= mail.com" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer = Baugh <<a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh= @janestreet.com</a>> wrote:<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:= shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<= br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 > On Tue, Nov 18, 2025 at 3:40=E2=80=AF= PM Spencer Baugh <<a href=3D"mailto:sbaugh@HIDDEN" target=3D"_bl= ank">sbaugh@HIDDEN</a>> wrote:<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href= =3D"mailto:shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>&g= t; writes:<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > On Mon, Nov 10, 2025 at 6:= 00=E2=80=AFPM Spencer Baugh <<a href=3D"mailto:sbaugh@HIDDEN" ta= rget=3D"_blank">sbaugh@HIDDEN</a>> wrote:<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 St=C3=A9phane Marks = <<a href=3D"mailto:shipmints@HIDDEN" target=3D"_blank">shipmints@gmai= l.com</a>> writes:<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Alright! Hand b= ecoming sufficiently usable! Sorry for the delay.<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Spencer, can yo= u take a quick look at the patch you provided via<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 0001-Fix-implicit-us= age-of-the-current-window-width-in-vt.patch<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > it does not pas= s the vtable tests (which we will beef up, and get rid of the typo in the f= irst test name).<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 Thanks for checking,= apologies about that, it was just an error<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 introduced when I po= rted the patch forward from emacs-30 (which is what<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 we use at my site).<= br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 Fixed it, this versi= on should be correct.<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Thank you.=C2=A0 Tests pas= s.<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > I think we should eliminat= e the slot -cache and get rid of the cache key entirely (the slot being sup= erseded by the<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 vtable-cache<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > text property).=C2=A0 Each= time the cache needs to be refreshed, the user runs vtable-revert which re= populates the now<br> >=C2=A0 sole<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 cache. <br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Leaving the remnants of th= e old mechanism in place will confuse people.=C2=A0 I also think we should = rename<br> >=C2=A0 current-cache<br> >=C2=A0 >=C2=A0 to<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 just<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > cache.=C2=A0 If agreed, I&= #39;ll finish this patch by removing the remnants.<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 Feel free to try it; please sen= d your patch as a diff on top of mine so<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 I can review it.<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 Note that we still need somethi= ng like the cache key just to know when<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 we need to invalidate the cache= .=C2=A0 And when we revert the vtable we<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 currently grab the cache out of= the slot -cache; we'll need to change<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 the code to grab the cache out = of the text properties before we erase<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 the previously inserted table.<= br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 > I don't think explicit cache inva= lidation is needed.=C2=A0 If the displays a vtable in another window of a d= ifferent size, or<br> >=C2=A0 resizes<br> >=C2=A0 >=C2=A0 >=C2=A0 the<br> >=C2=A0 >=C2=A0 >=C2=A0 > current window, they have to vtable-r= evert anyway, right?<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 Yes.=C2=A0 vtable-revert calls vtable-inse= rt which doesn't clear the cache if<br> >=C2=A0 >=C2=A0 >=C2=A0 the cache key is the same, so it doesn'= ;t recompute the cached data.<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 > Here's a simplified cache patch layered on t= op of yours.=C2=A0 If you agree, I think we should squash them.<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 This causes us to recompute the cache every time we c= all vtable-revert,<br> >=C2=A0 >=C2=A0 instead of reusing it.=C2=A0 Isn't that expensive= ?<br> >=C2=A0 ><br> >=C2=A0 > What I'd like to do is introduce more thoughtful cache = invalidation logic as I'd proposed in the larger patch.=C2=A0 The logic= there<br> >=C2=A0 was<br> >=C2=A0 > complicated by the multi-cache infrastructure which is now = gone.=C2=A0 I'll introduce that logic in another patch as I go through<= br> >=C2=A0 all the<br> >=C2=A0 > other stuff I have accumulated to add.<br> >=C2=A0 ><br> >=C2=A0 > If we can agree on this patch, let's get it going and c= ontinue along?<br> ><br> >=C2=A0 If you're going to be introducing more thoughtful cache inva= lidation<br> >=C2=A0 logic, then please just post a patch that contains that.<br> ><br> >=C2=A0 As it stands, the patch you just posted will cause a performance= <br> >=C2=A0 regression and so therefore should not be installed.<br> ><br> > Alright let's install yours and keep going then. <br> <br> I would if I could :)=C2=A0 I think we still need to find someone else who<= br> will kindly install this patch.</blockquote><div dir=3D"auto"><br></div><di= v dir=3D"auto">I was hoping as part of volunteering to be the vtable mainta= iner that I'd be able to and agree to touch only that file (and documen= tation).=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0= .8ex;border-left:1px #ccc solid;padding-left:1ex" dir=3D"auto"><br> </blockquote></div></div> --000000000000dd76f00643e7b0bb--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 23:42:23 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 18:42:23 2025 Received: from localhost ([127.0.0.1]:60534 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLVL4-0003fs-Iu for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:42:23 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60931) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vLVL2-0003ff-Ph for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:42:21 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el, [PATCH] Simplify vtable cache handling In-Reply-To: <CAN+1HbpwwmgOgp45z93CTu=MeBb_4UnTdKMykQ8f8RqOgDDUaw@HIDDEN> (=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Tue, 18 Nov 2025 18:40:00 -0500") References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> <ier7bvngenv.fsf_-_@HIDDEN> <CAN+1HbqQn4H834+dhAy-0CE8Dzb7UYbpw+tVEQPcV=8YQZRCNg@HIDDEN> <ier4iqrgcvi.fsf@HIDDEN> <CAN+1HbpwwmgOgp45z93CTu=MeBb_4UnTdKMykQ8f8RqOgDDUaw@HIDDEN> Date: Tue, 18 Nov 2025 18:42:15 -0500 Message-ID: <ier1pluhprc.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1763509335; bh=6p49DkrUjgg9URaLIWnvguHo/i3xYazRP7NF1rzDylc=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=zqsUQeghsx4MZiYfVquqWGvGAdd9EdOyF41gTsDGI2MfiHK4wi2RYSaOJgNNhwYQ9 02e2PYeGuawjFLpmh2x8/rQL8rOETgJLv9Qhj6nfdvlNMo+GGj3if0WbUk0WOmRtVp kTn3AJRN+KditEfc15Nm4ygLMpEpab9/WuubcB4BEF/LxEPtMsEZA5jq5o99Z+nEfn D+rfBZRixOAFopTqnqNvSbFMxy6wm2KdlGQbKUTY8GlTR4PML0xVQsnyhD1U0VPuR2 OhcmQ6K4Wh0rXRGKPPWhzXlQBTCNv1YGkBO+sZybF1tI+OL6+dWDoiJf64Fh+K9kz5 a6fpp4oMpYcdw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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 (---) St=C3=A9phane Marks <shipmints@HIDDEN> writes: > On Tue, Nov 18, 2025 at 18:05 Spencer Baugh <sbaugh@HIDDEN> wrote: > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <sbaugh@janestre= et.com> wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <sbaugh@janes= treet.com> wrote: > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <sbaugh@ja= nestreet.com> wrote: > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh= @janestreet.com> wrote: > > > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > Alright! Hand becoming sufficiently usable! Sorry for the = delay. > > > > > > > > > > > > Spencer, can you take a quick look at the patch you provid= ed via > > > > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.pa= tch > > > > > > it does not pass the vtable tests (which we will beef up, = and get rid of the typo in the first test name). > > > > > > > > > > Thanks for checking, apologies about that, it was just an er= ror > > > > > introduced when I ported the patch forward from emacs-30 (wh= ich is what > > > > > we use at my site). > > > > > > > > > > Fixed it, this version should be correct. > > > > > > > > > > Thank you. Tests pass. > > > > > > > > > > I think we should eliminate the slot -cache and get rid of th= e cache key entirely (the slot being superseded by the > > > > vtable-cache > > > > > text property). Each time the cache needs to be refreshed, t= he user runs vtable-revert which repopulates the now > sole > > > > cache.=20 > > > > > Leaving the remnants of the old mechanism in place will confu= se people. I also think we should rename > current-cache > > to > > > > just > > > > > cache. If agreed, I'll finish this patch by removing the rem= nants. > > > > > > > > Feel free to try it; please send your patch as a diff on top of= mine so > > > > I can review it. > > > > > > > > Note that we still need something like the cache key just to kn= ow when > > > > we need to invalidate the cache. And when we revert the vtable= we > > > > currently grab the cache out of the slot -cache; we'll need to = change > > > > the code to grab the cache out of the text properties before we= erase > > > > the previously inserted table. > > > > > > > > I don't think explicit cache invalidation is needed. If the dis= plays a vtable in another window of a different size, or > resizes > > > the > > > > current window, they have to vtable-revert anyway, right? > > > > > > Yes. vtable-revert calls vtable-insert which doesn't clear the ca= che if > > > the cache key is the same, so it doesn't recompute the cached data. > > > > > > Here's a simplified cache patch layered on top of yours. If you ag= ree, I think we should squash them. > > > > This causes us to recompute the cache every time we call vtable-rever= t, > > instead of reusing it. Isn't that expensive? > > > > What I'd like to do is introduce more thoughtful cache invalidation lo= gic as I'd proposed in the larger patch. The logic there > was > > complicated by the multi-cache infrastructure which is now gone. I'll= introduce that logic in another patch as I go through > all the > > other stuff I have accumulated to add. > > > > If we can agree on this patch, let's get it going and continue along? > > If you're going to be introducing more thoughtful cache invalidation > logic, then please just post a patch that contains that. > > As it stands, the patch you just posted will cause a performance > regression and so therefore should not be installed. > > Alright let's install yours and keep going then.=20 I would if I could :) I think we still need to find someone else who will kindly install this patch.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 23:40:21 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 18:40:21 2025 Received: from localhost ([127.0.0.1]:60522 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLVJ6-0003Zs-2S for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:40:21 -0500 Received: from mail-vs1-xe2c.google.com ([2607:f8b0:4864:20::e2c]:53331) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vLVJ3-0003ZH-CY for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:40:18 -0500 Received: by mail-vs1-xe2c.google.com with SMTP id ada2fe7eead31-5dfd4a02638so1404849137.2 for <69837 <at> debbugs.gnu.org>; Tue, 18 Nov 2025 15:40:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763509211; x=1764114011; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=aSSOnowjZpCbyfBMcLQMa6tiEUu4/Dydea00TmUrY8s=; b=VS/Pw59klszmnjdlWUNqW7PJpQeDHQ9veD5Bho1QHFLZHGLpOrHPsRpAl7VitamEIK YyX6Qph7GfX7/b/2+4LuRxHhD4RqLdW1dX3C7alJ41ex0kqdbMxdAh2kgX6uSEWeW3ZK xnnK/hCSYjHudccz7UXUIpbmAppx40Uni+O6ZY6h7wKIJ0NAc7E7arXGjnjOFgAxF8s7 tTdjfTk/uKk+Ng7grLqCB841dwqqezEyV1dVX+W5ANn13YMYGhdS6liwZhQMqJ1Kk4Zy +uLPTlXDPUR7XlHAoIKhDBkrbEPYz+kx9jj9XNeL9q2uW3k8j2Sqgtaj4wb2RV7C+Byu 1eqQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763509211; x=1764114011; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=aSSOnowjZpCbyfBMcLQMa6tiEUu4/Dydea00TmUrY8s=; b=J2NZFtcY8iVbRtTL+1mNpSO5gHJjMkqHfiyDIqQSNJvvrZwEy9MmRMDCL7hqJOUH+3 QemsYI2+aF7Jm/n6zDURTMoUHGpdljORcv83S2brISBkVZAKA6yCqKXDlGpNMre7G0+g z0BDFC9MelZC4+Sn0qdU93WmVRuPUPFsjreGGr1hKLFn3KwFDak10/Wqwe2d9rKnjvTO LX0YocBg/MkVUSPjDPOmDZkerIp6WpEiZm1KGZ9Z9S7lhIBXBWzKcSqe1a1hfs+tK0ei PgtdChsse7Pdi6g2LXZ42ZFYtsw/2M6Y2dB69OVoO3Yjp7yZ7HpF5yzpspB7JsNPWoKQ o2YQ== X-Forwarded-Encrypted: i=1; AJvYcCUlBQPym3ts21CyX2v2HK3Vzic7toTIS6hFPntmFM/wICp0mqYUXZ+7AnvwVGgV8h8SSzx+mg==@debbugs.gnu.org X-Gm-Message-State: AOJu0YwXp4VbEofgOcquGrkKa23S4x2qeY7cvFD0FsKSbQtqpXlgh195 1lExSD+KH/RvB2Vzm4BF0iRQsA69buVffDr+2K56FnXAFc8eOfp9M/1oftsV3wH5x5/h02hJl2y U00ZFz+P36b9fFAaj52IEGbrmCs2Lm6s= X-Gm-Gg: ASbGnct9+1BpgagYl83NbATwyJIEjz6FYJ5DYl5+A63SJRFUI3k8PhSkaxPJgb0ukFk oiglaYZCMawNr/PbSHhha/3O3pebtoVdDdw8KGUijzVNQjfBfRkUVFAoP013BW1Rkr5NCbQwG1L XTTfU6p/2GmFWg6Pwuod+7kKzARfAtzyzyQ6CQlcDypnaOj1T7sdt3sHUqEae4+U8BDL8vV6uqN GGniyz49LrH9+BVoj8e+M179KPdVA7cVT5t1KFcE+cvMes2oBDk0FiPopqfkxPeUM1b/8hIe3ym W9yILw== X-Google-Smtp-Source: AGHT+IF9zs1FgZ4WoO6oV5JwpZb7EAvZF/ZsB8HbkbhtdhWe/P3n5viI5Lt/x+5xToGjhNHP1e48E7OnpdWCe6n5uC8= X-Received: by 2002:a05:6102:4187:b0:5dd:a616:69fc with SMTP id ada2fe7eead31-5dfc54f9602mr6009611137.9.1763509211483; Tue, 18 Nov 2025 15:40:11 -0800 (PST) MIME-Version: 1.0 References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> <ier7bvngenv.fsf_-_@HIDDEN> <CAN+1HbqQn4H834+dhAy-0CE8Dzb7UYbpw+tVEQPcV=8YQZRCNg@HIDDEN> <ier4iqrgcvi.fsf@HIDDEN> In-Reply-To: <ier4iqrgcvi.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Tue, 18 Nov 2025 18:40:00 -0500 X-Gm-Features: AWmQ_bnt1wHtqHdqk9w-bOxuSCpu_31SdQrLqsjYJMG8HUbJaK8mKgKKjLA2OMc Message-ID: <CAN+1HbpwwmgOgp45z93CTu=MeBb_4UnTdKMykQ8f8RqOgDDUaw@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el, [PATCH] Simplify vtable cache handling To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000001bd2af0643e6fc10" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --0000000000001bd2af0643e6fc10 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2025 at 18:05 Spencer Baugh <sbaugh@HIDDEN> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <sbaugh@janestree= t.com> > wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <sbaugh@janest= reet.com> > wrote: > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh < > sbaugh@HIDDEN> wrote: > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh < > sbaugh@HIDDEN> wrote: > > > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > Alright! Hand becoming sufficiently usable! Sorry for the > delay. > > > > > > > > > > > > Spencer, can you take a quick look at the patch you provide= d > via > > > > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.pat= ch > > > > > > it does not pass the vtable tests (which we will beef up, > and get rid of the typo in the first test name). > > > > > > > > > > Thanks for checking, apologies about that, it was just an err= or > > > > > introduced when I ported the patch forward from emacs-30 > (which is what > > > > > we use at my site). > > > > > > > > > > Fixed it, this version should be correct. > > > > > > > > > > Thank you. Tests pass. > > > > > > > > > > I think we should eliminate the slot -cache and get rid of the > cache key entirely (the slot being superseded by the > > > > vtable-cache > > > > > text property). Each time the cache needs to be refreshed, th= e > user runs vtable-revert which repopulates the now sole > > > > cache. > > > > > Leaving the remnants of the old mechanism in place will confus= e > people. I also think we should rename current-cache > > to > > > > just > > > > > cache. If agreed, I'll finish this patch by removing the > remnants. > > > > > > > > Feel free to try it; please send your patch as a diff on top of > mine so > > > > I can review it. > > > > > > > > Note that we still need something like the cache key just to kno= w > when > > > > we need to invalidate the cache. And when we revert the vtable = we > > > > currently grab the cache out of the slot -cache; we'll need to > change > > > > the code to grab the cache out of the text properties before we > erase > > > > the previously inserted table. > > > > > > > > I don't think explicit cache invalidation is needed. If the > displays a vtable in another window of a different size, or resizes > > > the > > > > current window, they have to vtable-revert anyway, right? > > > > > > Yes. vtable-revert calls vtable-insert which doesn't clear the > cache if > > > the cache key is the same, so it doesn't recompute the cached data. > > > > > > Here's a simplified cache patch layered on top of yours. If you > agree, I think we should squash them. > > > > This causes us to recompute the cache every time we call vtable-revert= , > > instead of reusing it. Isn't that expensive? > > > > What I'd like to do is introduce more thoughtful cache invalidation > logic as I'd proposed in the larger patch. The logic there was > > complicated by the multi-cache infrastructure which is now gone. I'll > introduce that logic in another patch as I go through all the > > other stuff I have accumulated to add. > > > > If we can agree on this patch, let's get it going and continue along? > > If you're going to be introducing more thoughtful cache invalidation > logic, then please just post a patch that contains that. > > As it stands, the patch you just posted will cause a performance > regression and so therefore should not be installed. Alright let's install yours and keep going then. > > --0000000000001bd2af0643e6fc10 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div><br></div><div><br><div class=3D"gmail_quote gmail_quote_container"><d= iv dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 18, 2025 at 18:05 Spencer B= augh <<a href=3D"mailto:sbaugh@HIDDEN">sbaugh@HIDDEN</a>= > wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 = 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">St=C3=A9phane Marks <= ;<a href=3D"mailto:shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN= om</a>> writes:<br> <br> > On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <<a href=3D"m= ailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</a>>= ; wrote:<br> ><br> >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" t= arget=3D"_blank">shipmints@HIDDEN</a>> writes:<br> ><br> >=C2=A0 > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <<= a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@janestreet= .com</a>> wrote:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@g= mail.com" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer = Baugh <<a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh= @janestreet.com</a>> wrote:<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:= shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<= br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 > On Mon, Nov 10, 2025 at 6:00=E2=80=AF= PM Spencer Baugh <<a href=3D"mailto:sbaugh@HIDDEN" target=3D"_bl= ank">sbaugh@HIDDEN</a>> wrote:<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href= =3D"mailto:shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>&g= t; writes:<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Alright! Hand becoming suf= ficiently usable! Sorry for the delay.<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > Spencer, can you take a qu= ick look at the patch you provided via<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 0001-Fix-implicit-usage-of-the-= current-window-width-in-vt.patch<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 > it does not pass the vtabl= e tests (which we will beef up, and get rid of the typo in the first test n= ame).<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 Thanks for checking, apologies = about that, it was just an error<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 introduced when I ported the pa= tch forward from emacs-30 (which is what<br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 we use at my site).<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 >=C2=A0 Fixed it, this version should b= e correct.<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 > Thank you.=C2=A0 Tests pass.<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 > I think we should eliminate the slot = -cache and get rid of the cache key entirely (the slot being superseded by = the<br> >=C2=A0 >=C2=A0 >=C2=A0 vtable-cache<br> >=C2=A0 >=C2=A0 >=C2=A0 > text property).=C2=A0 Each time the c= ache needs to be refreshed, the user runs vtable-revert which repopulates t= he now sole<br> >=C2=A0 >=C2=A0 >=C2=A0 cache. <br> >=C2=A0 >=C2=A0 >=C2=A0 > Leaving the remnants of the old mecha= nism in place will confuse people.=C2=A0 I also think we should rename curr= ent-cache<br> >=C2=A0 to<br> >=C2=A0 >=C2=A0 >=C2=A0 just<br> >=C2=A0 >=C2=A0 >=C2=A0 > cache.=C2=A0 If agreed, I'll fini= sh this patch by removing the remnants.<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 Feel free to try it; please send your patc= h as a diff on top of mine so<br> >=C2=A0 >=C2=A0 >=C2=A0 I can review it.<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 Note that we still need something like the= cache key just to know when<br> >=C2=A0 >=C2=A0 >=C2=A0 we need to invalidate the cache.=C2=A0 And= when we revert the vtable we<br> >=C2=A0 >=C2=A0 >=C2=A0 currently grab the cache out of the slot -= cache; we'll need to change<br> >=C2=A0 >=C2=A0 >=C2=A0 the code to grab the cache out of the text= properties before we erase<br> >=C2=A0 >=C2=A0 >=C2=A0 the previously inserted table.<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 > I don't think explicit cache invalidation is= needed.=C2=A0 If the displays a vtable in another window of a different si= ze, or resizes<br> >=C2=A0 >=C2=A0 the<br> >=C2=A0 >=C2=A0 > current window, they have to vtable-revert anywa= y, right?<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 Yes.=C2=A0 vtable-revert calls vtable-insert which do= esn't clear the cache if<br> >=C2=A0 >=C2=A0 the cache key is the same, so it doesn't recomput= e the cached data.<br> >=C2=A0 ><br> >=C2=A0 > Here's a simplified cache patch layered on top of yours= .=C2=A0 If you agree, I think we should squash them.<br> ><br> >=C2=A0 This causes us to recompute the cache every time we call vtable-= revert,<br> >=C2=A0 instead of reusing it.=C2=A0 Isn't that expensive?<br> ><br> > What I'd like to do is introduce more thoughtful cache invalidatio= n logic as I'd proposed in the larger patch.=C2=A0 The logic there was<= br> > complicated by the multi-cache infrastructure which is now gone.=C2=A0= I'll introduce that logic in another patch as I go through all the<br> > other stuff I have accumulated to add.<br> ><br> > If we can agree on this patch, let's get it going and continue alo= ng?<br> <br> If you're going to be introducing more thoughtful cache invalidation<br= > logic, then please just post a patch that contains that.<br> <br> As it stands, the patch you just posted will cause a performance<br> regression and so therefore should not be installed.</blockquote><div dir= =3D"auto"><br></div><div dir=3D"auto">Alright let's install yours and k= eep going then.=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" dir=3D"auto"><br> </blockquote></div></div> --0000000000001bd2af0643e6fc10--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 23:06:00 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 18:06:00 2025 Received: from localhost ([127.0.0.1]:60336 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLUls-0001PR-Bu for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:06:00 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:35977) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vLUlq-0001PC-TH for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:05:59 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el, [PATCH] Simplify vtable cache handling In-Reply-To: <CAN+1HbqQn4H834+dhAy-0CE8Dzb7UYbpw+tVEQPcV=8YQZRCNg@HIDDEN> (=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Tue, 18 Nov 2025 18:01:38 -0500") References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> <ier7bvngenv.fsf_-_@HIDDEN> <CAN+1HbqQn4H834+dhAy-0CE8Dzb7UYbpw+tVEQPcV=8YQZRCNg@HIDDEN> Date: Tue, 18 Nov 2025 18:05:53 -0500 Message-ID: <ier4iqrgcvi.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1763507153; bh=Z3N4iWx6AtzMs/6HiKd2qIv2mPwq8JE+agkdUsnCUVQ=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=vDw2WiCPFCvfTS80gHo3iESPS1/yXzyALyQX9IRtjAcj1wqn/D1bd2w3J8Xls8k5n KAwRGDW/XDQBk49ps1LJ5qxjAUwrN4KkpnexA4fzyTVtFctmNh7qOqGC/L+y364lyi 1jHhKoWtj723eL+Dp8m0uP718ihQz/zLxhPR2pTNLwhkCKbK6M4Om7G51fOrI7TKWA gM6syIqd2btp0xh/OOsaLWyn5Tzy718ShEwrF+GqyKSvpK6ULBr3H4v2a3wonzksDH RuwFKeJsvk3qupFNCEMRwv6UNswVVaKLHke9rWRHcbOlVnVgc6uw+Pbva/xU7leN6U x2TKc6o887hmw== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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 (---) St=C3=A9phane Marks <shipmints@HIDDEN> writes: > On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <sbaugh@janestreet.= com> wrote: > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <sbaugh@janestre= et.com> wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <sbaugh@janes= treet.com> wrote: > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh@ja= nestreet.com> wrote: > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > Alright! Hand becoming sufficiently usable! Sorry for the del= ay. > > > > > > > > > > Spencer, can you take a quick look at the patch you provided = via > > > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > > > > it does not pass the vtable tests (which we will beef up, and= get rid of the typo in the first test name). > > > > > > > > Thanks for checking, apologies about that, it was just an error > > > > introduced when I ported the patch forward from emacs-30 (which= is what > > > > we use at my site). > > > > > > > > Fixed it, this version should be correct. > > > > > > > > Thank you. Tests pass. > > > > > > > > I think we should eliminate the slot -cache and get rid of the c= ache key entirely (the slot being superseded by the > > > vtable-cache > > > > text property). Each time the cache needs to be refreshed, the = user runs vtable-revert which repopulates the now sole > > > cache.=20 > > > > Leaving the remnants of the old mechanism in place will confuse = people. I also think we should rename current-cache > to > > > just > > > > cache. If agreed, I'll finish this patch by removing the remnan= ts. > > > > > > Feel free to try it; please send your patch as a diff on top of mi= ne so > > > I can review it. > > > > > > Note that we still need something like the cache key just to know = when > > > we need to invalidate the cache. And when we revert the vtable we > > > currently grab the cache out of the slot -cache; we'll need to cha= nge > > > the code to grab the cache out of the text properties before we er= ase > > > the previously inserted table. > > > > > > I don't think explicit cache invalidation is needed. If the displa= ys a vtable in another window of a different size, or resizes > > the > > > current window, they have to vtable-revert anyway, right? > > > > Yes. vtable-revert calls vtable-insert which doesn't clear the cache= if > > the cache key is the same, so it doesn't recompute the cached data. > > > > Here's a simplified cache patch layered on top of yours. If you agree= , I think we should squash them. > > This causes us to recompute the cache every time we call vtable-revert, > instead of reusing it. Isn't that expensive? > > What I'd like to do is introduce more thoughtful cache invalidation logic= as I'd proposed in the larger patch. The logic there was > complicated by the multi-cache infrastructure which is now gone. I'll in= troduce that logic in another patch as I go through all the > other stuff I have accumulated to add. > > If we can agree on this patch, let's get it going and continue along? If you're going to be introducing more thoughtful cache invalidation logic, then please just post a patch that contains that. As it stands, the patch you just posted will cause a performance regression and so therefore should not be installed.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 23:02:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 18:02:04 2025 Received: from localhost ([127.0.0.1]:60320 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLUi4-0001D7-4m for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:02:04 -0500 Received: from mail-ua1-x92a.google.com ([2607:f8b0:4864:20::92a]:58435) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vLUi0-0001CZ-Ph for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 18:02:02 -0500 Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-9351ed45fb8so1486881241.0 for <69837 <at> debbugs.gnu.org>; Tue, 18 Nov 2025 15:02:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763506915; x=1764111715; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=6C/JoaoqgPNF7X9YnEpOadtqGjjeOQJQ+SzuALmeMQs=; b=irK8o2ZIH6d2mLLup3Gic4OctH0rf8IhpVCVI3bECaUKJ0ECY6Wytsz7kdf9OorBky vn4zF0UIyZxhBWqKH65YQInQnTXv/hIR0ZvKqLhQ715ijWGIFXev0SaQMimkD4LQgQDb H6H2MeL+zX9qw3a5KxJIamCSTTFsmnY6fT/gYaSYLlk/EqbKASIxpwQmTUnQp2T+jKyJ cxMKYhd0Ns/zGihPZzUhtZI5ryTV+rJSqg19nMWhEoEye/kwhWzoxF9SUmRadFXBurNW 6SFTS1f/nQqmBYok5LSKmd1ar/LfnyBhSQ3Tsnc1vDIRYRsjIc9f7xvEvWi9Ma29Yovi ynJw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763506915; x=1764111715; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=6C/JoaoqgPNF7X9YnEpOadtqGjjeOQJQ+SzuALmeMQs=; b=L77ZJ2TFbXvMDXQlbPBlSEcm4+coYPib2cGM8sZsurldmVb/GK6m1nRwyIK8AKmIIC I2E2kuM+XftoRI4oh2xU1v6i1p6bnWF6GqQM4I/yoGVME0jsiUz3y8XNVVbMK9NeS+/O 0+6MSyjslTzIJIqh49ddvGsd5oVZU+Qc4eEslGUMuSXRT7vAhx+zU6M6YFefXe/PaAAn ejkv4Vlr8oXXF+w4ebDQVc39HoKDs9gTnJJdemwPhy1A5C4zdMxddr5M+WHQSGEtlKO7 EfMkEQ+2+S+IrxG4QxJWiF32KmM9qi3oEd/FoV862z6LbqjjB1V2VyXe7oNeVv5W7X/o re8A== X-Forwarded-Encrypted: i=1; AJvYcCUfRnUIRX37u/Gt8hdszEPxiRY7CORA9ik6yhvh6k2uaU628kHVVsbFXASZrCo2+QJrg0e6HQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yyad9VKlgnnxoZk12HnUaZXi0zi4+QIQ5XNJ5WkHgAFAqXs4jy0 UM+7PEt1LrDtbhjXCNs4ol1thQI0ToVCs9YW/DTAmnTUb9HwrRF+64yT1cmKt36eqx7uu1Sp3mb 4gnERHnbewWJTcqvYcGpFUp9h498pMMI= X-Gm-Gg: ASbGncuF7KiyIGoMHNRI5UsSqfZqWjrcexsYz05JVfimZs61DpeBhOqKmn5ZQWX67Db esaA0ikMOpWetM5xutekOhOT0JzENlIY+wk8lCq7Tc12quOVY5DMLw6ioN4OiO1//2qaUgGt4zL skpCyTo5uZdVkPZZBOJmNaaqRdIKfmobYNfUbtVk+TJkJ/Rclw4+yeKXgIO6XTu82B6t9AUN6Zf zf1E2QmFVU07VA1n/yNm8qqv1cf/NAYtRaZGYXXo6bJ47HtZZ7YZiIhGqeh3GLZZY4YkfT7GQGg fV4MQw== X-Google-Smtp-Source: AGHT+IFcZdeiBkOuomJ9cgosJ58aq1hnZtxJRtDHYiZug1gFdkixgdGa6P6W2C7G42AylT1r8PMjk5lbC4pJjaQHLig= X-Received: by 2002:a05:6102:54ac:b0:5d5:f6ae:38dc with SMTP id ada2fe7eead31-5dfc5b88e95mr5866074137.39.1763506914870; Tue, 18 Nov 2025 15:01:54 -0800 (PST) MIME-Version: 1.0 References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <86h6h34gj6.fsf@HIDDEN> <8e2fb7a9-202e-45c9-ab2d-c2cd6395d590@HIDDEN> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> <ier7bvngenv.fsf_-_@HIDDEN> In-Reply-To: <ier7bvngenv.fsf_-_@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Tue, 18 Nov 2025 18:01:38 -0500 X-Gm-Features: AWmQ_bkCUcqyK2kaSrNi7fJYMwI5cNDaW2i6Dda6slZlwSaa8YfD_pM7u4yQkE8 Message-ID: <CAN+1HbqQn4H834+dhAy-0CE8Dzb7UYbpw+tVEQPcV=8YQZRCNg@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el, [PATCH] Simplify vtable cache handling To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000003856a70643e673ec" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --0000000000003856a70643e673ec Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <sbaugh@janestree= t.com> > wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <sbaugh@janest= reet.com> > wrote: > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh < > sbaugh@HIDDEN> wrote: > > > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > Alright! Hand becoming sufficiently usable! Sorry for the dela= y. > > > > > > > > > > Spencer, can you take a quick look at the patch you provided v= ia > > > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > > > > it does not pass the vtable tests (which we will beef up, and > get rid of the typo in the first test name). > > > > > > > > Thanks for checking, apologies about that, it was just an error > > > > introduced when I ported the patch forward from emacs-30 (which > is what > > > > we use at my site). > > > > > > > > Fixed it, this version should be correct. > > > > > > > > Thank you. Tests pass. > > > > > > > > I think we should eliminate the slot -cache and get rid of the > cache key entirely (the slot being superseded by the > > > vtable-cache > > > > text property). Each time the cache needs to be refreshed, the > user runs vtable-revert which repopulates the now sole > > > cache. > > > > Leaving the remnants of the old mechanism in place will confuse > people. I also think we should rename current-cache to > > > just > > > > cache. If agreed, I'll finish this patch by removing the remnant= s. > > > > > > Feel free to try it; please send your patch as a diff on top of min= e > so > > > I can review it. > > > > > > Note that we still need something like the cache key just to know > when > > > we need to invalidate the cache. And when we revert the vtable we > > > currently grab the cache out of the slot -cache; we'll need to chan= ge > > > the code to grab the cache out of the text properties before we era= se > > > the previously inserted table. > > > > > > I don't think explicit cache invalidation is needed. If the display= s > a vtable in another window of a different size, or resizes > > the > > > current window, they have to vtable-revert anyway, right? > > > > Yes. vtable-revert calls vtable-insert which doesn't clear the cache = if > > the cache key is the same, so it doesn't recompute the cached data. > > > > Here's a simplified cache patch layered on top of yours. If you agree, > I think we should squash them. > > This causes us to recompute the cache every time we call vtable-revert, > instead of reusing it. Isn't that expensive? > What I'd like to do is introduce more thoughtful cache invalidation logic as I'd proposed in the larger patch. The logic there was complicated by the multi-cache infrastructure which is now gone. I'll introduce that logic in another patch as I go through all the other stuff I have accumulated to add. If we can agree on this patch, let's get it going and continue along? --0000000000003856a70643e673ec Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Tue, Nov 18, 2025 at 5:27=E2=80=AFPM Spencer Baugh <<a href=3D"mailto= :sbaugh@HIDDEN">sbaugh@HIDDEN</a>> wrote:</span></div></= div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">St=C3=A9phane Marks <<a href=3D"mailto:shipm= ints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> <br> > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <<a href=3D"m= ailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</a>>= ; wrote:<br> ><br> >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" t= arget=3D"_blank">shipmints@HIDDEN</a>> writes:<br> ><br> >=C2=A0 > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <<= a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@janestreet= .com</a>> wrote:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@g= mail.com" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer = Baugh <<a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh= @janestreet.com</a>> wrote:<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:= shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<= br> >=C2=A0 >=C2=A0 >=C2=A0 > Alright! Hand becoming sufficiently u= sable! Sorry for the delay.<br> >=C2=A0 >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 > Spencer, can you take a quick look at= the patch you provided via<br> >=C2=A0 >=C2=A0 >=C2=A0 0001-Fix-implicit-usage-of-the-current-win= dow-width-in-vt.patch<br> >=C2=A0 >=C2=A0 >=C2=A0 > it does not pass the vtable tests (wh= ich we will beef up, and get rid of the typo in the first test name).<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 Thanks for checking, apologies about that,= it was just an error<br> >=C2=A0 >=C2=A0 >=C2=A0 introduced when I ported the patch forward= from emacs-30 (which is what<br> >=C2=A0 >=C2=A0 >=C2=A0 we use at my site).<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 >=C2=A0 Fixed it, this version should be correct.<= br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 > Thank you.=C2=A0 Tests pass.<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 > I think we should eliminate the slot -cache and = get rid of the cache key entirely (the slot being superseded by the<br> >=C2=A0 >=C2=A0 vtable-cache<br> >=C2=A0 >=C2=A0 > text property).=C2=A0 Each time the cache needs = to be refreshed, the user runs vtable-revert which repopulates the now sole= <br> >=C2=A0 >=C2=A0 cache. <br> >=C2=A0 >=C2=A0 > Leaving the remnants of the old mechanism in pla= ce will confuse people.=C2=A0 I also think we should rename current-cache t= o<br> >=C2=A0 >=C2=A0 just<br> >=C2=A0 >=C2=A0 > cache.=C2=A0 If agreed, I'll finish this pat= ch by removing the remnants.<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 Feel free to try it; please send your patch as a diff= on top of mine so<br> >=C2=A0 >=C2=A0 I can review it.<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 Note that we still need something like the cache key = just to know when<br> >=C2=A0 >=C2=A0 we need to invalidate the cache.=C2=A0 And when we re= vert the vtable we<br> >=C2=A0 >=C2=A0 currently grab the cache out of the slot -cache; we&#= 39;ll need to change<br> >=C2=A0 >=C2=A0 the code to grab the cache out of the text properties= before we erase<br> >=C2=A0 >=C2=A0 the previously inserted table.<br> >=C2=A0 ><br> >=C2=A0 > I don't think explicit cache invalidation is needed.=C2= =A0 If the displays a vtable in another window of a different size, or resi= zes<br> >=C2=A0 the<br> >=C2=A0 > current window, they have to vtable-revert anyway, right?<b= r> ><br> >=C2=A0 Yes.=C2=A0 vtable-revert calls vtable-insert which doesn't c= lear the cache if<br> >=C2=A0 the cache key is the same, so it doesn't recompute the cache= d data.<br> ><br> > Here's a simplified cache patch layered on top of yours.=C2=A0 If = you agree, I think we should squash them.<br> <br> This causes us to recompute the cache every time we call vtable-revert,<br> instead of reusing it.=C2=A0 Isn't that expensive?<br></blockquote><div= ><br></div><div class=3D"gmail_default" style=3D"font-family:monospace">Wha= t I'd like to do is introduce more thoughtful cache invalidation logic = as I'd proposed in the larger patch.=C2=A0 The logic there was complica= ted by the multi-cache infrastructure which is now gone.=C2=A0 I'll int= roduce that logic in another patch as I go through all the other stuff I ha= ve accumulated to add.</div><div class=3D"gmail_default" style=3D"font-fami= ly:monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:m= onospace">If we can agree on this patch, let's get it going and continu= e along?</div></div></div> --0000000000003856a70643e673ec--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 22:27:25 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 17:27:24 2025 Received: from localhost ([127.0.0.1]:60124 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLUAV-0007bp-ST for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 17:27:24 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:52551) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vLUAT-0007bV-Si for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 17:27:22 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el, [PATCH] Simplify vtable cache handling In-Reply-To: <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> (=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Tue, 18 Nov 2025 16:25:20 -0500") References: <1388eaa8-ae65-43f9-9438-d5bab59f20d8@HIDDEN> <86h6h34gj6.fsf@HIDDEN> <8e2fb7a9-202e-45c9-ab2d-c2cd6395d590@HIDDEN> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> Date: Tue, 18 Nov 2025 17:27:16 -0500 Message-ID: <ier7bvngenv.fsf_-_@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1763504836; bh=HCj8n3ZndS9RUDgKBfM5QLXUlxF5hsCVGo+IZR6ePtk=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=Y252Fp1sHuc7rTYKmvn/kdFg9rv0ISH51tv7DS/aTuaqsPHN5i8S4X9nwR8roz29g f4LW+3SLPZYn5J+kkkVHK1YjCH+APExA704gQVVF9dKP4nrDh2oiRLUbrq4f+pYm3s wCc6kVrE5J7S9W4FOQoo8sxuog13ooWBbFGo99/C5KEMStFsfDaLwF72rHaWbc8+ES FdkXSOFk8bhLc0S1f8bo/rXzA/QeSbtJEV/6C5lt74W1K8RsIZk6gR5LP27gY/C9wF Unc4YcvYst+C9TVrSU6MlvHZJqmiF7S85tuBjXSHm8SDCOePY3oNvEwx6hEtRq6Si6 ly0SPOn6/qk1g== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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 (---) St=C3=A9phane Marks <shipmints@HIDDEN> writes: > On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <sbaugh@janestreet.= com> wrote: > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <sbaugh@janestre= et.com> wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh@janes= treet.com> wrote: > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > Alright! Hand becoming sufficiently usable! Sorry for the delay. > > > > > > > > Spencer, can you take a quick look at the patch you provided via > > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > > > it does not pass the vtable tests (which we will beef up, and ge= t rid of the typo in the first test name). > > > > > > Thanks for checking, apologies about that, it was just an error > > > introduced when I ported the patch forward from emacs-30 (which is= what > > > we use at my site). > > > > > > Fixed it, this version should be correct. > > > > > > Thank you. Tests pass. > > > > > > I think we should eliminate the slot -cache and get rid of the cach= e key entirely (the slot being superseded by the > > vtable-cache > > > text property). Each time the cache needs to be refreshed, the use= r runs vtable-revert which repopulates the now sole > > cache.=20 > > > Leaving the remnants of the old mechanism in place will confuse peo= ple. I also think we should rename current-cache to > > just > > > cache. If agreed, I'll finish this patch by removing the remnants. > > > > Feel free to try it; please send your patch as a diff on top of mine = so > > I can review it. > > > > Note that we still need something like the cache key just to know when > > we need to invalidate the cache. And when we revert the vtable we > > currently grab the cache out of the slot -cache; we'll need to change > > the code to grab the cache out of the text properties before we erase > > the previously inserted table. > > > > I don't think explicit cache invalidation is needed. If the displays = a vtable in another window of a different size, or resizes > the > > current window, they have to vtable-revert anyway, right? > > Yes. vtable-revert calls vtable-insert which doesn't clear the cache if > the cache key is the same, so it doesn't recompute the cached data. > > Here's a simplified cache patch layered on top of yours. If you agree, I= think we should squash them. This causes us to recompute the cache every time we call vtable-revert, instead of reusing it. Isn't that expensive?
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 21:25:46 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 16:25:46 2025 Received: from localhost ([127.0.0.1]:59866 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLTCs-0003xr-1J for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 16:25:46 -0500 Received: from mail-ua1-x92d.google.com ([2607:f8b0:4864:20::92d]:60748) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vLTCp-0003xd-52 for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 16:25:44 -0500 Received: by mail-ua1-x92d.google.com with SMTP id a1e0cc1a2514c-93515cb8c2bso3386611241.1 for <69837 <at> debbugs.gnu.org>; Tue, 18 Nov 2025 13:25:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763501137; x=1764105937; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=T2E6Rnv2+21BnMuFxxTeDQNAidiBfUGk5HnVG7mHzAA=; b=KY5Om33z4iq6hdFDzxcC3dd/wfbDQX4dOolBU5zh+c7WgkWfTdkXC1a2dU6gXQcpWu 2PfeTgnfncob1VzNNsI/WASDuNH963sfObRukEoJxB2iMEU9oldHTx/3dV6sCopnP/j7 GBNt0aHgVZqYrSYdv6H5HCJlA8M8vyiGxKzaqyCwBeHtmpiqc806nhJbGXy/hKamJPzQ uN5zeZAd/X8Bag2E4FoG4rPRKrxBeeNO1CaUvCb3ZZd/s/ZFwm4V71fqbVjMiVfHSpAZ +/WFvy1nbgZ45DfThoOi6juwgY1NvFRysnD7h0LogVFV+u/mIjzXJvX8qUOp2yRNrdOZ M7Mw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763501137; x=1764105937; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=T2E6Rnv2+21BnMuFxxTeDQNAidiBfUGk5HnVG7mHzAA=; b=o1NQFgm7nT3pP8RQhPay/5wEwMTw4izZkVxI5qsfHgeutlMd6jukMw5TosivdQ9EOZ KG1KRhAx+Y6XdGh3CgwpKQDKA7NpDAxF2LS16GxGrJIGqkSoZWksbpCM4GV26n6oZh2L bepK2YV3pMEC7GvkVjVmxHaq5BGiemfJoLGDcY+0CJCu/oaaA6KiY75OR0IjC46V4oGJ c+UwBkcW1/otQmVJoMAcMS9Dwct8iEcNwRVN5EVcVoRYXBoJ6naWDEKkawrPI2ocKQHP vt2BwFRz4LqTxFshzjLN9vHytBl0BR82v+8wxc0s9zbPnEe3WyYKtbOjEFypdETr2Wv/ H5Ug== X-Forwarded-Encrypted: i=1; AJvYcCXTwVIs4nm72fvAue+uQK18t/DHHJgiAwKCAlcg/H7UbR0yriihjPnQIwM8kl1+XRrs2hE17Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yy655XQ2R7Kbs7zDzgZ3x6/zaXsFRQ3k3qlEaN5F3c0c0OOVmTA EQ7W7uqQj7grH4+Bd0pgzj0EwG8znOw6zDQGu2ylGNnpnPHB399YQ/Cy1wRL7kw7ldfQYYI1uJ+ EUJtKJJGMOaDrk6RJ/44EPmR7miTx1VihKQ== X-Gm-Gg: ASbGncs7P+5EuVlXPpwZ6mIN/tHwqNUuZbLyZhiOvrmUONnOkb+TfCfthyJlzjLcH3t 5Gk5NEBp5dpSiYTo9pSv9eCdANpNgQ0XTq85vKF+Wa6A+eo0zV3esumml0u4is9JkAqzeGc3/GD yfZdylLNLxlEhRtFQUHmlsbEdxRMRUn9ljGKpyYh3xGiu86G9s0k5O7UE0n1Dm9YMuVuQXfNhWo xznykKK3t5iCKyp8wwDL/0Zt1AG8OGulNh48BrRiurNFNg6sw9tnStNuoz85z9c+tZ6Fm0= X-Google-Smtp-Source: AGHT+IGCaGB4nqK/oM6BoMYuvgVAw0Se/GO9fkeuaaWi1UMyVo44/H9zhjJ6BDeFGIPnJWazbtqIu6I55T5+FKGIo4A= X-Received: by 2002:a05:6102:6442:b0:5d3:ff01:363d with SMTP id ada2fe7eead31-5dfc5b723cemr6521368137.21.1763501137287; Tue, 18 Nov 2025 13:25:37 -0800 (PST) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> <iera50jgja8.fsf@HIDDEN> In-Reply-To: <iera50jgja8.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Tue, 18 Nov 2025 16:25:20 -0500 X-Gm-Features: AWmQ_bnnnOr5yI-HJCfmXWOLimki5Sv63haLcp8s4-yerJoLLN32o6q2_hes_7I Message-ID: <CAN+1HboauVO5ZHm6GrnLxxYVPTjwOfRxPos7ZAMm5xnVQv=jXg@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/mixed; boundary="000000000000d976ec0643e51ae2" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --000000000000d976ec0643e51ae2 Content-Type: multipart/alternative; boundary="000000000000d976eb0643e51ae0" --000000000000d976eb0643e51ae0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <sbaugh@janestree= t.com> > wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh@janest= reet.com> > wrote: > > > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > > Alright! Hand becoming sufficiently usable! Sorry for the delay. > > > > > > > > Spencer, can you take a quick look at the patch you provided via > > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > > > it does not pass the vtable tests (which we will beef up, and get > rid of the typo in the first test name). > > > > > > Thanks for checking, apologies about that, it was just an error > > > introduced when I ported the patch forward from emacs-30 (which is > what > > > we use at my site). > > > > > > Fixed it, this version should be correct. > > > > > > Thank you. Tests pass. > > > > > > I think we should eliminate the slot -cache and get rid of the cache > key entirely (the slot being superseded by the > > vtable-cache > > > text property). Each time the cache needs to be refreshed, the user > runs vtable-revert which repopulates the now sole > > cache. > > > Leaving the remnants of the old mechanism in place will confuse > people. I also think we should rename current-cache to > > just > > > cache. If agreed, I'll finish this patch by removing the remnants. > > > > Feel free to try it; please send your patch as a diff on top of mine s= o > > I can review it. > > > > Note that we still need something like the cache key just to know when > > we need to invalidate the cache. And when we revert the vtable we > > currently grab the cache out of the slot -cache; we'll need to change > > the code to grab the cache out of the text properties before we erase > > the previously inserted table. > > > > I don't think explicit cache invalidation is needed. If the displays a > vtable in another window of a different size, or resizes the > > current window, they have to vtable-revert anyway, right? > > Yes. vtable-revert calls vtable-insert which doesn't clear the cache if > the cache key is the same, so it doesn't recompute the cached data. > Here's a simplified cache patch layered on top of yours. If you agree, I think we should squash them. --000000000000d976eb0643e51ae0 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Tue, Nov 18, 2025 at 3:47=E2=80=AFPM Spencer Baugh <<a href=3D"mailto= :sbaugh@HIDDEN">sbaugh@HIDDEN</a>> wrote:</span></div></= div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">St=C3=A9phane Marks <<a href=3D"mailto:shipm= ints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> <br> > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <<a href=3D"m= ailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</a>>= ; wrote:<br> ><br> >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" t= arget=3D"_blank">shipmints@HIDDEN</a>> writes:<br> ><br> >=C2=A0 > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <<= a href=3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@janestreet= .com</a>> wrote:<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@g= mail.com" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> >=C2=A0 >=C2=A0 > Alright! Hand becoming sufficiently usable! Sorr= y for the delay.<br> >=C2=A0 >=C2=A0 ><br> >=C2=A0 >=C2=A0 > Spencer, can you take a quick look at the patch = you provided via<br> >=C2=A0 >=C2=A0 0001-Fix-implicit-usage-of-the-current-window-width-i= n-vt.patch<br> >=C2=A0 >=C2=A0 > it does not pass the vtable tests (which we will= beef up, and get rid of the typo in the first test name).<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 Thanks for checking, apologies about that, it was jus= t an error<br> >=C2=A0 >=C2=A0 introduced when I ported the patch forward from emacs= -30 (which is what<br> >=C2=A0 >=C2=A0 we use at my site).<br> >=C2=A0 ><br> >=C2=A0 >=C2=A0 Fixed it, this version should be correct.<br> >=C2=A0 ><br> >=C2=A0 > Thank you.=C2=A0 Tests pass.<br> >=C2=A0 ><br> >=C2=A0 > I think we should eliminate the slot -cache and get rid of = the cache key entirely (the slot being superseded by the<br> >=C2=A0 vtable-cache<br> >=C2=A0 > text property).=C2=A0 Each time the cache needs to be refre= shed, the user runs vtable-revert which repopulates the now sole<br> >=C2=A0 cache. <br> >=C2=A0 > Leaving the remnants of the old mechanism in place will con= fuse people.=C2=A0 I also think we should rename current-cache to<br> >=C2=A0 just<br> >=C2=A0 > cache.=C2=A0 If agreed, I'll finish this patch by remov= ing the remnants.<br> ><br> >=C2=A0 Feel free to try it; please send your patch as a diff on top of = mine so<br> >=C2=A0 I can review it.<br> ><br> >=C2=A0 Note that we still need something like the cache key just to kno= w when<br> >=C2=A0 we need to invalidate the cache.=C2=A0 And when we revert the vt= able we<br> >=C2=A0 currently grab the cache out of the slot -cache; we'll need = to change<br> >=C2=A0 the code to grab the cache out of the text properties before we = erase<br> >=C2=A0 the previously inserted table.<br> ><br> > I don't think explicit cache invalidation is needed.=C2=A0 If the = displays a vtable in another window of a different size, or resizes the<br> > current window, they have to vtable-revert anyway, right?<br> <br> Yes.=C2=A0 vtable-revert calls vtable-insert which doesn't clear the ca= che if<br> the cache key is the same, so it doesn't recompute the cached data.<br>= </blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-fami= ly:monospace">Here's a simplified cache patch layered on top of yours.= =C2=A0 If you agree, I think we should squash them.</div></div></div> --000000000000d976eb0643e51ae0-- --000000000000d976ec0643e51ae2 Content-Type: application/octet-stream; name="0001-Simplify-vtable-cache-handling.patch" Content-Disposition: attachment; filename="0001-Simplify-vtable-cache-handling.patch" Content-Transfer-Encoding: base64 Content-ID: <f_mi5317j50> X-Attachment-Id: f_mi5317j50 RnJvbSBiMDYyYzdjNDQyMGI4ZDEzYjMyNzZkMGMzYTFhMGE1YzA4NmI3YTM1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiA9P1VURi04P3E/U3Q9QzM9QTlwaGFuZT0yME1hcmtzPz0gPHNo aXBtaW50c0BnbWFpbC5jb20+CkRhdGU6IFR1ZSwgMTggTm92IDIwMjUgMTY6MTc6MjkgLTA1MDAK U3ViamVjdDogW1BBVENIXSBTaW1wbGlmeSB2dGFibGUgY2FjaGUgaGFuZGxpbmcKClJlbW92ZSB2 ZXN0aWdpYWwgY2FjaGUta2V5LiAgUmVuYW1lICd2dGFibGUtLWN1cnJlbnQtY2FjaGUnIHRvCid2 dGFibGUtLWNhY2hlJyB0byByZWZsZWN0IHRoYXQgdGhlcmUgaXMgb25seSBhIHNpbmdsZSBjYWNo ZQplbnRyeS4KCiogbGlzcC9lbWFjcy1saXNwL3Z0YWJsZS5lbCAodnRhYmxlKTogUmVtb3ZlICct Y2FjaGUnIHNsb3QuCih2dGFibGUtdXBkYXRlLW9iamVjdCk6IFVzZSByZW5hbWVkICd2dGFibGUt LWNhY2hlJy4KKHZ0YWJsZS1yZW1vdmUtb2JqZWN0KTogVXNlIHJlbmFtZWQgJ3Z0YWJsZS0tY2Fj aGUnLgoodnRhYmxlLWluc2VydC1vYmplY3QpOiBVc2UgcmVuYW1lZCAndnRhYmxlLS1jYWNoZScu Cih2dGFibGUtaW5zZXJ0KTogU2ltcGxpZnkgY2FjaGUgY3JlYXRpb24uCih2dGFibGUtLWNhY2hl LWtleSk6IFJlbW92ZWQgZnVuY3Rpb24uCih2dGFibGUtLWN1cnJlbnQtY2FjaGUpOiBSZW5hbWVk IHRvICd2dGFibGUtLWNhY2hlJy4KKHZ0YWJsZS0tY2FjaGUpOiBSZW5hbWVkIGZyb20gJ3Z0YWJs ZS0tY3VycmVudC1jYWNoZScuCih2dGFibGUtLWNsZWFyLWNhY2hlKTogUmVtb3ZlZCBmdW5jdGlv bi4KKHZ0YWJsZS0tYWx0ZXItY29sdW1uLXdpZHRoKTogVXNlIHJlbmFtZWQgJ3Z0YWJsZS0tY2Fj aGUnLgoodnRhYmxlLXByZXZpb3VzLWNvbHVtbik6IFVzZSByZW5hbWVkICd2dGFibGUtLWNhY2hl Jy4KKHZ0YWJsZS1uZXh0LWNvbHVtbik6IFVzZSByZW5hbWVkICd2dGFibGUtLWNhY2hlJy4KKHZ0 YWJsZS1yZXZlcnQtY29tbWFuZCk6IFJlbW92ZSBjYWxsIHRvICd2dGFibGUtLWNsZWFyLWNhY2hl Jy4KLS0tCiBsaXNwL2VtYWNzLWxpc3AvdnRhYmxlLmVsIHwgNDkgKysrKysrKysrKysrKystLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMTcgaW5zZXJ0aW9ucygrKSwg MzIgZGVsZXRpb25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9lbWFjcy1saXNwL3Z0YWJsZS5lbCBi L2xpc3AvZW1hY3MtbGlzcC92dGFibGUuZWwKaW5kZXggYmNkZDI4MGZiOTIuLmU4NmI1MDQwNjFm IDEwMDY0NAotLS0gYS9saXNwL2VtYWNzLWxpc3AvdnRhYmxlLmVsCisrKyBiL2xpc3AvZW1hY3Mt bGlzcC92dGFibGUuZWwKQEAgLTY4LDcgKzY4LDYgQEAgdnRhYmxlCiAgICAoY29sdW1uLWNvbG9y cyA6aW5pdGFyZyA6Y29sdW1uLWNvbG9ycyA6YWNjZXNzb3IgdnRhYmxlLWNvbHVtbi1jb2xvcnMp CiAgICAocm93LWNvbG9ycyA6aW5pdGFyZyA6cm93LWNvbG9ycyA6YWNjZXNzb3IgdnRhYmxlLXJv dy1jb2xvcnMpCiAgICAoLWNhY2hlZC1jb2xvcnMgOmluaXRmb3JtIG5pbCkKLSAgICgtY2FjaGUg OmluaXRmb3JtIChtYWtlLWhhc2gtdGFibGUgOnRlc3QgIydlcXVhbCkpCiAgICAoLWNhY2hlZC1r ZXltYXAgOmluaXRmb3JtIG5pbCkKICAgICgtaGFzLWNvbHVtbi1zcGVjIDppbml0Zm9ybSBuaWwp KQogICAiQW4gb2JqZWN0IHRvIGhvbGQgdGhlIGRhdGEgZm9yIGEgdGFibGUuIikKQEAgLTMwMiwx MiArMzAxLDEyIEBAIHZ0YWJsZS11cGRhdGUtb2JqZWN0CiAgICAgICAgIChlcnJvciAiQ2FuJ3Qg ZmluZCB0aGUgb2xkIG9iamVjdCIpKQogICAgICAgKHNldGNhciAoY2RyIG9iamVjdHMpIG9iamVj dCkpCiAgICAgOzsgVGhlbiB1cGRhdGUgdGhlIHJlbmRlcmVkIHZ0YWJsZSBpbiB0aGUgY3VycmVu dCBidWZmZXIuCi0gICAgKGlmLWxldCogKChjYWNoZSAodnRhYmxlLS1jdXJyZW50LWNhY2hlKSkK LSAgICAgICAgICAgICAobGluZS1udW1iZXIgKHNlcS1wb3NpdGlvbiAodnRhYmxlLS1jYWNoZS1s aW5lcyBjYWNoZSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBvbGQt b2JqZWN0Ci0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxhbWJkYSAo YSBiKQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGVxdWFsIChj YXIgYSkgYikpKSkKLSAgICAgICAgICAgICAobGluZSAoZWx0ICh2dGFibGUtLWNhY2hlLWxpbmVz IGNhY2hlKSBsaW5lLW51bWJlcikpKQorICAgIChpZi1sZXQqICgoY2FjaGUgKHZ0YWJsZS0tY2Fj aGUpKQorICAgICAgICAgICAgICAobGluZS1udW1iZXIgKHNlcS1wb3NpdGlvbiAodnRhYmxlLS1j YWNoZS1saW5lcyBjYWNoZSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgb2xkLW9iamVjdAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAo bGFtYmRhIChhIGIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg KGVxdWFsIChjYXIgYSkgYikpKSkKKyAgICAgICAgICAgICAgKGxpbmUgKGVsdCAodnRhYmxlLS1j YWNoZS1saW5lcyBjYWNoZSkgbGluZS1udW1iZXIpKSkKICAgICAgICAgKHByb2duCiAgICAgICAg ICAgKHNldGNhciBsaW5lIG9iamVjdCkKICAgICAgICAgICAoc2V0Y2RyIGxpbmUgKHZ0YWJsZS0t Y29tcHV0ZS1jYWNoZWQtbGluZSB0YWJsZSBvYmplY3QpKQpAQCAtMzM2LDcgKzMzNSw3IEBAIHZ0 YWJsZS1yZW1vdmUtb2JqZWN0CiAgIDs7IFRoZW4gYWRqdXN0IHRoZSBjYWNoZSBhbmQgZGlzcGxh eS4KICAgKHNhdmUtZXhjdXJzaW9uCiAgICAgKHZ0YWJsZS1nb3RvLXRhYmxlIHRhYmxlKQotICAg IChsZXQgKChjYWNoZSAodnRhYmxlLS1jdXJyZW50LWNhY2hlKSkKKyAgICAobGV0ICgoY2FjaGUg KHZ0YWJsZS0tY2FjaGUpKQogICAgICAgICAgIChpbmhpYml0LXJlYWQtb25seSB0KSkKICAgICAg IChzZXRjYXIgY2FjaGUgKGRlbHEgKGFzc3Egb2JqZWN0ICh2dGFibGUtLWNhY2hlLWxpbmVzIGNh Y2hlKSkKICAgICAgICAgICAgICAgICAgICAgICAgICAgKHZ0YWJsZS0tY2FjaGUtbGluZXMgY2Fj aGUpKSkKQEAgLTQwMCw3ICszOTksNyBAQCB2dGFibGUtaW5zZXJ0LW9iamVjdAogICAgIDs7IFRo ZW4gYWRqdXN0IHRoZSBjYWNoZSBhbmQgZGlzcGxheS4KICAgICAoc2F2ZS1leGN1cnNpb24KICAg ICAgICh2dGFibGUtZ290by10YWJsZSB0YWJsZSkKLSAgICAgIChsZXQqICgoY2FjaGUgKHZ0YWJs ZS0tY3VycmVudC1jYWNoZSkpCisgICAgICAobGV0KiAoKGNhY2hlICh2dGFibGUtLWNhY2hlKSkK ICAgICAgICAgICAgICAoaW5oaWJpdC1yZWFkLW9ubHkgdCkKICAgICAgICAgICAgICAoa2V5bWFw IChnZXQtdGV4dC1wcm9wZXJ0eSAocG9pbnQpICdrZXltYXApKQogICAgICAgICAgICAgIChlbGxp cHNpcyAoaWYgKHZ0YWJsZS1lbGxpcHNpcyB0YWJsZSkKQEAgLTUyOCwxNSArNTI3LDkgQEAgdnRh YmxlLWluc2VydAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAnZmFjZSAodnRh YmxlLWZhY2UgdGFibGUpKQogICAgICAgICAgICAgICAgICAgICAgIiIpKQogICAgICAgICAgKGVs bGlwc2lzLXdpZHRoIChzdHJpbmctcGl4ZWwtd2lkdGggZWxsaXBzaXMpKQotICAgICAgICAgOzsg V2UgbWFpbnRhaW4gYSBjYWNoZSBwZXIgc2NyZWVuL3dpbmRvdyB3aWR0aCwgc28gdGhhdCB3ZSBy ZW5kZXIKLSAgICAgICAgIDs7IGNvcnJlY3RseSBpZiBFbWFjcyBpcyBvcGVuIG9uIHR3byBkaWZm ZXJlbnQgc2NyZWVucyAob3IgdGhlCi0gICAgICAgICA7OyB1c2VyIHJlc2l6ZXMgdGhlIGZyYW1l KS4KLSAgICAgICAgIChjYWNoZSAob3IgKGdldGhhc2ggKHZ0YWJsZS0tY2FjaGUta2V5KSAoc2xv dC12YWx1ZSB0YWJsZSAnLWNhY2hlKSkKLSAgICAgICAgICAgICAgICAgICAgKGxldCogKChkYXRh ICh2dGFibGUtLWNvbXB1dGUtY2FjaGUgdGFibGUpKQotICAgICAgICAgICAgICAgICAgICAgICAg ICAgKHdpZHRocyAodnRhYmxlLS1jb21wdXRlLXdpZHRocyB0YWJsZSBkYXRhKSkpCi0gICAgICAg ICAgICAgICAgICAgICAgKHNldGYgKGdldGhhc2ggKHZ0YWJsZS0tY2FjaGUta2V5KSAoc2xvdC12 YWx1ZSB0YWJsZSAnLWNhY2hlKSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAobGlzdCBk YXRhIHdpZHRocykpKSkpCi0gICAgICAgICAod2lkdGhzICh2dGFibGUtLWNhY2hlLXdpZHRocyBj YWNoZSkpKQorICAgICAgICAgKGRhdGEgKHZ0YWJsZS0tY29tcHV0ZS1jYWNoZSB0YWJsZSkpCisg ICAgICAgICAod2lkdGhzICh2dGFibGUtLWNvbXB1dGUtd2lkdGhzIHRhYmxlIGRhdGEpKQorICAg ICAgICAgKGNhY2hlIChsaXN0IGRhdGEgd2lkdGhzKSkpCiAgICAgOzsgRG9uJ3QgaW5zZXJ0IGFu eSBoZWFkZXIgb3IgaGVhZGVyIGxpbmUgaWYgdGhlIHVzZXIgaGFzbid0CiAgICAgOzsgc3BlY2lm aWVkIHRoZSBjb2x1bW5zLgogICAgICh3aGVuIChzbG90LXZhbHVlIHRhYmxlICctaGFzLWNvbHVt bi1zcGVjKQpAQCAtNjYxLDIyICs2NTQsMTUgQEAgdnRhYmxlLS1pbnNlcnQtbGluZQogICAgICAg ICAgc3RhcnQgKHBvaW50KQogICAgICAgICAgKGVsdCByb3ctY29sb3JzIChtb2QgbGluZS1udW1i ZXIgKGxlbmd0aCByb3ctY29sb3JzKSkpKSkpKSkKIAotKGRlZnVuIHZ0YWJsZS0tY2FjaGUta2V5 ICgpCi0gIChjb25zIChmcmFtZS10ZXJtaW5hbCkgKHdpbmRvdy13aWR0aCkpKQotCi0oZGVmdW4g dnRhYmxlLS1jdXJyZW50LWNhY2hlICgpCisoZGVmdW4gdnRhYmxlLS1jYWNoZSAoKQogICAiUmV0 dXJuIHRoZSBjdXJyZW50IGNhY2hlIGZvciB0aGUgdGFibGUgYXQgcG9pbnQuCiAKIEluIGB2dGFi bGUtaW5zZXJ0JywgdGhlIGxpbmVzIGFuZCB3aWR0aHMgb2YgdGhlIHZ0YWJsZSB0ZXh0IGFyZSBj b21wdXRlZAogYmFzZWQgb24gdGhlIGN1cnJlbnQgc2VsZWN0ZWQgZnJhbWUgYW5kIHdpbmRvdyBh bmQgc3RvcmVkIGluIGEgY2FjaGUuCiBTdWJzZXF1ZW50IGludGVyYWN0aW9uIHdpdGggdGhlIHRl eHQgb2YgdGhlIHZ0YWJsZSBzaG91bGQgdXNlIHRoYXQgY2FjaGUKLXZpYSB0aGlzIGZ1bmN0aW9u IHJhdGhlciB0aGFuIGJ5IGNhbGxpbmcgYHZ0YWJsZS0tY2FjaGUta2V5JyB0byBsb29rIHVwCi10 aGUgY2FjaGUuIgordmlhIHRoaXMgZnVuY3Rpb24uIgogICAoZ2V0LXRleHQtcHJvcGVydHkgKHBv aW50KSAndnRhYmxlLWNhY2hlKSkKIAotKGRlZnVuIHZ0YWJsZS0tY2xlYXItY2FjaGUgKHRhYmxl KQotICAoc2V0ZiAoZ2V0aGFzaCAodnRhYmxlLS1jYWNoZS1rZXkpIChzbG90LXZhbHVlIHRhYmxl ICctY2FjaGUpKSBuaWwpKQotCiAoZGVmdW4gdnRhYmxlLS1zb3J0ICh0YWJsZSBjYWNoZSkKICAg KHBjYXNlLWRvbGlzdCAoYCgsaW5kZXggLiAsZGlyZWN0aW9uKSAodnRhYmxlLXNvcnQtYnkgdGFi bGUpKQogICAgIChsZXQgKChudW1lcmljYWwgKHZ0YWJsZS1jb2x1bW4tLW51bWVyaWNhbApAQCAt MTAwNiw3ICs5OTIsNyBAQCB2dGFibGUtbmFycm93LWN1cnJlbnQtY29sdW1uCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICgtICgqICh2dGFibGUtLWNoYXItd2lkdGggdGFibGUpIChv ciBuIDEpKSkpKSkKIAogKGRlZnVuIHZ0YWJsZS0tYWx0ZXItY29sdW1uLXdpZHRoICh0YWJsZSBj b2x1bW4gZGVsdGEpCi0gIChsZXQgKCh3aWR0aHMgKHZ0YWJsZS0tY2FjaGUtd2lkdGhzICh2dGFi bGUtLWN1cnJlbnQtY2FjaGUpKSkpCisgIChsZXQgKCh3aWR0aHMgKHZ0YWJsZS0tY2FjaGUtd2lk dGhzICh2dGFibGUtLWNhY2hlKSkpKQogICAgIChzZXRmIChhcmVmIHdpZHRocyBjb2x1bW4pCiAg ICAgICAgICAgKG1heCAoKiAodnRhYmxlLS1jaGFyLXdpZHRoIHRhYmxlKSAyKQogICAgICAgICAg ICAgICAgKCsgKGFyZWYgd2lkdGhzIGNvbHVtbikgZGVsdGEpKSkKQEAgLTEwMjgsMTQgKzEwMTQs MTQgQEAgdnRhYmxlLXByZXZpb3VzLWNvbHVtbgogICAoaW50ZXJhY3RpdmUpCiAgICh2dGFibGUt Z290by1jb2x1bW4KICAgIChtYXggMCAoMS0gKG9yICh2dGFibGUtY3VycmVudC1jb2x1bW4pCi0g ICAgICAgICAgICAgICAgICAobGVuZ3RoICh2dGFibGUtLWNhY2hlLXdpZHRocyAodnRhYmxlLS1j dXJyZW50LWNhY2hlKSkpKSkpKSkKKyAgICAgICAgICAgICAgICAgIChsZW5ndGggKHZ0YWJsZS0t Y2FjaGUtd2lkdGhzICh2dGFibGUtLWNhY2hlKSkpKSkpKSkKIAogKGRlZnVuIHZ0YWJsZS1uZXh0 LWNvbHVtbiAoKQogICAiR28gdG8gdGhlIG5leHQgY29sdW1uLiIKICAgKGludGVyYWN0aXZlKQog ICAod2hlbiAodnRhYmxlLWN1cnJlbnQtY29sdW1uKQogICAgICh2dGFibGUtZ290by1jb2x1bW4K LSAgICAgKG1pbiAoMS0gKGxlbmd0aCAodnRhYmxlLS1jYWNoZS13aWR0aHMgKHZ0YWJsZS0tY3Vy cmVudC1jYWNoZSkpKSkKKyAgICAgKG1pbiAoMS0gKGxlbmd0aCAodnRhYmxlLS1jYWNoZS13aWR0 aHMgKHZ0YWJsZS0tY2FjaGUpKSkpCiAgICAgICAgICAgKDErICh2dGFibGUtY3VycmVudC1jb2x1 bW4pKSkpKSkKIAogKGRlZnVuIHZ0YWJsZS1yZXZlcnQtY29tbWFuZCAoKQpAQCAtMTA0Myw4ICsx MDI5LDcgQEAgdnRhYmxlLXJldmVydC1jb21tYW5kCiAgIChpbnRlcmFjdGl2ZSkKICAgKGxldCAo KHRhYmxlICh2dGFibGUtY3VycmVudC10YWJsZSkpKQogICAgICh3aGVuICh2dGFibGUtb2JqZWN0 cy1mdW5jdGlvbiB0YWJsZSkKLSAgICAgIChzZXRmICh2dGFibGUtb2JqZWN0cyB0YWJsZSkgKGZ1 bmNhbGwgKHZ0YWJsZS1vYmplY3RzLWZ1bmN0aW9uIHRhYmxlKSkpKQotICAgICh2dGFibGUtLWNs ZWFyLWNhY2hlIHRhYmxlKSkKKyAgICAgIChzZXRmICh2dGFibGUtb2JqZWN0cyB0YWJsZSkgKGZ1 bmNhbGwgKHZ0YWJsZS1vYmplY3RzLWZ1bmN0aW9uIHRhYmxlKSkpKSkKICAgKHZ0YWJsZS1yZXZl cnQpKQogCiAoZGVmdW4gdnRhYmxlLXNvcnQtYnktY3VycmVudC1jb2x1bW4gKCkKLS0gCjIuNDcu MQoK --000000000000d976ec0643e51ae2--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 20:47:35 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 15:47:35 2025 Received: from localhost ([127.0.0.1]:59713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLSbu-000201-PI for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:47:35 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:35591) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vLSbs-0001zm-Pl for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:47:33 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el In-Reply-To: <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> (=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Tue, 18 Nov 2025 15:43:40 -0500") 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> Date: Tue, 18 Nov 2025 15:47:27 -0500 Message-ID: <iera50jgja8.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1763498847; bh=VeInqlKZh5DVh7K1j/4lC8g3RQkw8exbGebsgEFdQW8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=w0qb9idg8VKjolSMyRY97DigpfVAAGYnrHPNYOp9J8rB41wqVC9Yez83wBgExP+Za AwKDxyF4PioRQo5ubiTPypJiuW0WP+Mmc2sOsZdsBxiQ0SDCvtLdmE0Ocg57jvEGfQ 302y63kbzATmpz0gh+xtVDBye6XVYcZPZnsyFZHQKdWlfVr+WbvPGHmfTOAM8UMpbX qZSUwTpItEcrXKJ97XYbdYvBkCrytgRUoRgR4YJk10YiUHV05akdTKt2wKhPQT9NyQ 7aCTzdniFGPJAIqhzAZCgTo3wJv0no4K94byHDmIDiyCgUAU8PuvvAEclco3LRb6Nd 0+ojOxZ9NO7Ng== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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 (---) St=C3=A9phane Marks <shipmints@HIDDEN> writes: > On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <sbaugh@janestreet.= com> wrote: > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh@janestre= et.com> wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > Alright! Hand becoming sufficiently usable! Sorry for the delay. > > > > > > Spencer, can you take a quick look at the patch you provided via > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > > it does not pass the vtable tests (which we will beef up, and get r= id of the typo in the first test name). > > > > Thanks for checking, apologies about that, it was just an error > > introduced when I ported the patch forward from emacs-30 (which is wh= at > > we use at my site). > > > > Fixed it, this version should be correct. > > > > Thank you. Tests pass. > > > > I think we should eliminate the slot -cache and get rid of the cache k= ey entirely (the slot being superseded by the > vtable-cache > > text property). Each time the cache needs to be refreshed, the user r= uns vtable-revert which repopulates the now sole > cache.=20 > > Leaving the remnants of the old mechanism in place will confuse people= . I also think we should rename current-cache to > just > > cache. If agreed, I'll finish this patch by removing the remnants. > > Feel free to try it; please send your patch as a diff on top of mine so > I can review it. > > Note that we still need something like the cache key just to know when > we need to invalidate the cache. And when we revert the vtable we > currently grab the cache out of the slot -cache; we'll need to change > the code to grab the cache out of the text properties before we erase > the previously inserted table. > > I don't think explicit cache invalidation is needed. If the displays a v= table in another window of a different size, or resizes the > current window, they have to vtable-revert anyway, right? Yes. vtable-revert calls vtable-insert which doesn't clear the cache if the cache key is the same, so it doesn't recompute the cached data.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 20:44:04 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 15:44:04 2025 Received: from localhost ([127.0.0.1]:59695 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLSYV-0001nM-KN for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:44:04 -0500 Received: from mail-vs1-xe2d.google.com ([2607:f8b0:4864:20::e2d]:43278) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vLSYT-0001mg-PC for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:44:02 -0500 Received: by mail-vs1-xe2d.google.com with SMTP id ada2fe7eead31-5dbde7f4341so178143137.1 for <69837 <at> debbugs.gnu.org>; Tue, 18 Nov 2025 12:44:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763498636; x=1764103436; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Sfd+v99putfy4UyWplEO0UassZLEpiXHdH9y7Wxzx+E=; b=A7jkrmaRDjbsgsd3+jAlM5QAUhe366gHYtDTttlHEnRBVAucKN3PnAHZI2xhUA1oZB sIw4hVreBwPa6wFhUggBun8BmAlxhxhWHMrP++0KcYdc0IX4mAd0ChP0I6cnLot3mpCU ssviTuRhouzPlFI3Rz3vzAlTLLAaP7pOlAouw/01KrDrHHlt/Hddpzzym85gLDEauIbU Svd0p+7tHzzm1Kiq7y8Kql/Irf6yYCJCIvkc+vGDCA9y6JxCsMoDgI2LMFtyzxAz51bJ I3nAauEOlQvmXtCrEXrUZhMu+5fMaaUEi5u9gYoa+rlV9ZIGh9L9OwAEfcY6Grt0yYfO 8KHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763498636; x=1764103436; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=Sfd+v99putfy4UyWplEO0UassZLEpiXHdH9y7Wxzx+E=; b=pmd6eOA9oKSM+QNAvsXVt880nzoCHuJ+eBzAHtjSX7Y5HMI5O6L7sUUyTzIHAD37Dv C2rC9UrE5NfUvC7e8MKGkx37Sz+u8HSSFSKNXYy7ZKIQTIWs5C9+gwZibUaW3j/yXs7a UC+iAm2e13ZJAAkH9YpMdVo26Ge4a6+29UAG5kUZBK6WbEJoa8/AMsPYL2Dr2vOMUK4z K2Fjnal2VbaWvHEEtCSE+nCpGhhM+0z5YOH2V1pli40UJxjWlWDPCGDEuys7oQWDh2Jq eh4kA4ieaVLIT4pEO+m1Wqa3loVdWD56IXDOgulobxBz10oPKpLQ1nrYO7NlXVKtBzY6 alYg== X-Forwarded-Encrypted: i=1; AJvYcCVAhE7/j4KaH6ve9mOY6350GfJStmJ8XLt7SBBLNceY0ODlmwXjue1vURq74E/tG1LPB2BiLw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzcVwckcfW5leIvZ0cWGMQCdErtgegfarkHuI6i6B7xYLXe998W ++pTBC0nrm74BhM9mT5MVeSdb5NJyPEz0rfhWcz7hI5O6wgrq2Z+oyZb80TirsqrC4tJwwyTKOx 1ywHrQ6ByyoE84azBikYQsG+GZMKNRd8= X-Gm-Gg: ASbGnctmD02YHWP0DBKp+g4U+5ACya1RKxAZ+G/ZcrzRg36y6Aln3PE2gwy+P5kD9xN 3vsV6Nj07geGelKhfC4RrSu/HwKfcm95tZo3n8GqKZrAgmwAGsD77cFapkuA3hpgRuB+wKyiWVw Ld2T/WAVKAtH4ivmlT28J5hm6dwvF+BTx/HpZc4aiRJf362jNYnLYMqZRmaPw1hFFHqoJCaX4CZ 8Pfzzy//STLrx3opQOcrz1toWgi8q62wYBOeVhXhGGKJtGpb/EJM4Jfh+66ZIkDeDozsdX98h1P /KmmTw== X-Google-Smtp-Source: AGHT+IGrEps0IgejgQaom/v5J+wHgTLhxfcsCp759/TxRCM8Bq+hIzZUfNFy5ru8KISkv1fIFnk4KWtsnncUgf6REdI= X-Received: by 2002:a05:6102:e0b:b0:5df:ab05:d84d with SMTP id ada2fe7eead31-5e1a7516e6bmr12846137.20.1763498635990; Tue, 18 Nov 2025 12:43:55 -0800 (PST) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> <iercy5fgjm0.fsf@HIDDEN> In-Reply-To: <iercy5fgjm0.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Tue, 18 Nov 2025 15:43:40 -0500 X-Gm-Features: AWmQ_bkct7GubhgjtCjba_r-svZbqS7BcelsXhJ_oqB_GVahyNdm8bbpSsOzZMI Message-ID: <CAN+1Hbq7FWi-NOnoyz_4bwEfAHp5VEM1YaFN9HarUKre_Z6AZQ@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000c298df0643e48597" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --000000000000c298df0643e48597 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh@janestree= t.com> > wrote: > > > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > > Alright! Hand becoming sufficiently usable! Sorry for the delay. > > > > > > Spencer, can you take a quick look at the patch you provided via > > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > > it does not pass the vtable tests (which we will beef up, and get ri= d > of the typo in the first test name). > > > > Thanks for checking, apologies about that, it was just an error > > introduced when I ported the patch forward from emacs-30 (which is wha= t > > we use at my site). > > > > Fixed it, this version should be correct. > > > > Thank you. Tests pass. > > > > I think we should eliminate the slot -cache and get rid of the cache ke= y > entirely (the slot being superseded by the vtable-cache > > text property). Each time the cache needs to be refreshed, the user > runs vtable-revert which repopulates the now sole cache. > > Leaving the remnants of the old mechanism in place will confuse people. > I also think we should rename current-cache to just > > cache. If agreed, I'll finish this patch by removing the remnants. > > Feel free to try it; please send your patch as a diff on top of mine so > I can review it. > > Note that we still need something like the cache key just to know when > we need to invalidate the cache. And when we revert the vtable we > currently grab the cache out of the slot -cache; we'll need to change > the code to grab the cache out of the text properties before we erase > the previously inserted table. > I don't think explicit cache invalidation is needed. If the displays a vtable in another window of a different size, or resizes the current window, they have to vtable-revert anyway, right? --000000000000c298df0643e48597 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Tue, Nov 18, 2025 at 3:40=E2=80=AFPM Spencer Baugh <<a href=3D"mailto= :sbaugh@HIDDEN">sbaugh@HIDDEN</a>> wrote:</span></div></= div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">St=C3=A9phane Marks <<a href=3D"mailto:shipm= ints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> <br> > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <<a href=3D"m= ailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</a>>= ; wrote:<br> ><br> >=C2=A0 St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" t= arget=3D"_blank">shipmints@HIDDEN</a>> writes:<br> >=C2=A0 > Alright! Hand becoming sufficiently usable! Sorry for the d= elay.<br> >=C2=A0 ><br> >=C2=A0 > Spencer, can you take a quick look at the patch you provide= d via<br> >=C2=A0 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch<= br> >=C2=A0 > it does not pass the vtable tests (which we will beef up, a= nd get rid of the typo in the first test name).<br> ><br> >=C2=A0 Thanks for checking, apologies about that, it was just an error<= br> >=C2=A0 introduced when I ported the patch forward from emacs-30 (which = is what<br> >=C2=A0 we use at my site).<br> ><br> >=C2=A0 Fixed it, this version should be correct.<br> ><br> > Thank you.=C2=A0 Tests pass.<br> ><br> > I think we should eliminate the slot -cache and get rid of the cache k= ey entirely (the slot being superseded by the vtable-cache<br> > text property).=C2=A0 Each time the cache needs to be refreshed, the u= ser runs vtable-revert which repopulates the now sole cache. <br> > Leaving the remnants of the old mechanism in place will confuse people= .=C2=A0 I also think we should rename current-cache to just<br> > cache.=C2=A0 If agreed, I'll finish this patch by removing the rem= nants.<br> <br> Feel free to try it; please send your patch as a diff on top of mine so<br> I can review it.<br> <br> Note that we still need something like the cache key just to know when<br> we need to invalidate the cache.=C2=A0 And when we revert the vtable we<br> currently grab the cache out of the slot -cache; we'll need to change<b= r> the code to grab the cache out of the text properties before we erase<br> the previously inserted table.<br></blockquote><div><br></div><div class=3D= "gmail_default" style=3D"font-family:monospace">I don't think explicit = cache invalidation is needed.=C2=A0 If the displays a vtable in another win= dow of a different size, or resizes the current window, they have to vtable= -revert anyway, right?</div></div></div> --000000000000c298df0643e48597--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 20:40:31 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 15:40:31 2025 Received: from localhost ([127.0.0.1]:59688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLSV4-0001gn-PJ for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:40:31 -0500 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:45333) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1vLSV3-0001gR-6L for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:40:29 -0500 From: Spencer Baugh <sbaugh@HIDDEN> To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el In-Reply-To: <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> (=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Tue, 18 Nov 2025 15:28:51 -0500") 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> Date: Tue, 18 Nov 2025 15:40:23 -0500 Message-ID: <iercy5fgjm0.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1763498423; bh=ygqVwwpU1G9FvIFkRdhtOlwC6R8Pi1I088OV9DQm1kI=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=SSeuX9PDF1tjjYGZnvCVUklHu+1ZExFNwqwKshaM8nDTRXkRLl1JyYFK3+eSK5oR7 BpCqHmf0rmb1hfjsnoluMVN4K2XcAtpnQpZuL9pxkj7QpD0J1TlvR9k1lVQY9xdsfW 0N2r//I4AfziDNYvHXhDDK5nXiY090fhtYwg3pnzo6Z2Y44HAXtZI7i38fJILxNKm/ Ai5fUW1rxm0JocLDulM5MW3e0iH32FYtzBI5fSw/8Afebhqzpas+xXuzx2yNmuWGtx +iEP/28RGhTvggXbrW5REO6xiIrLuYu8wVzGnSpqoYuzMNd4/dYS1J148H2Weq0Ud3 opmi3jtXfEI0w== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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 (---) St=C3=A9phane Marks <shipmints@HIDDEN> writes: > On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh@janestreet.= com> wrote: > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > Alright! Hand becoming sufficiently usable! Sorry for the delay. > > > > Spencer, can you take a quick look at the patch you provided via > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > it does not pass the vtable tests (which we will beef up, and get rid = of the typo in the first test name). > > Thanks for checking, apologies about that, it was just an error > introduced when I ported the patch forward from emacs-30 (which is what > we use at my site). > > Fixed it, this version should be correct. > > Thank you. Tests pass. > > I think we should eliminate the slot -cache and get rid of the cache key = entirely (the slot being superseded by the vtable-cache > text property). Each time the cache needs to be refreshed, the user runs= vtable-revert which repopulates the now sole cache.=20 > Leaving the remnants of the old mechanism in place will confuse people. = I also think we should rename current-cache to just > cache. If agreed, I'll finish this patch by removing the remnants. Feel free to try it; please send your patch as a diff on top of mine so I can review it. Note that we still need something like the cache key just to know when we need to invalidate the cache. And when we revert the vtable we currently grab the cache out of the slot -cache; we'll need to change the code to grab the cache out of the text properties before we erase the previously inserted table.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Nov 2025 20:29:15 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Tue Nov 18 15:29:15 2025 Received: from localhost ([127.0.0.1]:59632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1vLSKB-0000zo-3U for submit <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:29:15 -0500 Received: from mail-vk1-xa33.google.com ([2607:f8b0:4864:20::a33]:60788) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1vLSK8-0000zV-KD for 69837 <at> debbugs.gnu.org; Tue, 18 Nov 2025 15:29:13 -0500 Received: by mail-vk1-xa33.google.com with SMTP id 71dfb90a1353d-55b2f2ae1cbso2371544e0c.1 for <69837 <at> debbugs.gnu.org>; Tue, 18 Nov 2025 12:29:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1763497747; x=1764102547; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=esEVRAYNH8HAYS45ssM84zyP1ZziJOLqptl8rNeyEc0=; b=dHvnFJRckNfboheaXNPPyUhgn0OKDlIWshy3E2Dz5tRh2REMwdZaXbcbrMZyI+Nn9Q IHow/CS3z32BH6chcYmE3SdkM2dhvfpA63I3FW35Xgd52S6Hs/c6tjHx/kqAHheh2X+e y37dfmN4bDbqNIdoOGNPrkGHIP+B0USbG6tXhUHKLVh1kcSSPkI3QorLQ9llh6NqfL2I ThQ21wxCn5PMSh481HtxSZ6IV498v4x0kmKbWF3mP0aqJma3wqhGc41UrCpQQ2jYziue BrXkv/65NEsBB3ED8alRm3EXBTer/krknjHtAnmvr3KWxzamkiViQlEtrcFEmLAqX+3H hwQg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1763497747; x=1764102547; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=esEVRAYNH8HAYS45ssM84zyP1ZziJOLqptl8rNeyEc0=; b=BOWWXM21IjYsoji2Hh5wv/jaipNUE0hxA7EqO6fIJetI5nnZbnlDoPv1YsP2XQEI78 sChgM3n/4jcpatZO0Vyyu2+mri1YV1uf0QKtFGkqpeKr6cmPGbX8pK5daS3wVcJrUJXG dMCXpKyj/L5OiDnsNTT4T495gHScDWaaZaRFJ1qvcXHUx9Ufy4QSISwC4fTC95z30ml5 whM5kwDxAI4V4cJpXk0l5NiUcXyT10B5VOvOw8HSVztthaHVUMUQwo5LdvcUB/1EbSYM ki9QkwU3c91y2Y8r4w6yqmIcsQihege6gt9WspH9YuOR/XhhP0qGM1xBUrFTs+Yns03l xz9g== X-Forwarded-Encrypted: i=1; AJvYcCWDNpGXzm8rD+W/6KtoQvpkDtWCnVY87QjEByUP7RECEFnG47FZM2ANPQNy9H5XVo4cOt6/8Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0YxW9MtZswmIrL0fcKIF0gBtRmGeJKYZ/QgNd2EZUsCAYsja2GFS 2aIWn3Z0qUjFtdkgmsxdKK0NimFRP1QhLlUAPx5V8VOwApo2Y2cEKj5207/ygan/TwqO61RO2Nx rmDo2+WT7COy6TegaLmVurOyk8SjEYbY= X-Gm-Gg: ASbGncuY7xne3DbyJ7C3K2Ukw67mZrQvYP4iWIXs/ekrBPY9kD9q01H8KeuhLi4cvZa /3mjkAmJhbC44yyxSReFoAXLLPVybqUGwX2WVBtdq3K2s8d4D1t6OAF5DIpX70bjAnmrFo2McGn Z13O5XVfrbWaMLnvYfE9TIHsPiIr5I78SmFb34sse1uYfokQpBgd3G+lVZtZcOQj0/uZCr+q94E KmaI3ikkGcuhRQGrGS4I49FLyTytPyJ6ZBSHI7TzMtCnB4pnY+oL+0X6SKP6s0oOHSSX3g= X-Google-Smtp-Source: AGHT+IHj1uJmPgv8pZDx/73sXO3/1rY9TIA+Flhi9nKZ11sGfPtIFc/H/sxo5mGDdHRQ+8liRJyDnkT03XTcpf+8wiI= X-Received: by 2002:a05:6102:8026:b0:5db:f424:5b9f with SMTP id ada2fe7eead31-5dfc5b722bamr6521095137.25.1763497746887; Tue, 18 Nov 2025 12:29:06 -0800 (PST) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN> <ierqzu57asi.fsf@HIDDEN> In-Reply-To: <ierqzu57asi.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Tue, 18 Nov 2025 15:28:51 -0500 X-Gm-Features: AWmQ_bma3rp-uvFdDTN0SI92uP4g9g579iZwouslGgqscQQNRILmqe5BexYuB2g Message-ID: <CAN+1Hbo-p2DC8RqmVVkjTUrhsqNw17aYWTHTD4LEpv-UZ7v7yg@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000c3f7070643e450ae" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --000000000000c3f7070643e450ae Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > Alright! Hand becoming sufficiently usable! Sorry for the delay. > > > > Spencer, can you take a quick look at the patch you provided via > 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch > > it does not pass the vtable tests (which we will beef up, and get rid o= f > the typo in the first test name). > > Thanks for checking, apologies about that, it was just an error > introduced when I ported the patch forward from emacs-30 (which is what > we use at my site). > > Fixed it, this version should be correct. Thank you. Tests pass. I think we should eliminate the slot -cache and get rid of the cache key entirely (the slot being superseded by the vtable-cache text property). Each time the cache needs to be refreshed, the user runs vtable-revert which repopulates the now sole cache. Leaving the remnants of the old mechanism in place will confuse people. I also think we should rename current-cache to just cache. If agreed, I'll finish this patch by removing the remnants. --000000000000c3f7070643e450ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Mon, Nov 10, 2025 at 6:00=E2=80=AFPM Spencer Baugh <<a href=3D"mailto= :sbaugh@HIDDEN">sbaugh@HIDDEN</a>> wrote:</span></div></= div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">St=C3=A9phane Marks <<a href=3D"mailto:shipm= ints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> > Alright! Hand becoming sufficiently usable! Sorry for the delay.<br> ><br> > Spencer, can you take a quick look at the patch you provided via 0001-= Fix-implicit-usage-of-the-current-window-width-in-vt.patch<br> > it does not pass the vtable tests (which we will beef up, and get rid = of the typo in the first test name).<br> <br> Thanks for checking, apologies about that, it was just an error<br> introduced when I ported the patch forward from emacs-30 (which is what<br> we use at my site).<br> <br> Fixed it, this version should be correct<span class=3D"gmail_default" style= =3D"font-family:monospace">.</span></blockquote><div><br></div><div class= =3D"gmail_default" style=3D"font-family:monospace">Thank you.=C2=A0 Tests p= ass.</div><div class=3D"gmail_default" style=3D"font-family:monospace"><br>= </div><div class=3D"gmail_default" style=3D"font-family:monospace">I think = we should eliminate=C2=A0the slot -cache and get rid of the cache key entir= ely (the slot being superseded by the vtable-cache text property).=C2=A0 Ea= ch time the cache needs to be refreshed, the user runs vtable-revert which = repopulates the now sole cache.=C2=A0 Leaving the remnants of the old mecha= nism in place will confuse people.=C2=A0 I also think we should rename curr= ent-cache to just cache.=C2=A0 If agreed, I'll finish this patch by rem= oving the remnants.</div></div></div> --000000000000c3f7070643e450ae--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.
Received: (at 69837) by debbugs.gnu.org; 10 Nov 2025 23:00:54 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Nov 10 18:00:54 2025
Received: from localhost ([127.0.0.1]:40736 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vIasX-0005OJ-Ib
for submit <at> debbugs.gnu.org; Mon, 10 Nov 2025 18:00:54 -0500
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:56787)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1vIasU-000566-Sm
for 69837 <at> debbugs.gnu.org; Mon, 10 Nov 2025 18:00:51 -0500
From: Spencer Baugh <sbaugh@HIDDEN>
To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN>
Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible
windows, [PATCH] Fix implicit usage of the current window-width in
vtable.el
In-Reply-To: <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN>
(=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Thu, 30 Oct 2025
17:41:48 -0400")
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>
<86frvy3fci.fsf@HIDDEN>
<CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN>
<ierwm97jtwb.fsf@HIDDEN>
<CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN>
<iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN>
<CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN>
<CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN>
<CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN>
<ierfrcjsh3q.fsf@HIDDEN>
<CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN>
<CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN>
Date: Mon, 10 Nov 2025 18:00:45 -0500
Message-ID: <ierqzu57asi.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1762815645;
bh=wXY8zM6uVJxhTRzQwiwhXcdg39Z5hizoJOMo55cknEc=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=M9/0+z2GAp3kIpH0oWPZrfPvtlJv5a27ntUDsjNnSyfLNZSyDnU6gVCylQJ0UOoPu
j2bgRQ0NTpBZUKzIqF1yN2L7YistXCBWq7CnDzyHieL7KXl3OCK+uYvr5LydjAIdBk
uSVmjkzl2LoCaR/JPNFT93rX3OyXjFBWsKih8F0gkr6dXbKy6qB665fWfelfpmv0tC
HBX2cZupE2jXnY/f980bsr0uAryVJGS1b+325a549nXlJLg4SjUL6ypDG9Hxx5wi32
Eovnr/BaqeZl1z83dlazEwqDS42Nvrulgk/9GZ99GfoywadoHJXi+kD9mLmNpSZwCp
Yq+yWqkuVm69Q==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 69837
Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org,
Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
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 (---)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
St=C3=A9phane Marks <shipmints@HIDDEN> writes:
> Alright! Hand becoming sufficiently usable! Sorry for the delay.
>
> Spencer, can you take a quick look at the patch you provided via 0001-Fix=
-implicit-usage-of-the-current-window-width-in-vt.patch
> it does not pass the vtable tests (which we will beef up, and get rid of =
the typo in the first test name).
Thanks for checking, apologies about that, it was just an error
introduced when I ported the patch forward from emacs-30 (which is what
we use at my site).
Fixed it, this version should be correct.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch
From e8a90f0942fa09f8168c4fb9619144c52b0676eb Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Thu, 19 Jun 2025 17:20:12 -0400
Subject: [PATCH] Fix implicit usage of the current window-width in vtable.el
Previously, many functions in vtable.el called vtable--cache,
which computed vtable--cache-key based on the current selected
window and frame; this could cause vtable functions to fail or
misbehave if they were not called from the selected window and
frame that vtable-insert was last called in.
Now, the vtable cache is stored with the text of the vtable, so
that functions which need to interact with some vtable text can
do so reliably without having to use the same selected window
and frame.
Also, vtable-update-object has always required TABLE to be
present at point in the current buffer; now its docstring states
this.
* lisp/emacs-lisp/vtable.el (vtable--current-cache)
(vtable--cache-widths, vtable--cache-lines): Add.
(vtable-insert): Save cache in 'vtable-cache.
(vtable--ensure-cache, vtable--recompute-cache): Inline into
vtable-insert.
(vtable--widths, vtable--cache): Delete.
(vtable-update-object): Use vtable--current-cache and update
docstring. (bug#69837)
(vtable-remove-object, vtable-insert-object): Use
vtable--current-cache and save cache in 'vtable-cache.
(vtable--sort, vtable--alter-column-width)
(vtable-previous-column, vtable-next-column): Use
vtable--current-cache.
---
lisp/emacs-lisp/vtable.el | 114 ++++++++++++++++++++------------------
1 file changed, 61 insertions(+), 53 deletions(-)
diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index 00785113edb..bcdd280fb92 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -282,10 +282,9 @@ vtable-update-object
"Update OBJECT's representation in TABLE.
If OLD-OBJECT is non-nil, replace OLD-OBJECT with OBJECT and display it.
In either case, if the existing object is not found in the table (being
-compared with `equal'), signal an error. Note a limitation: if TABLE's
-buffer is not in a visible window, or if its window has changed width
-since it was updated, updating the TABLE is not possible, and an error
-is signaled."
+compared with `equal'), signal an error.
+
+TABLE must be at point in the current buffer."
(unless old-object
(setq old-object object))
(let* ((objects (vtable-objects table))
@@ -299,17 +298,16 @@ vtable-update-object
(while (and (cdr objects)
(not (eq (cadr objects) old-object)))
(setq objects (cdr objects)))
- (unless objects
+ (unless (cdr objects)
(error "Can't find the old object"))
(setcar (cdr objects) object))
- ;; Then update the cache...
- ;; FIXME: If the table's buffer has no visible window, or if its
- ;; width has changed since the table was updated, the cache key will
- ;; not match and the object can't be updated. (Bug #69837).
- (if-let* ((line-number (seq-position (car (vtable--cache table)) old-object
- (lambda (a b)
- (equal (car a) b))))
- (line (elt (car (vtable--cache table)) line-number)))
+ ;; Then update the rendered vtable in the current buffer.
+ (if-let* ((cache (vtable--current-cache))
+ (line-number (seq-position (vtable--cache-lines cache)
+ old-object
+ (lambda (a b)
+ (equal (car a) b))))
+ (line (elt (vtable--cache-lines cache) line-number)))
(progn
(setcar line object)
(setcdr line (vtable--compute-cached-line table object))
@@ -320,10 +318,11 @@ vtable-update-object
(start (point)))
(delete-line)
(vtable--insert-line table line line-number
- (nth 1 (vtable--cache table))
+ (vtable--cache-widths cache)
(vtable--spacer table))
(add-text-properties start (point) (list 'keymap keymap
- 'vtable table))))
+ 'vtable table
+ 'vtable-cache cache))))
;; We may have inserted a non-numerical value into a previously
;; all-numerical table, so recompute.
(vtable--recompute-numerical table (cdr line)))
@@ -335,11 +334,12 @@ vtable-remove-object
;; First remove from the objects.
(setf (vtable-objects table) (delq object (vtable-objects table)))
;; Then adjust the cache and display.
- (let ((cache (vtable--cache table))
- (inhibit-read-only t))
- (setcar cache (delq (assq object (car cache)) (car cache)))
- (save-excursion
- (vtable-goto-table table)
+ (save-excursion
+ (vtable-goto-table table)
+ (let ((cache (vtable--current-cache))
+ (inhibit-read-only t))
+ (setcar cache (delq (assq object (vtable--cache-lines cache))
+ (vtable--cache-lines cache)))
(when (vtable-goto-object object)
(delete-line)))))
@@ -400,7 +400,7 @@ vtable-insert-object
;; Then adjust the cache and display.
(save-excursion
(vtable-goto-table table)
- (let* ((cache (vtable--cache table))
+ (let* ((cache (vtable--current-cache))
(inhibit-read-only t)
(keymap (get-text-property (point) 'keymap))
(ellipsis (if (vtable-ellipsis table)
@@ -408,13 +408,14 @@ vtable-insert-object
'face (vtable-face table))
""))
(ellipsis-width (string-pixel-width ellipsis))
+ (lines (vtable--cache-lines cache))
(elem (if location ; This binding mirrors the binding of `pos' above.
(if (integerp location)
- (nth location (car cache))
- (or (assq location (car cache))
- (and before (caar cache))))
- (if before (caar cache))))
- (pos (memq elem (car cache)))
+ (nth location lines)
+ (or (assq location lines)
+ (and before (car lines))))
+ (if before (car lines))))
+ (pos (memq elem lines))
(line (cons object (vtable--compute-cached-line table object))))
(if (or before
(and pos (integerp location)))
@@ -433,16 +434,17 @@ vtable-insert-object
(forward-line 1) ; Insert *after*.
(vtable-end-of-table)))
;; Otherwise, append the object.
- (setcar cache (nconc (car cache) (list line)))
+ (setcar cache (nconc lines (list line)))
(vtable-end-of-table)))
(let ((start (point)))
;; FIXME: We have to adjust colors in lines below this if we
;; have :row-colors.
(vtable--insert-line table line 0
- (nth 1 cache) (vtable--spacer table)
+ (vtable--cache-widths cache) (vtable--spacer table)
ellipsis ellipsis-width)
(add-text-properties start (point) (list 'keymap keymap
- 'vtable table)))
+ 'vtable table
+ 'vtable-cache cache)))
;; We may have inserted a non-numerical value into a previously
;; all-numerical table, so recompute.
(vtable--recompute-numerical table (cdr line))))))
@@ -512,15 +514,11 @@ vtable--compute-columns
(defun vtable--spacer (table)
(vtable--compute-width table (vtable-separator-width table)))
-(defun vtable--recompute-cache (table)
- (let* ((data (vtable--compute-cache table))
- (widths (vtable--compute-widths table data)))
- (setf (gethash (vtable--cache-key) (slot-value table '-cache))
- (list data widths))))
+(defun vtable--cache-widths (cache)
+ (nth 1 cache))
-(defun vtable--ensure-cache (table)
- (or (vtable--cache table)
- (vtable--recompute-cache table)))
+(defun vtable--cache-lines (cache)
+ (car cache))
(defun vtable-insert (table)
(let* ((spacer (vtable--spacer table))
@@ -533,7 +531,12 @@ vtable-insert
;; 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).
- (widths (nth 1 (vtable--ensure-cache table))))
+ (cache (or (gethash (vtable--cache-key) (slot-value table '-cache))
+ (let* ((data (vtable--compute-cache table))
+ (widths (vtable--compute-widths table data)))
+ (setf (gethash (vtable--cache-key) (slot-value table '-cache))
+ (list data widths)))))
+ (widths (vtable--cache-widths cache)))
;; Don't insert any header or header line if the user hasn't
;; specified the columns.
(when (slot-value table '-has-column-spec)
@@ -546,18 +549,20 @@ vtable-insert
(add-text-properties start (point)
(list 'keymap vtable-header-line-map
'rear-nonsticky t
- 'vtable table))
+ 'vtable table
+ 'vtable-cache cache))
(setq start (point))))
- (vtable--sort table)
+ (vtable--sort table cache)
;; Insert the data.
(let ((line-number 0))
- (dolist (line (car (vtable--cache table)))
+ (dolist (line (vtable--cache-lines cache))
(vtable--insert-line table line line-number widths spacer
ellipsis ellipsis-width)
(setq line-number (1+ line-number))))
(add-text-properties start (point)
(list 'rear-nonsticky t
- 'vtable table))
+ 'vtable table
+ 'vtable-cache cache))
(goto-char start)))
(defun vtable--insert-line (table line line-number widths spacer
@@ -659,16 +664,22 @@ vtable--insert-line
(defun vtable--cache-key ()
(cons (frame-terminal) (window-width)))
-(defun vtable--cache (table)
- (gethash (vtable--cache-key) (slot-value table '-cache)))
+(defun vtable--current-cache ()
+ "Return the current cache for the table at point.
+
+In `vtable-insert', the lines and widths of the vtable text are computed
+based on the current selected frame and window and stored in a cache.
+Subsequent interaction with the text of the vtable should use that cache
+via this function rather than by calling `vtable--cache-key' to look up
+the cache."
+ (get-text-property (point) 'vtable-cache))
(defun vtable--clear-cache (table)
(setf (gethash (vtable--cache-key) (slot-value table '-cache)) nil))
-(defun vtable--sort (table)
+(defun vtable--sort (table cache)
(pcase-dolist (`(,index . ,direction) (vtable-sort-by table))
- (let ((cache (vtable--cache table))
- (numerical (vtable-column--numerical
+ (let ((numerical (vtable-column--numerical
(elt (vtable-columns table) index)))
(numcomp (if (eq direction 'descend)
#'> #'<))
@@ -971,9 +982,6 @@ vtable-revert
(when column
(vtable-goto-column column))))
-(defun vtable--widths (table)
- (nth 1 (vtable--ensure-cache table)))
-
;;; Commands.
(defvar-keymap vtable-header-mode-map
@@ -998,7 +1006,7 @@ vtable-narrow-current-column
(- (* (vtable--char-width table) (or n 1))))))
(defun vtable--alter-column-width (table column delta)
- (let ((widths (vtable--widths table)))
+ (let ((widths (vtable--cache-widths (vtable--current-cache))))
(setf (aref widths column)
(max (* (vtable--char-width table) 2)
(+ (aref widths column) delta)))
@@ -1020,14 +1028,14 @@ vtable-previous-column
(interactive)
(vtable-goto-column
(max 0 (1- (or (vtable-current-column)
- (length (vtable--widths (vtable-current-table))))))))
+ (length (vtable--cache-widths (vtable--current-cache))))))))
(defun vtable-next-column ()
"Go to the next column."
(interactive)
(when (vtable-current-column)
(vtable-goto-column
- (min (1- (length (vtable--widths (vtable-current-table))))
+ (min (1- (length (vtable--cache-widths (vtable--current-cache))))
(1+ (vtable-current-column))))))
(defun vtable-revert-command ()
--
2.43.7
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.
Received: (at 69837) by debbugs.gnu.org; 30 Oct 2025 21:42:20 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Oct 30 17:42:20 2025
Received: from localhost ([127.0.0.1]:37916 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1vEaPO-0006ts-Au
for submit <at> debbugs.gnu.org; Thu, 30 Oct 2025 17:42:19 -0400
Received: from mail-vs1-xe34.google.com ([2607:f8b0:4864:20::e34]:42050)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) (envelope-from <shipmints@HIDDEN>)
id 1vEaPG-0006sv-4J
for 69837 <at> debbugs.gnu.org; Thu, 30 Oct 2025 17:42:08 -0400
Received: by mail-vs1-xe34.google.com with SMTP id
ada2fe7eead31-5d5fbfca7e2so1776595137.0
for <69837 <at> debbugs.gnu.org>; Thu, 30 Oct 2025 14:42:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1761860520; x=1762465320; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:from:to:cc:subject:date:message-id:reply-to;
bh=NEmmv1bdEe7i8uqQSr8KW7AOZD4whfVLSDzmzSiemig=;
b=jaNuboucZ6+5TwCbnN9NvelSHq2n5rw83aakcoUh0iNBV3LbDvH2q6K6HDgUTCR6ZU
bwy+yM/wWRwZNT1/vyPpRcKoWqcE53mGxni40HLAcnJNIYvHcZqjYWcHsgdB/0CsMvmI
S0tG1JYpQ+g4nD9IoUQfSKA6MNwQ7VHJntQ5oW3QFKjuEbiegDyFREnqEvC0Yc5/Pysr
pMEKV4bou1Oe0+/Zy9KiM+SGDHU6IqcGAYeOe95TZCwdrDFf8UjW8xrGv4pi+TPU+wtK
zQ3EE3kP68pHBnjNp6cE+cBEMpH8VS0m4PuHyFYU4JlAh4dwnf/q1Zc/ew6daewuxATE
0HHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1761860520; x=1762465320;
h=cc:to:subject:message-id:date:from:in-reply-to:references
:mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
:reply-to;
bh=NEmmv1bdEe7i8uqQSr8KW7AOZD4whfVLSDzmzSiemig=;
b=VRNZBSrU2AytNTtDn/lLlW7KlbAu2z/OKxu+PIwqTDALDR9QRh+EGP3q5mVr/pJ8Vr
rTypKZGeJvNuqx1mOUMmSBP9XCn1JQAcPyvaSG+9QePD2gs2Oakibuiy0Jn5QFk+jJdp
6TP6WRfn8IM1ZEv5dlz37oAdELCNPK4LugJ8P33xoP8q4DSKBgEKSTdg8hktFgdWd8AD
STttenuptdd6OeIIiCohxp32hmKGgXGdnCojBmQVmukgN+SrWAWI6IQ+OS/Xwh4t25o0
uvqRzwRlYhTE1fxdag6sdcY0dYKg5rCy15FSpi0RHAVsGg3v/wb5TxUuhnxVvCa11x8/
GHWA==
X-Forwarded-Encrypted: i=1;
AJvYcCWhBKaBEAaOtRbtQvxeZJcB+fZ/iTULQ5HIPFULAE42o82+FGiRbmOJZcpWfRHetyjiQaMd7Q==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yy80mYFOHKfTNDk3Xqu2aoYFL/HwSigzrYL2hWCb9+fQu/PM7WE
1vo7UxS6ShHfThW5WQyfi2rUfYdQpsyRcPdKX8GTy3gF9aEW3LWpX4VIGVcxBWK6rxpOtc4t9dT
+JvNzIfUm6V8Zj0zsMXeuGP+6zN0eVNo=
X-Gm-Gg: ASbGncs3x+Dwafbvke8yo09ViexRs+juscPuaUJGj2FwSfwzthOE0vwzV4xHaVoqo9V
r+cSbeqRmEeGPYoyANbzpuOx4Zwwihju9GQG6+pk1B4uCItnMPW1NMJNI8FwGzuWBt3TE8Ekbh6
oqtKwfkiqbTqWmhXfkV0C4lTOICWF02wtDXWDdsU09JJTB7JXSPBRJU6gTgR3Sx43uGHVRtjf2i
+cZHztm+v7KFWmHI1MLqivSK95+3iF3XcQuFJF0jro1i2Qm0OAdCSscnTQGGN/QhCVTemSKNw==
X-Google-Smtp-Source: AGHT+IH/FoZjIXxGEGVhTeZgAOkNLzQ1Ul1xTQFNDzA7MwZJUK/mnqLwlXDBGLt7GMDciHvVCUsAIZiPPe6onxIlXjE=
X-Received: by 2002:a05:6102:dc9:b0:59c:d78:dca with SMTP id
ada2fe7eead31-5dbb02370fcmr589056137.15.1761860519699; Thu, 30 Oct 2025
14:41:59 -0700 (PDT)
MIME-Version: 1.0
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>
<86frvy3fci.fsf@HIDDEN>
<CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN>
<ierwm97jtwb.fsf@HIDDEN>
<CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN>
<iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN>
<CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN>
<CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN>
<CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN>
<ierfrcjsh3q.fsf@HIDDEN>
<CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN>
In-Reply-To: <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN>
From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN>
Date: Thu, 30 Oct 2025 17:41:48 -0400
X-Gm-Features: AWmQ_bmUSkasGaqX-b1e9T1zDbP095fyv5uHJwwrIiDRxkA1rPxr5ZuJK96CkGA
Message-ID: <CAN+1Hbq+GG_Q3j0P3OAZRpCmv-6wNqSQaUA__nDtvuCf6LZvKA@HIDDEN>
Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible
windows, [PATCH] Fix implicit usage of the current window-width in vtable.el
To: Spencer Baugh <sbaugh@HIDDEN>
Content-Type: multipart/alternative; boundary="0000000000006baabb0642671ef7"
X-Spam-Score: 0.0 (/)
X-Debbugs-Envelope-To: 69837
Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org,
Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
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: -1.0 (-)
--0000000000006baabb0642671ef7
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Sep 26, 2025 at 10:09=E2=80=AFAM St=C3=A9phane Marks <shipmints@gma=
il.com> wrote:
> I kind of badly injured my left hand (this is right hand typing) so will
> be back to this when I can function a bit better.
>
> On Thu, Sep 18, 2025 at 3:20=E2=80=AFPM Spencer Baugh <sbaugh@janestreet.=
com>
> wrote:
>
>> St=C3=A9phane Marks <shipmints@HIDDEN> writes:
>> > Thank you for being patient (family, life, and work priorities vs.
>> volunteer time). I've put a lot of work into vtable bug fixes and
>> > improvements, and I'd like to see how much momentum we can foster.
>> >
>> > The proposed patch will mutate only the "current cache" on
>> insert/update/remove objects leaving the other caches invalid, and
>> > when called from a window that doesn't share the cache key's width, th=
e
>> user will need to manually revert to repopulate a cache
>> > of their window's width and reset the "current cache" to avoid cache
>> corruption runtime errors on mutation (I've addressed these
>> > use cases in the larger patch.)
>>
>> That's not true. No corruption can happen with my patch. If you
>> believe otherwise, please give some code which demonstrates it, and we
>> can convert that into a test.
>>
>> > I think we should come to an agreement on supporting multiple
>> window-width caches at all or just a single cache. The proposed
>> > patch would be better suited to a single-cache case (regenerated on a
>> full data revert).
>> >
>> > As a buffer can contain only a single-sized vtable, even when displaye=
d
>> in multiple windows of different widths, perhaps a single
>> > cache isn't so bad?
>>
>> Yes. That's what my patch does, it has a single "cache" stored in the
>> text of the vtable, no longer keyed by anything.
>>
>> But really "cache" is the wrong word for this. It's just some mutable
>> data stored by the vtable.
>>
>> > People might be relying on the current multi-width cache
>> implementation, at least for predominantly read-only vtables (or they
>> > would have reported the issues we're aware of). One simple concession
>> could be to support multiple caches for read-only tables,
>> > and simply invalidate other caches on mutations (this is the policy I
>> implemented in the larger patch).
>> >
>> > If we decide on a single cache, then the simpler approach in the
>> proposed patch could work at the cost of making it harder to
>> > restore multi-cache later (and, if we go with the cache as text
>> property on the table, we should rename it `vtable--cache` to avoid
>> > people using its value in their own code).
>>
>> The multi-width cache is completely useless and broken with the current
>> state of the code, so no-one can be relying on it. And anyway it
>> provides no benefit, because vtables can't be displayed differently in
>> different windows.
>>
>> > If we decide to retain multi-cache, I'd prefer if we make the smallest
>> possible change to deal with the case you need now. I think
>> > this can be done with a simple change to `vtable--cache-key` to produc=
e
>> a uniform window-less key. I want to add the option to
>> > record the buffer into which a vtable instance has been inserted to
>> precisely test whether the current window's buffer is the vtable
>> > buffer (also addressed in the larger patch) and which addresses
>> Augusto's `comint-mime` use case.
>>
>> Changing vtable--cache-key to produce a key which doesn't mention the
>> window or the frame would mean changing to have a single cache, because
>> those are the only two things in the cache key.
>>
>
Alright! Hand becoming sufficiently usable! Sorry for the delay.
Spencer, can you take a quick look at the patch you provided
via 0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch it does
not pass the vtable tests (which we will beef up, and get rid of the typo
in the first test name).
Selector: test-vtable-insert-object
Passed: 0
Failed: 1 (1 unexpected)
Skipped: 0
Total: 1/1
Started at: 2025-10-30 14:16:26-0400
Finished.
Finished at: 2025-10-30 14:16:27-0400
F
F test-vtable-insert-object
(wrong-type-argument consp nil)
Thank you,
-St=C3=A9phane (two handed!)
--0000000000006baabb0642671ef7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">=
On Fri, Sep 26, 2025 at 10:09=E2=80=AFAM St=C3=A9phane Marks <<a href=3D=
"mailto:shipmints@HIDDEN">shipmints@HIDDEN</a>> wrote:</span></div=
></div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg=
b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div style=3D"font-family=
:monospace">I kind of badly injured my left hand (this is right hand typing=
) so will be back to this when I can function a bit better.</div></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Se=
p 18, 2025 at 3:20=E2=80=AFPM Spencer Baugh <<a href=3D"mailto:sbaugh@ja=
nestreet.com" target=3D"_blank">sbaugh@HIDDEN</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex">St=C3=A9phane Marks &l=
t;<a href=3D"mailto:shipmints@HIDDEN" target=3D"_blank">shipmints@gmail.=
com</a>> writes:<br>
> Thank you for being patient (family, life, and work priorities vs. vol=
unteer time). I've put a lot of work into vtable bug fixes and<br>
> improvements, and I'd like to see how much momentum we can foster.=
<br>
><br>
> The proposed patch will mutate only the "current cache" on i=
nsert/update/remove objects leaving the other caches invalid, and<br>
> when called from a window that doesn't share the cache key's w=
idth, the user will need to manually revert to repopulate a cache<br>
> of their window's width and reset the "current cache" to=
avoid cache corruption runtime errors on mutation (I've addressed thes=
e<br>
> use cases in the larger patch.)<br>
<br>
That's not true.=C2=A0 No corruption can happen with my patch.=C2=A0 If=
you<br>
believe otherwise, please give some code which demonstrates it, and we<br>
can convert that into a test.<br>
<br>
> I think we should come to an agreement on supporting multiple window-w=
idth caches at all or just a single cache. The proposed<br>
> patch would be better suited to a single-cache case (regenerated on a =
full data revert).<br>
><br>
> As a buffer can contain only a single-sized vtable, even when displaye=
d in multiple windows of different widths, perhaps a single<br>
> cache isn't so bad?<br>
<br>
Yes.=C2=A0 That's what my patch does, it has a single "cache"=
stored in the<br>
text of the vtable, no longer keyed by anything.<br>
<br>
But really "cache" is the wrong word for this.=C2=A0 It's jus=
t some mutable<br>
data stored by the vtable.<br>
<br>
> People might be relying on the current multi-width cache implementatio=
n, at least for predominantly read-only vtables (or they<br>
> would have reported the issues we're aware of).=C2=A0 One simple c=
oncession could be to support multiple caches for read-only tables,<br>
> and simply invalidate other caches on mutations (this is the policy I =
implemented in the larger patch).<br>
><br>
> If we decide on a single cache, then the simpler approach in the propo=
sed patch could work at the cost of making it harder to<br>
> restore multi-cache later (and, if we go with the cache as text proper=
ty on the table, we should rename it `vtable--cache` to avoid<br>
> people using its value in their own code).<br>
<br>
The multi-width cache is completely useless and broken with the current<br>
state of the code, so no-one can be relying on it.=C2=A0 And anyway it<br>
provides no benefit, because vtables can't be displayed differently in<=
br>
different windows.<br>
<br>
> If we decide to retain multi-cache, I'd prefer if we make the smal=
lest possible change to deal with the case you need now.=C2=A0 I think<br>
> this can be done with a simple change to `vtable--cache-key` to produc=
e a uniform window-less key. I want to add the option to<br>
> record the buffer into which a vtable instance has been inserted to pr=
ecisely test whether the current window's buffer is the vtable<br>
> buffer (also addressed in the larger patch) and which addresses August=
o's `comint-mime` use case. <br>
<br>
Changing vtable--cache-key to produce a key which doesn't mention the<b=
r>
window or the frame would mean changing to have a single cache, because<br>
those are the only two things in the cache key.<br></blockquote></div></blo=
ckquote><div><br></div><div class=3D"gmail_default" style=3D"font-family:mo=
nospace">Alright! Hand becoming sufficiently usable! Sorry for the delay.</=
div><div class=3D"gmail_default" style=3D"font-family:monospace"><br></div>=
<div class=3D"gmail_default" style=3D"font-family:monospace">Spencer, can y=
ou take a quick look at the patch you provided via=C2=A00001-Fix-implicit-u=
sage-of-the-current-window-width-in-vt.patch it does not pass the vtable te=
sts (which we will beef up, and get rid of the typo in the first test name)=
.</div><div class=3D"gmail_default" style=3D"font-family:monospace"><br></d=
iv><div class=3D"gmail_default" style=3D"font-family:monospace">Selector: t=
est-vtable-insert-object<br>Passed: =C2=A00<br>Failed: =C2=A01 (1 unexpecte=
d)<br>Skipped: 0<br>Total: =C2=A0 1/1<br><br>Started at: =C2=A0 2025-10-30 =
14:16:26-0400<br>Finished.<br>Finished at: =C2=A02025-10-30 14:16:27-0400<b=
r><br>F<br><br>F test-vtable-insert-object<br>=C2=A0 =C2=A0 (wrong-type-arg=
ument consp nil)<br><br>Thank you,</div><div class=3D"gmail_default" style=
=3D"font-family:monospace"><br></div><div class=3D"gmail_default" style=3D"=
font-family:monospace">-St=C3=A9phane (two handed!)<br><br></div></div></di=
v>
--0000000000006baabb0642671ef7--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 26 Sep 2025 14:09:49 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Sep 26 10:09:49 2025 Received: from localhost ([127.0.0.1]:36091 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1v298u-0005Ru-7g for submit <at> debbugs.gnu.org; Fri, 26 Sep 2025 10:09:49 -0400 Received: from mail-vk1-xa32.google.com ([2607:f8b0:4864:20::a32]:57698) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1v298k-0005RU-Fo for 69837 <at> debbugs.gnu.org; Fri, 26 Sep 2025 10:09:40 -0400 Received: by mail-vk1-xa32.google.com with SMTP id 71dfb90a1353d-54a786ed57cso1676465e0c.3 for <69837 <at> debbugs.gnu.org>; Fri, 26 Sep 2025 07:09:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758895771; x=1759500571; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=E+4FxowY7JKw81vX8cYT0sYFT2aGpVyBXxDdTaan1us=; b=FqFKaVfudLG64b51zb8MB3X9EFctDHXCTXkmdgz+Y15h/20Hq09DN5v/0UuDAEqsz5 9hI0u3MMHyg+hnxbd3GkeCmh5Y431qhhj3RnChAztyO7byqpZXEaQQJD99jQYy/Hyrxk R56O0rThhKoC860m7hEz8UWPAeBidDocvFHQTtqPEwBaKcJtM7OOIAZ+qbbXjRX2ogZp xbcodwIbrqguH9Xsf89PDy/iPbRMF8fZdv4y+xPctHZcT/49SImQ1liXpQcoJdGn8/9u 2RY1dI7S3Zs1hv4bVsUsW91gTCZKDfPyOW2U8fMosR/3Gvlt9pnQopUDed19OLw3yqk9 MRaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758895771; x=1759500571; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=E+4FxowY7JKw81vX8cYT0sYFT2aGpVyBXxDdTaan1us=; b=t2BzgqBoXwwR5ifXxK/7UW+ViDbYHAbhttFKT/kZcp67h3kAZuOhOtn0wjL23SBkyd a2viM4EedMuLrSFOqrkUtyDiXqnZo2NdVD1lxjqiTDYPv67U7VeGOgXan+MfFDEAfJ0F mBGUNNlLPUvwsCGjEuyHFTzFu06Yu/4jFj+RJ2yCppayHP3qBgGqKe/qwznkQvP32OGo kgsopyLMfmvGF61Co3ZfWniU3b2uTrJV9H5mKqo1U04N5L+CJ0RK9kOE9KJx+rqiZQKO UUf+JvWgYJgdz2AGwLBzBwpPOv89seY6LCBvNYqbA1l33uQNRs0YQOxYs7OXNHASQ45a FvDg== X-Forwarded-Encrypted: i=1; AJvYcCUBe7n/+9WOf4jN5czhBjKXVLQ4ngeeM970zavfA3nHqgoSoyU8NmHfTXCLUsXuWVS8DFPQCQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0YySLzsJWESC81im0VPths1V6qlDXnBRCrVl2Ynvs00+53d5aeuY HiGpgQhikXULE2Qd8ZU+pG3pB9ZZ3Pbyk+hJZDYDIN78F7aQPcPUAHRkZOTsdMvt1sCYFh/y+rn mH9ChuYFZlN4zS724qja55p9O0qAwQ7Q= X-Gm-Gg: ASbGncs+4MZh70sSrAtbKHXBHJTLQioghLa7UMLvQbSIl81YeKzm9HQ1yxd9lcNpNLl Yu0NiNGpXG+wOYVd/E0ABjHNXy5/83Kxp2mLwLnLYjFQmb4mOK0yGg/UUwyb39MxXZGC5tWMlyX nXhaKq8Zv71b30jLFy9KmfRqbXSPnM5VBm3LvhvCse8C1USnD4e0MA0Yjrl2gWR+Cz3V7fvP6F/ sIiZemZ0tpC4xe1lXTS X-Google-Smtp-Source: AGHT+IEYb1iaRcDwEZi/0EIO5zEnkvDsNmI0zTd7hAGmzxxNIyHHt9mbVSpSgfYEbDo/pnDSuecMQbS4MKhMIgfkxCI= X-Received: by 2002:a05:6122:1806:b0:54a:8ad7:59eb with SMTP id 71dfb90a1353d-54bea2f50b1mr3387144e0c.9.1758895771359; Fri, 26 Sep 2025 07:09:31 -0700 (PDT) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> <ierfrcjsh3q.fsf@HIDDEN> In-Reply-To: <ierfrcjsh3q.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Fri, 26 Sep 2025 10:09:19 -0400 X-Gm-Features: AS18NWBnK79xrn1fpO2JG1Yf8jxW3ZaptE8iMREJq1SCvZAmvbRO7O9ABDIB1mw Message-ID: <CAN+1Hbp11MZ3FZChH3qg_93Am1zAvMbfpL_9ZRzuhSOJ0vVaYA@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000a61f56063fb4d545" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --000000000000a61f56063fb4d545 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable I kind of badly injured my left hand (this is right hand typing) so will be back to this when I can function a bit better. On Thu, Sep 18, 2025 at 3:20=E2=80=AFPM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > Thank you for being patient (family, life, and work priorities vs. > volunteer time). I've put a lot of work into vtable bug fixes and > > improvements, and I'd like to see how much momentum we can foster. > > > > The proposed patch will mutate only the "current cache" on > insert/update/remove objects leaving the other caches invalid, and > > when called from a window that doesn't share the cache key's width, the > user will need to manually revert to repopulate a cache > > of their window's width and reset the "current cache" to avoid cache > corruption runtime errors on mutation (I've addressed these > > use cases in the larger patch.) > > That's not true. No corruption can happen with my patch. If you > believe otherwise, please give some code which demonstrates it, and we > can convert that into a test. > > > I think we should come to an agreement on supporting multiple > window-width caches at all or just a single cache. The proposed > > patch would be better suited to a single-cache case (regenerated on a > full data revert). > > > > As a buffer can contain only a single-sized vtable, even when displayed > in multiple windows of different widths, perhaps a single > > cache isn't so bad? > > Yes. That's what my patch does, it has a single "cache" stored in the > text of the vtable, no longer keyed by anything. > > But really "cache" is the wrong word for this. It's just some mutable > data stored by the vtable. > > > People might be relying on the current multi-width cache implementation= , > at least for predominantly read-only vtables (or they > > would have reported the issues we're aware of). One simple concession > could be to support multiple caches for read-only tables, > > and simply invalidate other caches on mutations (this is the policy I > implemented in the larger patch). > > > > If we decide on a single cache, then the simpler approach in the > proposed patch could work at the cost of making it harder to > > restore multi-cache later (and, if we go with the cache as text propert= y > on the table, we should rename it `vtable--cache` to avoid > > people using its value in their own code). > > The multi-width cache is completely useless and broken with the current > state of the code, so no-one can be relying on it. And anyway it > provides no benefit, because vtables can't be displayed differently in > different windows. > > > If we decide to retain multi-cache, I'd prefer if we make the smallest > possible change to deal with the case you need now. I think > > this can be done with a simple change to `vtable--cache-key` to produce > a uniform window-less key. I want to add the option to > > record the buffer into which a vtable instance has been inserted to > precisely test whether the current window's buffer is the vtable > > buffer (also addressed in the larger patch) and which addresses > Augusto's `comint-mime` use case. > > Changing vtable--cache-key to produce a key which doesn't mention the > window or the frame would mean changing to have a single cache, because > those are the only two things in the cache key. > --000000000000a61f56063fb4d545 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:monospac= e">I kind of badly injured my left hand (this is right hand typing) so will= be back to this when I can function a bit better.</div></div><br><div clas= s=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_att= r">On Thu, Sep 18, 2025 at 3:20=E2=80=AFPM Spencer Baugh <<a href=3D"mai= lto:sbaugh@HIDDEN">sbaugh@HIDDEN</a>> wrote:<br></div><b= lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le= ft:1px solid rgb(204,204,204);padding-left:1ex">St=C3=A9phane Marks <<a = href=3D"mailto:shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</= a>> writes:<br> > Thank you for being patient (family, life, and work priorities vs. vol= unteer time). I've put a lot of work into vtable bug fixes and<br> > improvements, and I'd like to see how much momentum we can foster.= <br> ><br> > The proposed patch will mutate only the "current cache" on i= nsert/update/remove objects leaving the other caches invalid, and<br> > when called from a window that doesn't share the cache key's w= idth, the user will need to manually revert to repopulate a cache<br> > of their window's width and reset the "current cache" to= avoid cache corruption runtime errors on mutation (I've addressed thes= e<br> > use cases in the larger patch.)<br> <br> That's not true.=C2=A0 No corruption can happen with my patch.=C2=A0 If= you<br> believe otherwise, please give some code which demonstrates it, and we<br> can convert that into a test.<br> <br> > I think we should come to an agreement on supporting multiple window-w= idth caches at all or just a single cache. The proposed<br> > patch would be better suited to a single-cache case (regenerated on a = full data revert).<br> ><br> > As a buffer can contain only a single-sized vtable, even when displaye= d in multiple windows of different widths, perhaps a single<br> > cache isn't so bad?<br> <br> Yes.=C2=A0 That's what my patch does, it has a single "cache"= stored in the<br> text of the vtable, no longer keyed by anything.<br> <br> But really "cache" is the wrong word for this.=C2=A0 It's jus= t some mutable<br> data stored by the vtable.<br> <br> > People might be relying on the current multi-width cache implementatio= n, at least for predominantly read-only vtables (or they<br> > would have reported the issues we're aware of).=C2=A0 One simple c= oncession could be to support multiple caches for read-only tables,<br> > and simply invalidate other caches on mutations (this is the policy I = implemented in the larger patch).<br> ><br> > If we decide on a single cache, then the simpler approach in the propo= sed patch could work at the cost of making it harder to<br> > restore multi-cache later (and, if we go with the cache as text proper= ty on the table, we should rename it `vtable--cache` to avoid<br> > people using its value in their own code).<br> <br> The multi-width cache is completely useless and broken with the current<br> state of the code, so no-one can be relying on it.=C2=A0 And anyway it<br> provides no benefit, because vtables can't be displayed differently in<= br> different windows.<br> <br> > If we decide to retain multi-cache, I'd prefer if we make the smal= lest possible change to deal with the case you need now.=C2=A0 I think<br> > this can be done with a simple change to `vtable--cache-key` to produc= e a uniform window-less key. I want to add the option to<br> > record the buffer into which a vtable instance has been inserted to pr= ecisely test whether the current window's buffer is the vtable<br> > buffer (also addressed in the larger patch) and which addresses August= o's `comint-mime` use case. <br> <br> Changing vtable--cache-key to produce a key which doesn't mention the<b= r> window or the frame would mean changing to have a single cache, because<br> those are the only two things in the cache key.<br> </blockquote></div> --000000000000a61f56063fb4d545--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Sep 2025 19:20:20 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 18 15:20:20 2025 Received: from localhost ([127.0.0.1]:34204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uzKB2-0000jB-Bq for submit <at> debbugs.gnu.org; Thu, 18 Sep 2025 15:20:20 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:56065) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1uzKAx-0000iG-C0 for 69837 <at> debbugs.gnu.org; Thu, 18 Sep 2025 15:20:15 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el In-Reply-To: <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> (=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Thu, 18 Sep 2025 14:49:36 -0400") 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> Date: Thu, 18 Sep 2025 15:20:09 -0400 Message-ID: <ierfrcjsh3q.fsf@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1758223210; bh=kK1fydIt4/qsVDUMFQZKP0kX7IVrvybiqg17sltty74=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=1eEvrEgpo2df6PQPVsc2+9zK30otGdEM4JUpf0aE0qS+B+LnjAGEc0Ae5fPkYSJIS uc6YGfWhU4O/HsfjW7tPOcGOrSUsTRCJOe/A7Wvz5/otwMzeBYTCA5mfMUr/W22Xlk y8BoH35v3pdnKlMJUb1Qvh0cj7z9OVWdKrb8lg+QtJA+2WPOixo2RGERLjFYw3wNfx Ze1TNCP3vlRE9X8kEHGK+OfzFl/ua6i378ibNK44MojJ8MyEVBjeVcekmI6gjAHC8x 8NoUVVCDfor6yY+/xmOh4U5h+IM/sdJ3CKcm6cW8naYKnlLYol1pCZ5ukIlpMUlgKS +1LZ5xaoPWMLA== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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 (---) St=C3=A9phane Marks <shipmints@HIDDEN> writes: > Thank you for being patient (family, life, and work priorities vs. volunt= eer time). I've put a lot of work into vtable bug fixes and > improvements, and I'd like to see how much momentum we can foster. > > The proposed patch will mutate only the "current cache" on insert/update/= remove objects leaving the other caches invalid, and > when called from a window that doesn't share the cache key's width, the u= ser will need to manually revert to repopulate a cache > of their window's width and reset the "current cache" to avoid cache corr= uption runtime errors on mutation (I've addressed these > use cases in the larger patch.) That's not true. No corruption can happen with my patch. If you believe otherwise, please give some code which demonstrates it, and we can convert that into a test. > I think we should come to an agreement on supporting multiple window-widt= h caches at all or just a single cache. The proposed > patch would be better suited to a single-cache case (regenerated on a ful= l data revert). > > As a buffer can contain only a single-sized vtable, even when displayed i= n multiple windows of different widths, perhaps a single > cache isn't so bad? Yes. That's what my patch does, it has a single "cache" stored in the text of the vtable, no longer keyed by anything. But really "cache" is the wrong word for this. It's just some mutable data stored by the vtable. > People might be relying on the current multi-width cache implementation, = at least for predominantly read-only vtables (or they > would have reported the issues we're aware of). One simple concession co= uld be to support multiple caches for read-only tables, > and simply invalidate other caches on mutations (this is the policy I imp= lemented in the larger patch). > > If we decide on a single cache, then the simpler approach in the proposed= patch could work at the cost of making it harder to > restore multi-cache later (and, if we go with the cache as text property = on the table, we should rename it `vtable--cache` to avoid > people using its value in their own code). The multi-width cache is completely useless and broken with the current state of the code, so no-one can be relying on it. And anyway it provides no benefit, because vtables can't be displayed differently in different windows. > If we decide to retain multi-cache, I'd prefer if we make the smallest po= ssible change to deal with the case you need now. I think > this can be done with a simple change to `vtable--cache-key` to produce a= uniform window-less key. I want to add the option to > record the buffer into which a vtable instance has been inserted to preci= sely test whether the current window's buffer is the vtable > buffer (also addressed in the larger patch) and which addresses Augusto's= `comint-mime` use case.=20 Changing vtable--cache-key to produce a key which doesn't mention the window or the frame would mean changing to have a single cache, because those are the only two things in the cache key.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 18 Sep 2025 18:50:01 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 18 14:50:00 2025 Received: from localhost ([127.0.0.1]:34145 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uzJhf-0007ZX-AP for submit <at> debbugs.gnu.org; Thu, 18 Sep 2025 14:50:00 -0400 Received: from mail-ua1-x92b.google.com ([2607:f8b0:4864:20::92b]:50532) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1uzJhZ-0007ZG-TV for 69837 <at> debbugs.gnu.org; Thu, 18 Sep 2025 14:49:55 -0400 Received: by mail-ua1-x92b.google.com with SMTP id a1e0cc1a2514c-8a00c77a62dso877659241.1 for <69837 <at> debbugs.gnu.org>; Thu, 18 Sep 2025 11:49:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1758221388; x=1758826188; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=j4JPaliE5PulnHPHBpytCA5SFQW6jpLIQNRJLACicCk=; b=nQpaSpDuD+fas2z0MQxNqK5C+YGnmuxmdX5Zx8ruItmrOyn8AbGMP+Ge1DeUY5v1Q1 4n11bV8O5AjRvuiEhJGvaQEVn9NSP5dB5L2elsCIpjHzI2XpLdPPaakJ4dAVjV5UeXBF JaM4JkODTNYpX0tynyzREKtL4g9W0pql1QWnbJY0FA+TVu9KNATFmx2vvyJVqOYH0E9V W9GzqhaYAUpiIfat/125gSo3CGq937PQffJQ8aJHSJR4sG4bMcSH2ntw1ml3m+H0MG2H /oT7K//jf+8OHLJiAst/pUm7hMBqsybudWlqUd3sSvnaku9HrR9wkwXy5nfJeLuPskXs Siww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1758221388; x=1758826188; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=j4JPaliE5PulnHPHBpytCA5SFQW6jpLIQNRJLACicCk=; b=dhxCcN/SYGcpr45EhrYGPez18q007c0ePs6Xx4AeODbdvgF6Jxbu906XVvXgn8urht c+KMYoNgL08FfwASkGv9SQaUZ3x5eENdwBC0yn27gIswzAvnl7bXYvxuEgs2jUwkBny2 SwP/DX60+X0biU5ufyLHk6Eb2/TuFP9IMiKIdqFQ+ICBj4HyEKWjFkMP1Ua6yWIMY7kj /OsFvmXtSDKCZBFHwRASQFU+Gicyu9qKtB7zSuIMBCmpi2XcuIHER1bnN0UTNcURQVR6 Ke7zEu0IaYs88YVoOpjjON8Mye0p+TqG5SN9BKNFVQI0ColVZBF81wkbc5n+9qMDrKYL ru4w== X-Forwarded-Encrypted: i=1; AJvYcCWU6G8UfqYtHRK/vJF1OAdcaMjQaQPNzv1kL4yKtutvEnN5d5FueUi1Vbt9CnBDtNDrEsbHXw==@debbugs.gnu.org X-Gm-Message-State: AOJu0YyDjn+dYwSxb7BGSsepOaXVIzHMRurKzH57HI6ejJIMk9UhC1Ic Cg+CA81dwwdVSfV7As5S4Ut9Bv4r2FbxSz3RkXYUcCEdNIWxN4gt8BvWVLCxA+uqiH4a8aEHqZq 3DjnrjJirgat0d/mBENYC7Z/54IvLqCs= X-Gm-Gg: ASbGncvzSFolO4P2Bd5sSXgIxgNOHWcEV8cRa/z069trI09pIHoauJ9G3jxLsnLa2EX TowPty4FDwNsZYdFKjHiik43yVcAFvVvaXnF0oZHRFKCsQnJ1lJO+lO0fd8M4e0hCKapipNgrDC MaYL4yyK01wD+T4spYF52CRHWr/eUiiK6rUf9tB+SRedCTdEyo5dhXQ/e15eYfk1/7isODp0zxe 6aEdTNFlgs1eb+lC7lHYnee0bPOB0hoY8emaQDk7jz9BWOaY0sWCcoRj0HiBBRjia5QC9srd8FO xau8S/Me2pxgYci8RzZxX+K61+iOvcTNB4sR9IEZ217V5A77AoNvsVc66sQ7rXd+30cRuHtQIRH 8OWYbCtn0zlYb+Re3oeeI8bCSM+nsQQ9/AfdQGg== X-Google-Smtp-Source: AGHT+IF5ccavhqBj2pdYOreHCMm2BS+QAKxOGMfeNqiLuUyFSl7YmWYh4/rwlOboRV17bmseOUzYfYHMHRjo0yVJi4s= X-Received: by 2002:a05:6102:148f:b0:4e5:ac0f:582c with SMTP id ada2fe7eead31-588ddab957amr248526137.13.1758221387987; Thu, 18 Sep 2025 11:49:47 -0700 (PDT) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> In-Reply-To: <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Thu, 18 Sep 2025 14:49:36 -0400 X-Gm-Features: AS18NWDsYpDt5HceEiBdjgk0d8-t9wKiruzy8T1DOKSZIHCSxzWzOfwn9Z61yhQ Message-ID: <CAN+1HbpOnAvpTyMFYap2paUcEshwjAUf6Omthk7McNLjsoQj_Q@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000447e0b063f17d11c" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --000000000000447e0b063f17d11c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 10, 2025 at 10:47=E2=80=AFAM St=C3=A9phane Marks <shipmints@gma= il.com> wrote: > On Thu, Sep 4, 2025 at 3:05=E2=80=AFPM St=C3=A9phane Marks <shipmints@gma= il.com> wrote: > >> On Wed, Sep 3, 2025 at 12:30=E2=80=AFPM Spencer Baugh <sbaugh@janestreet= .com> >> wrote: >> >>> Spencer Baugh <sbaugh@HIDDEN> writes: >>> > St=C3=A9phane Marks <shipmints@HIDDEN> writes: >>> >> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug report= s for GNU >>> Emacs, the Swiss army knife of text editors >>> >> <bug-gnu-emacs@HIDDEN> wrote: >>> >> >>> >> Stefan Kangas <stefankangas@HIDDEN> writes: >>> >> >>> >> > Eli Zaretskii <eliz@HIDDEN> writes: >>> >> > >>> >> >>> 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 o= f >>> the >>> >> >>> vtable's creation. The macro locally overrides the functions >>> >> >>> `frame-terminal' and `window-width' to return those saved value= s. >>> >> >>> >>> >> >>> This allows the cache key to match unconditionally, which allow= s >>> 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 tab= le >>> >> >>> (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. >>> >> > >>> >> > Adam, could you please install the workaround? Or maybe you did >>> >> > already? >>> >> >>> >> I ran into this same problem. I think Adam's workaround is on the >>> right >>> >> track, but the issue is present in a number of other functions in >>> >> vtable.el, not just vtable-update-object. >>> >> >>> >> The root of the issue is that when we're interacting with the text >>> of an >>> >> inserted vtable, we should use the "cache" object that was last use= d >>> to >>> >> insert that vtable, rather than one based on the current selected >>> window >>> >> and terminal. Otherwise we will experience various inconsistencies= , >>> >> e.g. inserting a new line that has different column widths from the >>> rest >>> >> of the vtable text. >>> >> >>> >> My attached patch solves this by saving the "cache" object in a tex= t >>> >> property on the vtable text, and updating all the relevant vtable >>> >> functions to access the cache via that text property rather than by >>> >> computing a cache key from the current selected window/terminal. >>> >> >>> >> Adam, could you check that this solves the problem for your use cas= e? >>> >> >>> >> I have a very big patch coming for vtable under >>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843 which addresses >>> this issue, >>> >> and a ton of other bugs (and features). That's coming in the next >>> day or so, if you can wait? >>> > >>> > Certainly I can wait. Cc me when you send the patch. >>> > >>> > Though if your patch is very large, maybe this relatively small patch >>> > should land first. >>> >>> Since it's been a while and this large patch has not landed, I suggest >>> we should install my patch now to close this bug. St=C3=A9phane's patc= h can >>> simply be rebased on top later. >>> >> >> I'll try to get back into vtable this weekend and take a fresh look. >> > > I'll have some time tomorrow to test and react. I have one amendment that > enhances the patch in the case where a vtable is inserted in a window-les= s > buffer. My larger patch has such an accommodation. > Thank you for being patient (family, life, and work priorities vs. volunteer time). I've put a lot of work into vtable bug fixes and improvements, and I'd like to see how much momentum we can foster. The proposed patch will mutate only the "current cache" on insert/update/remove objects leaving the other caches invalid, and when called from a window that doesn't share the cache key's width, the user will need to manually revert to repopulate a cache of their window's width and reset the "current cache" to avoid cache corruption runtime errors on mutation (I've addressed these use cases in the larger patch.) I think we should come to an agreement on supporting multiple window-width caches at all or just a single cache. The proposed patch would be better suited to a single-cache case (regenerated on a full data revert). As a buffer can contain only a single-sized vtable, even when displayed in multiple windows of different widths, perhaps a single cache isn't so bad? People might be relying on the current multi-width cache implementation, at least for predominantly read-only vtables (or they would have reported the issues we're aware of). One simple concession could be to support multiple caches for read-only tables, and simply invalidate other caches on mutations (this is the policy I implemented in the larger patch). If we decide on a single cache, then the simpler approach in the proposed patch could work at the cost of making it harder to restore multi-cache later (and, if we go with the cache as text property on the table, we should rename it `vtable--cache` to avoid people using its value in their own code). If we decide to retain multi-cache, I'd prefer if we make the smallest possible change to deal with the case you need now. I think this can be done with a simple change to `vtable--cache-key` to produce a uniform window-less key. I want to add the option to record the buffer into which a vtable instance has been inserted to precisely test whether the current window's buffer is the vtable buffer (also addressed in the larger patch) and which addresses Augusto's `comint-mime` use case. -St=C3=A9phane --000000000000447e0b063f17d11c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Wed, Sep 10, 2025 at 10:47=E2=80=AFAM St=C3=A9phane Marks <<a href=3D= "mailto:shipmints@HIDDEN">shipmints@HIDDEN</a>> wrote:</span></div= ></div><div class=3D"gmail_quote gmail_quote_container"><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div sty= le=3D"font-family:monospace"><span style=3D"font-family:Arial,Helvetica,san= s-serif">On Thu, Sep 4, 2025 at 3:05=E2=80=AFPM St=C3=A9phane Marks <<a = href=3D"mailto:shipmints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</= a>> wrote:</span></div></div><div class=3D"gmail_quote"><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div st= yle=3D"font-family:monospace"><span style=3D"font-family:Arial,Helvetica,sa= ns-serif">On Wed, Sep 3, 2025 at 12:30=E2=80=AFPM Spencer Baugh <<a href= =3D"mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</= a>> wrote:</span></div></div><div class=3D"gmail_quote"><blockquote clas= s=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid r= gb(204,204,204);padding-left:1ex">Spencer Baugh <<a href=3D"mailto:sbaug= h@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</a>> writes:<b= r> > St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" target= =3D"_blank">shipmints@HIDDEN</a>> writes:<br> >> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug repo= rts for GNU Emacs, the Swiss army knife of text editors<br> >> <<a href=3D"mailto:bug-gnu-emacs@HIDDEN" target=3D"_blank">bug= -gnu-emacs@HIDDEN</a>> wrote:<br> >><br> >>=C2=A0 Stefan Kangas <<a href=3D"mailto:stefankangas@HIDDEN" = target=3D"_blank">stefankangas@HIDDEN</a>> writes:<br> >><br> >>=C2=A0 > Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" targe= t=3D"_blank">eliz@HIDDEN</a>> writes:<br> >>=C2=A0 ><br> >>=C2=A0 >>> Date: Thu, 21 Mar 2024 03:36:02 -0500<br> >>=C2=A0 >>> Cc: <a href=3D"mailto:69837 <at> debbugs.gnu.org" ta= rget=3D"_blank">69837 <at> debbugs.gnu.org</a><br> >>=C2=A0 >>> From: Adam Porter <<a href=3D"mailto:adam@al= phapapa.net" target=3D"_blank">adam@HIDDEN</a>><br> >>=C2=A0 >>><br> >>=C2=A0 >>> FWIW, I did some hacking on listen.el attemptin= g to further understand<br> >>=C2=A0 >>> and work around this problem, and I've foun= d what seems to be a usable<br> >>=C2=A0 >>> workaround (for my purposes, anyway).<br> >>=C2=A0 >>><br> >>=C2=A0 >>> The attached code defines a macro within which = I call<br> >>=C2=A0 >>> `listen-queue--vtable-update-object' (which= merely incorporates the fix<br> >>=C2=A0 >>> to `vtable-update-object' from bug#69664).= =C2=A0 As well, I wrap<br> >>=C2=A0 >>> `make-vtable' in a function that also sets = two buffer-local variables to<br> >>=C2=A0 >>> the values of `frame-terminal' and `window-= width' at the time of the<br> >>=C2=A0 >>> vtable's creation.=C2=A0 The macro locally = overrides the functions<br> >>=C2=A0 >>> `frame-terminal' and `window-width' to = return those saved values.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> This allows the cache key to match unconditiona= lly, which allows the<br> >>=C2=A0 >>> vtable's objects to be updated even when it= s buffer is not visible.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> In my limited testing, it seems to work fine.= =C2=A0 In my estimation, the<br> >>=C2=A0 >>> consequences of doing this in the worst case wo= uld be that the rows for<br> >>=C2=A0 >>> the updated objects might be drawn with some co= lumns at a slightly<br> >>=C2=A0 >>> incorrect width, which is easily rectified by r= everting the table<br> >>=C2=A0 >>> (usually bound to "g").=C2=A0 As well= , that worst case (e.g. imagining a<br> >>=C2=A0 >>> vtable whose buffer might be initially displaye= d on one terminal/monitor<br> >>=C2=A0 >>> and later on another with different characteris= tics) would seem to be<br> >>=C2=A0 >>> relatively rare (so for my project, it seems li= ke an obviously good<br> >>=C2=A0 >>> thing to do).<br> >>=C2=A0 >>><br> >>=C2=A0 >>> For Emacs itself, I'm not sure what the bes= t fix would be.=C2=A0 I suppose a<br> >>=C2=A0 >>> workaround like this could be implemented as a = fallback in case the<br> >>=C2=A0 >>> cache key misses; it would seem better to updat= e the object potentially<br> >>=C2=A0 >>> sub-optimally than to error and not update it a= t all.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> Another possibility would be to ignore the fram= e-terminal and<br> >>=C2=A0 >>> window-width in the cache key altogether (i.e. = so they would always be<br> >>=C2=A0 >>> assumed to be the same), but I'm sure that = Lars did it this way for a<br> >>=C2=A0 >>> reason, so that would seem unwise.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> Let me know how you'd like me to proceed.<b= r> >>=C2=A0 >><br> >>=C2=A0 >> I think you should install your workaround.=C2=A0 I= don't see how it could<br> >>=C2=A0 >> be worse than what we have now.<br> >>=C2=A0 >><br> >>=C2=A0 >> P.S. And sorry for a long silence.<br> >>=C2=A0 ><br> >>=C2=A0 > Adam, could you please install the workaround?=C2=A0 Or= maybe you did<br> >>=C2=A0 > already?<br> >><br> >>=C2=A0 I ran into this same problem.=C2=A0 I think Adam's worka= round is on the right<br> >>=C2=A0 track, but the issue is present in a number of other functio= ns in<br> >>=C2=A0 vtable.el, not just vtable-update-object.<br> >><br> >>=C2=A0 The root of the issue is that when we're interacting wit= h the text of an<br> >>=C2=A0 inserted vtable, we should use the "cache" object = that was last used to<br> >>=C2=A0 insert that vtable, rather than one based on the current sel= ected window<br> >>=C2=A0 and terminal.=C2=A0 Otherwise we will experience various inc= onsistencies,<br> >>=C2=A0 e.g. inserting a new line that has different column widths f= rom the rest<br> >>=C2=A0 of the vtable text.<br> >><br> >>=C2=A0 My attached patch solves this by saving the "cache"= ; object in a text<br> >>=C2=A0 property on the vtable text, and updating all the relevant v= table<br> >>=C2=A0 functions to access the cache via that text property rather = than by<br> >>=C2=A0 computing a cache key from the current selected window/termi= nal.<br> >><br> >>=C2=A0 Adam, could you check that this solves the problem for your = use case?<br> >><br> >> I have a very big patch coming for vtable under <a href=3D"https:/= /debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843" rel=3D"noreferrer" target= =3D"_blank">https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843</a> which= addresses this issue,<br> >> and a ton of other bugs (and features).=C2=A0 That's coming in= the next day or so, if you can wait?<br> ><br> > Certainly I can wait.=C2=A0 Cc me when you send the patch.<br> ><br> > Though if your patch is very large, maybe this relatively small patch<= br> > should land first.<br> <br> Since it's been a while and this large patch has not landed, I suggest<= br> we should install my patch now to close this bug.=C2=A0 St=C3=A9phane's= patch can<br> simply be rebased on top later.<br></blockquote><div><br></div><div style= =3D"font-family:monospace">I'll try to get back into vtable this weeken= d and take a fresh look.</div></div></div></blockquote><div><br></div><div = style=3D"font-family:monospace">I'll have some time tomorrow to test an= d react. I have one amendment that enhances the patch in the case where a v= table is inserted in a window-less buffer. My larger patch has such an acco= mmodation.</div></div></div></blockquote><div><font face=3D"monospace"><br>= </font></div><font face=3D"monospace">Thank you for being patient (family, = life, and work priorities vs. volunteer time).<span class=3D"gmail_default"= style=3D"font-family:monospace">=C2=A0</span> I've put a lot of work i= nto vtable bug fixes and improvements, <span class=3D"gmail_default" style= =3D"font-family:monospace"></span>a<span class=3D"gmail_default" style=3D"f= ont-family:monospace">nd I'd like to=C2=A0</span><span class=3D"gmail_d= efault" style=3D"font-family:monospace"></span>see how much momentum we can= foster.<br><br>The proposed patch will mutate only the "current cache= " on insert/update/remove objects leaving the other caches invalid, an= d when called from a window that doesn't share the cache key's widt= h, the user will need to manually revert to repopulate a cache of their win= dow's width and reset the "current cache" to avoid cache corr= uption runtime errors on mutation (I've addressed these use cases in th= e larger patch.)<br><br>I think we should come to an agreement on supportin= g multiple window-width caches at all or just a single cache.<span class=3D= "gmail_default" style=3D"font-family:monospace">=C2=A0</span> The proposed = patch would be better suited to a single-cache case (regenerated on a full = data revert).<br><br>As a buffer can contain only a single-sized vtable, ev= en when displayed in multiple windows of different widths, perhaps a single= cache isn't so bad?<br><br><span class=3D"gmail_default" style=3D"font= -family:monospace"></span>People might be relying on the current multi-widt= h cache implementation, at least for predominantly read-only vtables (or th= ey would have reported the issues we're aware of). <span class=3D"gmail= _default" style=3D"font-family:monospace">=C2=A0</span>One simple concessio= n could be to support multiple caches for read-only tables, and simply inva= lidate other caches on mutations (this is the policy I implemented in the l= arger patch).<br><br>If we decide on a single cache, then the simpler appro= ach in the proposed patch could work at the cost of making it harder to res= tore multi-cache later (and, if we go with the cache as text property on th= e table, we should rename it `vtable--cache` to avoid people using its valu= e in their own code).<br><br>If we decide to retain multi-cache, I'd pr= efer if we make the smallest possible change to deal with the case you need= now. <span class=3D"gmail_default" style=3D"font-family:monospace">=C2=A0<= /span>I think this can be done with a simple change to `vtable--cache-key` = to produce a uniform window-less key.<span class=3D"gmail_default" style=3D= "font-family:monospace">=C2=A0</span> I want to add the option to record th= e buffer into which a vtable instance has been inserted to precisely test w= hether the current window's buffer is the vtable buffer (also addressed= in the larger patch) and which addresses Augusto's `comint-mime` use c= ase.</font>=C2=A0</div><div class=3D"gmail_quote gmail_quote_container"><br= ></div><div class=3D"gmail_quote gmail_quote_container"><div class=3D"gmail= _default" style=3D"font-family:monospace">-St=C3=A9phane</div><br></div></d= iv> --000000000000447e0b063f17d11c--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 10 Sep 2025 14:48:22 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 10 10:48:22 2025 Received: from localhost ([127.0.0.1]:38661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uwM7R-0006SU-9g for submit <at> debbugs.gnu.org; Wed, 10 Sep 2025 10:48:22 -0400 Received: from mail-vs1-xe2a.google.com ([2607:f8b0:4864:20::e2a]:57637) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1uwM7N-0006S8-IJ for 69837 <at> debbugs.gnu.org; Wed, 10 Sep 2025 10:48:18 -0400 Received: by mail-vs1-xe2a.google.com with SMTP id ada2fe7eead31-50f8bf5c518so5241934137.3 for <69837 <at> debbugs.gnu.org>; Wed, 10 Sep 2025 07:48:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757515691; x=1758120491; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uTtvyFPn1Dm0uyhCT8Rv70cHs3SICxj3nVqBsPFE36w=; b=JzI8pRq7zHVjZLWfMLwoo7UEa4MdNOpMF4XZeIp+78l5G7oF02SOoVJRvEEN+lDdf+ 8GsdunkCH/V+jRqacKwgjSFzQ8yfOpF37UJaQ41NJosChLxDRclf2NOeY8GuA1RKAWQN MHHrrvRsT/WdwsWM/nEE1P7WMB5wxDRFh8lmKKITU1TETloUqHot7dccrz1sWQ+euSLD uhPJWpsG84D/Svk56vRoMuoMngSnf20yPXYFQPw2qtoWYGbeZkjIfjNR5HS6QwGoeU72 z814jmHfytsflkmJd3s2mjHR2vHwPrqrAE6s/mQrsGi6sORgpfaE+p1JrxXBoRCbxkEw f+2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757515691; x=1758120491; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uTtvyFPn1Dm0uyhCT8Rv70cHs3SICxj3nVqBsPFE36w=; b=FCdiMGMADp83T40uf6nwYyvdLEzsZqEhKjOzqd+ePI2RAzRlI9b2evUL1iJSbMv3Po YSuRtaBj60/zEtFzJppqqElFxxDBTOyiEqGAtqDbIt+AyvPRY+51ZV2jVPAZ4M1CaPFC Arvhk0hIolX2mdKhBOgk6Ls2eIXuwhXTjJPW1V+yIYJ6HZoq0lyVUjwaWtLwQ+odpaxy kgXfzeK/p1RtwwapRk5P8nwkP1zUogyj6pqLQHyLyfIu96d8oho3TWBRe/RxK97ui1Xl UCNiDyEdmx02/dW3ApMSpf+Ehz5aPh3Vuoo2oInVSZyOSuso/grkGsXkEs53GyLRC0aG H31g== X-Forwarded-Encrypted: i=1; AJvYcCXeMsX+NE/yQ7OyfXET9ffg65ngkH4XDhDwnNspXQI9v5BaYkC8G0ysGkDCvet5Wrm1ScdeiQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yz4Y2erwwhdo4jSUt4ZknKbJhbVoVD3NBaK8GHh7aCkdhdkZLCt tAxmRWpNFYIHutW6HwyqZjF1wRpwlwKionWj1Kt/EwkpEuTegB1YR3aqbxB+f9EsE0+7TJT0plI VN9y9pmxm12Zd8JRCxh2+LLpyZxz1FRA= X-Gm-Gg: ASbGnctETcDjgYYtiyU0wlvcW9yKTq6gLhQKATNTGmxfYzCF2ZNQgeaXTvtXC1k21hq gcHA4m3ADUbK2+ADi1y49R/skBrZRQZPEThtkq7lLHkx97B6fKihMtjOdRRqligohigIi0/7GZD p7CxSf75M0XZc3mKLBnjU7saIfwzwqNH/RAM7kI+52mdQimAZuqYVRmjykbeCWC68XoGNbrrqNI +TleG6eQNVA1lP651+zWwWAjFaslRD2qjqj7bCgFrTPWHy1vXFDOxV4/5es4FxrwpobD7F+3Il4 5oilSAe7q8guCIOsXqbQRY7Pe5g858qiM4vapudqi3MDKDpQhwfLPk98pWR/IGtAIwB5AbwQ2KS zp96MnMxVJu79tEDQhc43lznajBI= X-Google-Smtp-Source: AGHT+IHT7FIR8CUImvf1WlsWZ9nWnLQ2pBCA0OEzwFBIdIK9N1MXNGfPx02x5Zy6SC6w716fe52ObelHJMRaocBqBeY= X-Received: by 2002:a05:6102:32d0:b0:519:534a:6c49 with SMTP id ada2fe7eead31-53d24a0579amr5685528137.35.1757515690629; Wed, 10 Sep 2025 07:48:10 -0700 (PDT) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> In-Reply-To: <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Wed, 10 Sep 2025 10:47:59 -0400 X-Gm-Features: AS18NWDqBuuFPym66TQQfI84Z9fwPjOWOj6aEKpIgk7fmAeMwPdfu2A9h18Nyv4 Message-ID: <CAN+1HbrUgaG8s9zmReUQcBWvxucjDEAO_ogaLU43rVp92uBDnQ@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000006d6052063e738298" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --0000000000006d6052063e738298 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Sep 4, 2025 at 3:05=E2=80=AFPM St=C3=A9phane Marks <shipmints@gmail= .com> wrote: > On Wed, Sep 3, 2025 at 12:30=E2=80=AFPM Spencer Baugh <sbaugh@janestreet.= com> > wrote: > >> Spencer Baugh <sbaugh@HIDDEN> writes: >> > St=C3=A9phane Marks <shipmints@HIDDEN> writes: >> >> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports= for GNU >> Emacs, the Swiss army knife of text editors >> >> <bug-gnu-emacs@HIDDEN> wrote: >> >> >> >> Stefan Kangas <stefankangas@HIDDEN> writes: >> >> >> >> > Eli Zaretskii <eliz@HIDDEN> writes: >> >> > >> >> >>> 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 slight= ly >> >> >>> incorrect width, which is easily rectified by reverting the tabl= e >> >> >>> (usually bound to "g"). As well, that worst case (e.g. imaginin= g >> 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. >> >> > >> >> > Adam, could you please install the workaround? Or maybe you did >> >> > already? >> >> >> >> I ran into this same problem. I think Adam's workaround is on the >> right >> >> track, but the issue is present in a number of other functions in >> >> vtable.el, not just vtable-update-object. >> >> >> >> The root of the issue is that when we're interacting with the text o= f >> an >> >> inserted vtable, we should use the "cache" object that was last used >> to >> >> insert that vtable, rather than one based on the current selected >> window >> >> and terminal. Otherwise we will experience various inconsistencies, >> >> e.g. inserting a new line that has different column widths from the >> rest >> >> of the vtable text. >> >> >> >> My attached patch solves this by saving the "cache" object in a text >> >> property on the vtable text, and updating all the relevant vtable >> >> functions to access the cache via that text property rather than by >> >> computing a cache key from the current selected window/terminal. >> >> >> >> Adam, could you check that this solves the problem for your use case= ? >> >> >> >> I have a very big patch coming for vtable under >> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843 which addresses th= is >> issue, >> >> and a ton of other bugs (and features). That's coming in the next da= y >> or so, if you can wait? >> > >> > Certainly I can wait. Cc me when you send the patch. >> > >> > Though if your patch is very large, maybe this relatively small patch >> > should land first. >> >> Since it's been a while and this large patch has not landed, I suggest >> we should install my patch now to close this bug. St=C3=A9phane's patch= can >> simply be rebased on top later. >> > > I'll try to get back into vtable this weekend and take a fresh look. > I'll have some time tomorrow to test and react. I have one amendment that enhances the patch in the case where a vtable is inserted in a window-less buffer. My larger patch has such an accommodation. --0000000000006d6052063e738298 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Thu, Sep 4, 2025 at 3:05=E2=80=AFPM St=C3=A9phane Marks <<a href=3D"m= ailto:shipmints@HIDDEN">shipmints@HIDDEN</a>> wrote:</span></div><= /div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"= gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20= 4,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr"><div style= =3D"font-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-= serif">On Wed, Sep 3, 2025 at 12:30=E2=80=AFPM Spencer Baugh <<a href=3D= "mailto:sbaugh@HIDDEN" target=3D"_blank">sbaugh@HIDDEN</a>&= gt; wrote:</span></div></div><div class=3D"gmail_quote"><blockquote class= =3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rg= b(204,204,204);padding-left:1ex">Spencer Baugh <<a href=3D"mailto:sbaugh= @janestreet.com" target=3D"_blank">sbaugh@HIDDEN</a>> writes:<br= > > St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" target= =3D"_blank">shipmints@HIDDEN</a>> writes:<br> >> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug repo= rts for GNU Emacs, the Swiss army knife of text editors<br> >> <<a href=3D"mailto:bug-gnu-emacs@HIDDEN" target=3D"_blank">bug= -gnu-emacs@HIDDEN</a>> wrote:<br> >><br> >>=C2=A0 Stefan Kangas <<a href=3D"mailto:stefankangas@HIDDEN" = target=3D"_blank">stefankangas@HIDDEN</a>> writes:<br> >><br> >>=C2=A0 > Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" targe= t=3D"_blank">eliz@HIDDEN</a>> writes:<br> >>=C2=A0 ><br> >>=C2=A0 >>> Date: Thu, 21 Mar 2024 03:36:02 -0500<br> >>=C2=A0 >>> Cc: <a href=3D"mailto:69837 <at> debbugs.gnu.org" ta= rget=3D"_blank">69837 <at> debbugs.gnu.org</a><br> >>=C2=A0 >>> From: Adam Porter <<a href=3D"mailto:adam@al= phapapa.net" target=3D"_blank">adam@HIDDEN</a>><br> >>=C2=A0 >>><br> >>=C2=A0 >>> FWIW, I did some hacking on listen.el attemptin= g to further understand<br> >>=C2=A0 >>> and work around this problem, and I've foun= d what seems to be a usable<br> >>=C2=A0 >>> workaround (for my purposes, anyway).<br> >>=C2=A0 >>><br> >>=C2=A0 >>> The attached code defines a macro within which = I call<br> >>=C2=A0 >>> `listen-queue--vtable-update-object' (which= merely incorporates the fix<br> >>=C2=A0 >>> to `vtable-update-object' from bug#69664).= =C2=A0 As well, I wrap<br> >>=C2=A0 >>> `make-vtable' in a function that also sets = two buffer-local variables to<br> >>=C2=A0 >>> the values of `frame-terminal' and `window-= width' at the time of the<br> >>=C2=A0 >>> vtable's creation.=C2=A0 The macro locally = overrides the functions<br> >>=C2=A0 >>> `frame-terminal' and `window-width' to = return those saved values.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> This allows the cache key to match unconditiona= lly, which allows the<br> >>=C2=A0 >>> vtable's objects to be updated even when it= s buffer is not visible.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> In my limited testing, it seems to work fine.= =C2=A0 In my estimation, the<br> >>=C2=A0 >>> consequences of doing this in the worst case wo= uld be that the rows for<br> >>=C2=A0 >>> the updated objects might be drawn with some co= lumns at a slightly<br> >>=C2=A0 >>> incorrect width, which is easily rectified by r= everting the table<br> >>=C2=A0 >>> (usually bound to "g").=C2=A0 As well= , that worst case (e.g. imagining a<br> >>=C2=A0 >>> vtable whose buffer might be initially displaye= d on one terminal/monitor<br> >>=C2=A0 >>> and later on another with different characteris= tics) would seem to be<br> >>=C2=A0 >>> relatively rare (so for my project, it seems li= ke an obviously good<br> >>=C2=A0 >>> thing to do).<br> >>=C2=A0 >>><br> >>=C2=A0 >>> For Emacs itself, I'm not sure what the bes= t fix would be.=C2=A0 I suppose a<br> >>=C2=A0 >>> workaround like this could be implemented as a = fallback in case the<br> >>=C2=A0 >>> cache key misses; it would seem better to updat= e the object potentially<br> >>=C2=A0 >>> sub-optimally than to error and not update it a= t all.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> Another possibility would be to ignore the fram= e-terminal and<br> >>=C2=A0 >>> window-width in the cache key altogether (i.e. = so they would always be<br> >>=C2=A0 >>> assumed to be the same), but I'm sure that = Lars did it this way for a<br> >>=C2=A0 >>> reason, so that would seem unwise.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> Let me know how you'd like me to proceed.<b= r> >>=C2=A0 >><br> >>=C2=A0 >> I think you should install your workaround.=C2=A0 I= don't see how it could<br> >>=C2=A0 >> be worse than what we have now.<br> >>=C2=A0 >><br> >>=C2=A0 >> P.S. And sorry for a long silence.<br> >>=C2=A0 ><br> >>=C2=A0 > Adam, could you please install the workaround?=C2=A0 Or= maybe you did<br> >>=C2=A0 > already?<br> >><br> >>=C2=A0 I ran into this same problem.=C2=A0 I think Adam's worka= round is on the right<br> >>=C2=A0 track, but the issue is present in a number of other functio= ns in<br> >>=C2=A0 vtable.el, not just vtable-update-object.<br> >><br> >>=C2=A0 The root of the issue is that when we're interacting wit= h the text of an<br> >>=C2=A0 inserted vtable, we should use the "cache" object = that was last used to<br> >>=C2=A0 insert that vtable, rather than one based on the current sel= ected window<br> >>=C2=A0 and terminal.=C2=A0 Otherwise we will experience various inc= onsistencies,<br> >>=C2=A0 e.g. inserting a new line that has different column widths f= rom the rest<br> >>=C2=A0 of the vtable text.<br> >><br> >>=C2=A0 My attached patch solves this by saving the "cache"= ; object in a text<br> >>=C2=A0 property on the vtable text, and updating all the relevant v= table<br> >>=C2=A0 functions to access the cache via that text property rather = than by<br> >>=C2=A0 computing a cache key from the current selected window/termi= nal.<br> >><br> >>=C2=A0 Adam, could you check that this solves the problem for your = use case?<br> >><br> >> I have a very big patch coming for vtable under <a href=3D"https:/= /debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843" rel=3D"noreferrer" target= =3D"_blank">https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843</a> which= addresses this issue,<br> >> and a ton of other bugs (and features).=C2=A0 That's coming in= the next day or so, if you can wait?<br> ><br> > Certainly I can wait.=C2=A0 Cc me when you send the patch.<br> ><br> > Though if your patch is very large, maybe this relatively small patch<= br> > should land first.<br> <br> Since it's been a while and this large patch has not landed, I suggest<= br> we should install my patch now to close this bug.=C2=A0 St=C3=A9phane's= patch can<br> simply be rebased on top later.<br></blockquote><div><br></div><div style= =3D"font-family:monospace">I'll try to get back into vtable this weeken= d and take a fresh look.</div></div></div></blockquote><div><br></div><div = class=3D"gmail_default" style=3D"font-family:monospace">I'll have some = time tomorrow to test and react. I have one amendment that enhances the pat= ch in the case where a vtable is inserted in a window-less buffer. My large= r patch has such an accommodation.</div></div></div> --0000000000006d6052063e738298--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 4 Sep 2025 19:05:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Sep 04 15:05:40 2025 Received: from localhost ([127.0.0.1]:49270 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uuFH8-0007aX-Rm for submit <at> debbugs.gnu.org; Thu, 04 Sep 2025 15:05:40 -0400 Received: from mail-vk1-xa2a.google.com ([2607:f8b0:4864:20::a2a]:57487) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1uuFGz-0007a7-2f for 69837 <at> debbugs.gnu.org; Thu, 04 Sep 2025 15:05:34 -0400 Received: by mail-vk1-xa2a.google.com with SMTP id 71dfb90a1353d-544ad727e87so1110937e0c.2 for <69837 <at> debbugs.gnu.org>; Thu, 04 Sep 2025 12:05:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1757012723; x=1757617523; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=82D1CgPuFJXpuenPPCPmpQX+u2KZaMBaaxKYUIZf1Ak=; b=kRQ4F7pn+6YjbkYnLk9fydAKCTzTS+PsQAO4mQnOn4jkeqULtCGUVUjGoMUhk3QMC0 9quXfG0Ip1OM2kCtuaBExwF4e5UGXcg3AoX7vbUERQbuR263wqrFkg1piEgtzxOPppt3 qqIy6aoY8JTqrwQCituiZ8a4szK3foM+vohCr1BxEn0gdGRgxzN9A7O65nNeXfGLDNxw DuP1/bTOnR0/4tDH6160IR69h2l35t9OgRHK21z8qrNUmcXEPb8CoI8+uhkrSxXOidZD Ve9aIMpbNYl+dPQlPYkx3fgyBxuxbzoU+mlOb+BYm+asU0nbUhAnZUjA4hzFrM+NFKii N5DQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1757012723; x=1757617523; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=82D1CgPuFJXpuenPPCPmpQX+u2KZaMBaaxKYUIZf1Ak=; b=oQtkoh7tYx5xgBuobJqYq/M1c96+eThfYLb6gjWzqXuh3oeaDkCGfEs5e0V4fFLlaO S2atuYy9TkXJOR871Qifyf4zIq1HFkM0JTpVBBdGt912lp/c9PzfsF/ilHMDvBGQCi9r fMqIlI5oPcHOMNyNrXntWFCyW6Qof7b9znauKVzNXPH7wOdRWXFv2uXHt5YTUYVcCrTy RkuWnGlOphyvuzixR6yHK5wprz9xvuVg9FjTNw2+pL5wHdPxt1kyDQWMxxIIIW3VlCEB JBwwlRfMn62F6cJABBbP7Ha+T7ybPen9dV1DLPLT2skF08BnIcTNmprk77IYs3Mxw1zx 3F/A== X-Forwarded-Encrypted: i=1; AJvYcCVrM+gcJL0DwAWAAHjKnGtkUYgHXxW483CeIZvR8DuOh4XUubaIAyry7gXb9b2An3CC5hms7g==@debbugs.gnu.org X-Gm-Message-State: AOJu0YzCBHoON2IQx8Dffsk2z0FRtn1gEH0jsMP6s0OgV093XApyr2vg 2Uu+I37AzsnjsBbzIWgdR2SaEAD8c1TVlNyLBTWt0PtvQxh7s9X4n2lYj73WRfyJG4nNjkeBfzA LuitohqWxbcbs3uT9CTBvefLKHREHaZM= X-Gm-Gg: ASbGncsHr4lVSVmd/nV93mHdDzd6zUEzS91plmGDPcLCdFJTJgmJEmWvAPNg5AGSC34 FPuz4IGkRsNM8lOZrTUajnsiNhMi7YO/eoe361Z44eLzFAo3ASma8hM37FQ7txjIEcnX8OanRZ6 pH3tF6EMiBrMf2CI5YGNLBXZSBPKcdKOjLXDzIo3J+4+Vr/mBRQ9MASwLFUSlAsW7CSaLrJ9aVr n5F8U9WHf023j9nkXHF/1LXzIDZJ02QzD9oQ91DCQKYTrxCntL8fRVPZpZB8qsjhGEJk7F+wGrP zQLETK1ID0w8bCyUm2gc6NYGKMnCq3Q7ukhhYTcMPN9jt02KuUrmNXOV1GTInZWQ9Pf5fagPFps 8HpLe3rWpmetWT+R1X7//xarqNvrcZw== X-Google-Smtp-Source: AGHT+IFwVm9eXY1S+9DdhCmaytQiljfX+QcEYIhUCRU6JO7K/fGVqVpiD3kN2ZfV8xzc/RcQ6ctIT6iIK2Rdom6DnLo= X-Received: by 2002:a05:6102:598e:b0:521:ed06:1fc7 with SMTP id ada2fe7eead31-52b166d84eamr7199260137.0.1757012722740; Thu, 04 Sep 2025 12:05:22 -0700 (PDT) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> <iery0qvjy74.fsf_-_@HIDDEN> In-Reply-To: <iery0qvjy74.fsf_-_@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Thu, 4 Sep 2025 15:05:11 -0400 X-Gm-Features: Ac12FXwo40kpQzAsLP-CLLq_jxhO8u7SRP_eOrNEYCi3tPj5ALE8tx6eSqHHqok Message-ID: <CAN+1HbqV2FNbTHEgDJn8uMihvFVM5H8eYGjpwpDno5cZHJXsiA@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="00000000000034736e063dfe674e" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --00000000000034736e063dfe674e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Sep 3, 2025 at 12:30=E2=80=AFPM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > Spencer Baugh <sbaugh@HIDDEN> writes: > > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > >> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports = for GNU > Emacs, the Swiss army knife of text editors > >> <bug-gnu-emacs@HIDDEN> wrote: > >> > >> Stefan Kangas <stefankangas@HIDDEN> writes: > >> > >> > Eli Zaretskii <eliz@HIDDEN> writes: > >> > > >> >>> 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 visibl= e. > >> >>> > >> >>> 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 slightl= y > >> >>> 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 t= o > be > >> >>> relatively rare (so for my project, it seems like an obviously go= od > >> >>> 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 t= he > >> >>> 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. > >> > > >> > Adam, could you please install the workaround? Or maybe you did > >> > already? > >> > >> I ran into this same problem. I think Adam's workaround is on the > right > >> track, but the issue is present in a number of other functions in > >> vtable.el, not just vtable-update-object. > >> > >> The root of the issue is that when we're interacting with the text of > an > >> inserted vtable, we should use the "cache" object that was last used = to > >> insert that vtable, rather than one based on the current selected > window > >> and terminal. Otherwise we will experience various inconsistencies, > >> e.g. inserting a new line that has different column widths from the > rest > >> of the vtable text. > >> > >> My attached patch solves this by saving the "cache" object in a text > >> property on the vtable text, and updating all the relevant vtable > >> functions to access the cache via that text property rather than by > >> computing a cache key from the current selected window/terminal. > >> > >> Adam, could you check that this solves the problem for your use case? > >> > >> I have a very big patch coming for vtable under > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843 which addresses thi= s > issue, > >> and a ton of other bugs (and features). That's coming in the next day > or so, if you can wait? > > > > Certainly I can wait. Cc me when you send the patch. > > > > Though if your patch is very large, maybe this relatively small patch > > should land first. > > Since it's been a while and this large patch has not landed, I suggest > we should install my patch now to close this bug. St=C3=A9phane's patch = can > simply be rebased on top later. > I'll try to get back into vtable this weekend and take a fresh look. --00000000000034736e063dfe674e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Wed, Sep 3, 2025 at 12:30=E2=80=AFPM Spencer Baugh <<a href=3D"mailto= :sbaugh@HIDDEN">sbaugh@HIDDEN</a>> wrote:</span></div></= div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">Spencer Baugh <<a href=3D"mailto:sbaugh@jane= street.com" target=3D"_blank">sbaugh@HIDDEN</a>> writes:<br> > St=C3=A9phane Marks <<a href=3D"mailto:shipmints@HIDDEN" target= =3D"_blank">shipmints@HIDDEN</a>> writes:<br> >> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug repo= rts for GNU Emacs, the Swiss army knife of text editors<br> >> <<a href=3D"mailto:bug-gnu-emacs@HIDDEN" target=3D"_blank">bug= -gnu-emacs@HIDDEN</a>> wrote:<br> >><br> >>=C2=A0 Stefan Kangas <<a href=3D"mailto:stefankangas@HIDDEN" = target=3D"_blank">stefankangas@HIDDEN</a>> writes:<br> >><br> >>=C2=A0 > Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" targe= t=3D"_blank">eliz@HIDDEN</a>> writes:<br> >>=C2=A0 ><br> >>=C2=A0 >>> Date: Thu, 21 Mar 2024 03:36:02 -0500<br> >>=C2=A0 >>> Cc: <a href=3D"mailto:69837 <at> debbugs.gnu.org" ta= rget=3D"_blank">69837 <at> debbugs.gnu.org</a><br> >>=C2=A0 >>> From: Adam Porter <<a href=3D"mailto:adam@al= phapapa.net" target=3D"_blank">adam@HIDDEN</a>><br> >>=C2=A0 >>><br> >>=C2=A0 >>> FWIW, I did some hacking on listen.el attemptin= g to further understand<br> >>=C2=A0 >>> and work around this problem, and I've foun= d what seems to be a usable<br> >>=C2=A0 >>> workaround (for my purposes, anyway).<br> >>=C2=A0 >>><br> >>=C2=A0 >>> The attached code defines a macro within which = I call<br> >>=C2=A0 >>> `listen-queue--vtable-update-object' (which= merely incorporates the fix<br> >>=C2=A0 >>> to `vtable-update-object' from bug#69664).= =C2=A0 As well, I wrap<br> >>=C2=A0 >>> `make-vtable' in a function that also sets = two buffer-local variables to<br> >>=C2=A0 >>> the values of `frame-terminal' and `window-= width' at the time of the<br> >>=C2=A0 >>> vtable's creation.=C2=A0 The macro locally = overrides the functions<br> >>=C2=A0 >>> `frame-terminal' and `window-width' to = return those saved values.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> This allows the cache key to match unconditiona= lly, which allows the<br> >>=C2=A0 >>> vtable's objects to be updated even when it= s buffer is not visible.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> In my limited testing, it seems to work fine.= =C2=A0 In my estimation, the<br> >>=C2=A0 >>> consequences of doing this in the worst case wo= uld be that the rows for<br> >>=C2=A0 >>> the updated objects might be drawn with some co= lumns at a slightly<br> >>=C2=A0 >>> incorrect width, which is easily rectified by r= everting the table<br> >>=C2=A0 >>> (usually bound to "g").=C2=A0 As well= , that worst case (e.g. imagining a<br> >>=C2=A0 >>> vtable whose buffer might be initially displaye= d on one terminal/monitor<br> >>=C2=A0 >>> and later on another with different characteris= tics) would seem to be<br> >>=C2=A0 >>> relatively rare (so for my project, it seems li= ke an obviously good<br> >>=C2=A0 >>> thing to do).<br> >>=C2=A0 >>><br> >>=C2=A0 >>> For Emacs itself, I'm not sure what the bes= t fix would be.=C2=A0 I suppose a<br> >>=C2=A0 >>> workaround like this could be implemented as a = fallback in case the<br> >>=C2=A0 >>> cache key misses; it would seem better to updat= e the object potentially<br> >>=C2=A0 >>> sub-optimally than to error and not update it a= t all.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> Another possibility would be to ignore the fram= e-terminal and<br> >>=C2=A0 >>> window-width in the cache key altogether (i.e. = so they would always be<br> >>=C2=A0 >>> assumed to be the same), but I'm sure that = Lars did it this way for a<br> >>=C2=A0 >>> reason, so that would seem unwise.<br> >>=C2=A0 >>><br> >>=C2=A0 >>> Let me know how you'd like me to proceed.<b= r> >>=C2=A0 >><br> >>=C2=A0 >> I think you should install your workaround.=C2=A0 I= don't see how it could<br> >>=C2=A0 >> be worse than what we have now.<br> >>=C2=A0 >><br> >>=C2=A0 >> P.S. And sorry for a long silence.<br> >>=C2=A0 ><br> >>=C2=A0 > Adam, could you please install the workaround?=C2=A0 Or= maybe you did<br> >>=C2=A0 > already?<br> >><br> >>=C2=A0 I ran into this same problem.=C2=A0 I think Adam's worka= round is on the right<br> >>=C2=A0 track, but the issue is present in a number of other functio= ns in<br> >>=C2=A0 vtable.el, not just vtable-update-object.<br> >><br> >>=C2=A0 The root of the issue is that when we're interacting wit= h the text of an<br> >>=C2=A0 inserted vtable, we should use the "cache" object = that was last used to<br> >>=C2=A0 insert that vtable, rather than one based on the current sel= ected window<br> >>=C2=A0 and terminal.=C2=A0 Otherwise we will experience various inc= onsistencies,<br> >>=C2=A0 e.g. inserting a new line that has different column widths f= rom the rest<br> >>=C2=A0 of the vtable text.<br> >><br> >>=C2=A0 My attached patch solves this by saving the "cache"= ; object in a text<br> >>=C2=A0 property on the vtable text, and updating all the relevant v= table<br> >>=C2=A0 functions to access the cache via that text property rather = than by<br> >>=C2=A0 computing a cache key from the current selected window/termi= nal.<br> >><br> >>=C2=A0 Adam, could you check that this solves the problem for your = use case?<br> >><br> >> I have a very big patch coming for vtable under <a href=3D"https:/= /debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843" rel=3D"noreferrer" target= =3D"_blank">https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843</a> which= addresses this issue,<br> >> and a ton of other bugs (and features).=C2=A0 That's coming in= the next day or so, if you can wait?<br> ><br> > Certainly I can wait.=C2=A0 Cc me when you send the patch.<br> ><br> > Though if your patch is very large, maybe this relatively small patch<= br> > should land first.<br> <br> Since it's been a while and this large patch has not landed, I suggest<= br> we should install my patch now to close this bug.=C2=A0 St=C3=A9phane's= patch can<br> simply be rebased on top later.<br></blockquote><div><br></div><div class= =3D"gmail_default" style=3D"font-family:monospace">I'll try to get back= into vtable this weekend and take a fresh look.</div></div></div> --00000000000034736e063dfe674e--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 3 Sep 2025 16:30:33 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Wed Sep 03 12:30:33 2025 Received: from localhost ([127.0.0.1]:41243 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1utqNV-000369-60 for submit <at> debbugs.gnu.org; Wed, 03 Sep 2025 12:30:33 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:58031) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>) id 1utqNR-00035t-8W for 69837 <at> debbugs.gnu.org; Wed, 03 Sep 2025 12:30:31 -0400 From: Spencer Baugh <sbaugh@HIDDEN> To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows, [PATCH] Fix implicit usage of the current window-width in vtable.el In-Reply-To: <iertt4bjsoc.fsf@HIDDEN> (Spencer Baugh's message of "Thu, 19 Jun 2025 18:02:59 -0400") 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> Date: Wed, 03 Sep 2025 12:30:23 -0400 Message-ID: <iery0qvjy74.fsf_-_@HIDDEN> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=waixah; t=1756917023; bh=rnYzVbcCPpbX0EAV7icRMMk7jzDY+FUzMuHdJJN43m8=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=BmSzTva9l+4PSXrOEUpkDXP+y4GOuBLuAcCFKQa7HZukwx+MsGC5kV0xw3Onu8i8Y o6Pzr7UinOTSqbtN0dGxDe03lCXW3LmtwYBp/IK1OdJ7uEYGYxYQrx/sr1nR/2DG2x sKx5yIKOdzzMs0e9E0Y/vzMwRxMGh0PZm04l99Mc/rn+LECr8DziI95U3dojsMsc8m U058Y6tvtYXu7VwM2D16pD2NvzcBi9oCoZnLZyIqRpD7F2zr57nAWVvLvJGF35kbCH OYHDXFpoIlE1P0yQ8D2Ul3JfAJ73h48eIRyb4uMcCfeAiS0vhOEiNnam6oJZCb5viV Clllb85RTQGXQ== X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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 (---) Spencer Baugh <sbaugh@HIDDEN> writes: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: >> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports fo= r GNU Emacs, the Swiss army knife of text editors >> <bug-gnu-emacs@HIDDEN> wrote: >> >> Stefan Kangas <stefankangas@HIDDEN> writes: >> >> > Eli Zaretskii <eliz@HIDDEN> writes: >> > >> >>> 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 underst= and >> >>> and work around this problem, and I've found what seems to be a usa= ble >> >>> 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 variabl= es 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/mo= nitor >> >>> 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 suppo= se a >> >>> workaround like this could be implemented as a fallback in case the >> >>> cache key misses; it would seem better to update the object potenti= ally >> >>> 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. >> > >> > Adam, could you please install the workaround? Or maybe you did >> > already? >> >> I ran into this same problem. I think Adam's workaround is on the right >> track, but the issue is present in a number of other functions in >> vtable.el, not just vtable-update-object. >> >> The root of the issue is that when we're interacting with the text of an >> inserted vtable, we should use the "cache" object that was last used to >> insert that vtable, rather than one based on the current selected window >> and terminal. Otherwise we will experience various inconsistencies, >> e.g. inserting a new line that has different column widths from the rest >> of the vtable text. >> >> My attached patch solves this by saving the "cache" object in a text >> property on the vtable text, and updating all the relevant vtable >> functions to access the cache via that text property rather than by >> computing a cache key from the current selected window/terminal. >> >> Adam, could you check that this solves the problem for your use case? >> >> I have a very big patch coming for vtable under https://debbugs.gnu.org/= cgi/bugreport.cgi?bug=3D78843 which addresses this issue, >> and a ton of other bugs (and features). That's coming in the next day o= r so, if you can wait? > > Certainly I can wait. Cc me when you send the patch. > > Though if your patch is very large, maybe this relatively small patch > should land first. Since it's been a while and this large patch has not landed, I suggest we should install my patch now to close this bug. St=C3=A9phane's patch can simply be rebased on top later.
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 19 Jun 2025 22:07:10 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 19 18:07:10 2025 Received: from localhost ([127.0.0.1]:38784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uSNPU-000524-NF for submit <at> debbugs.gnu.org; Thu, 19 Jun 2025 18:07:10 -0400 Received: from mail-vs1-xe34.google.com ([2607:f8b0:4864:20::e34]:45294) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1uSNPP-0004zh-Dg for 69837 <at> debbugs.gnu.org; Thu, 19 Jun 2025 18:07:02 -0400 Received: by mail-vs1-xe34.google.com with SMTP id ada2fe7eead31-4e9a1090360so334089137.2 for <69837 <at> debbugs.gnu.org>; Thu, 19 Jun 2025 15:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750370813; x=1750975613; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=XwaLwJqmNYDy6gF4/HZcNJuJ6TysHPdK/socLQCT2hk=; b=FgtO30+T4FL/b22TUXItmUgHU9lb0pL6oXXnyxoJhynVHJBQVZ2NTQtrYzSx+o+R2J PMBdCGndFzP1DkdiyoF/Ix+4jVt/t/EVBHF61VepedPgAulVrzjUFqcIdA7GDUJlkhMZ ZQzspzDRQAoZ93yDy2NEISAfHkmYIksbge9MtOTBt1LeYge4qM2iCyBurVamZ3cTNNN1 H+DgPEMliqA4cjWRs3lOX4zPNEnacPt9/7NpqqdsL3Y6g8Cr+Iz9SI6mFFGwe9KWAzrY Db6+6c65rcxMyusPtKac4SbgA8gFvTsewxFD+P93SMDZmO8LYcZYu80lgvBmTIRyUAUE 3kOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750370813; x=1750975613; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=XwaLwJqmNYDy6gF4/HZcNJuJ6TysHPdK/socLQCT2hk=; b=IV5zDMsIWH+uLQX2QKjELqlzBTJFJeVt5CauJ52RMEatouiUu/M93rrxzRqJCQBsCe nc6xYOVUOgUSrFNya7ckW/wRpVuCY9HZVS1bbcBgLdTmNFny8SjMCdkOlfRIhTPmhIiO SRMscGXEmLXh0QjK3Ba4Q+hM4N1l5ZNxeXu9tX37968ELTBDzbqLMj6+vMUNiJ2zz7oX K6wgPsa+/9sHAPjjCjgWnGxtAZJpF1jp+Mg40xdsw/lD/boTksZZDjb+/FDi8H5lqF8G tMsgzJaystbvR+cVrz9pffqmBtUZm+/3w59OKKmQFkGxnjwwoJh4mL81VeXPhoAxuPG2 j2KQ== X-Forwarded-Encrypted: i=1; AJvYcCWjTZcPl8DQifz4pTi0UPaQrxmphku8ykFuivyiJ2jZubej7tbz+nl1tUHzak4Iw0wcUFvW2Q==@debbugs.gnu.org X-Gm-Message-State: AOJu0Yw934ZBsQOcsGnM27MDQ3eulPoSEkJX+JSRQUp5agDPIgD/k69a y0iUqrjMH8q9UWoyXqZ84rDltvEV9ibpCntGhY97ESlMPwlMVbLuiDKePAzUblbjU/JIFbDaZZl qlywB0sDXjDzOdiH04FuvhKvi3L4fP0c= X-Gm-Gg: ASbGncuYTj9uLdYnwnPoMtXmaDM6FrvsD2/fMTs8uHtmwSXNw69JlxQZO/wcWsJV5EC /SqoJapssX83TjOowT8ZQyFE+m72/nLO83UrjT3uMi9N6KJUjwVEPTwLgECwgktYfBGcTq+zXsG Fjo4kq5BI270Y4nSkLrwOH9D34Eh0m3QZS6ZBKg67wJJWhFQ== X-Google-Smtp-Source: AGHT+IHOd0F4XkKa/rm6polav0OU7SEwP1tNgJFveVZzDGBe2aBACzMckap6g8nC5m4X6aGMqK4gQx/wpa1xhYEVR/k= X-Received: by 2002:a05:6102:c4e:b0:4e4:8362:dce9 with SMTP id ada2fe7eead31-4e9c2845786mr414127137.9.1750370813393; Thu, 19 Jun 2025 15:06:53 -0700 (PDT) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> <iertt4bjsoc.fsf@HIDDEN> In-Reply-To: <iertt4bjsoc.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Thu, 19 Jun 2025 18:06:40 -0400 X-Gm-Features: Ac12FXyOAXp-oxWkWhbuNrvbl4Z1hJyVWcpnVHYr4Hn_569CbbFCwIvm5GWPejc Message-ID: <CAN+1HbrGcReGHrtsxHdHLiwr+eV1Wm12BfWcwrtVD19D4cBAHQ@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="0000000000008ec0ca0637f3f619" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --0000000000008ec0ca0637f3f619 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 19, 2025 at 6:02=E2=80=AFPM Spencer Baugh <sbaugh@HIDDEN= m> wrote: > St=C3=A9phane Marks <shipmints@HIDDEN> writes: > > On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports f= or GNU > Emacs, the Swiss army knife of text editors > > <bug-gnu-emacs@HIDDEN> wrote: > > > > Stefan Kangas <stefankangas@HIDDEN> writes: > > > > > Eli Zaretskii <eliz@HIDDEN> writes: > > > > > >>> 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 th= e > 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 t= he > > >>> 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 t= he > > >>> 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, t= he > > >>> consequences of doing this in the worst case would be that the row= s > 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 goo= d > > >>> 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 th= e > > >>> 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 alway= s > be > > >>> assumed to be the same), but I'm sure that Lars did it this way fo= r > 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 cou= ld > > >> be worse than what we have now. > > >> > > >> P.S. And sorry for a long silence. > > > > > > Adam, could you please install the workaround? Or maybe you did > > > already? > > > > I ran into this same problem. I think Adam's workaround is on the rig= ht > > track, but the issue is present in a number of other functions in > > vtable.el, not just vtable-update-object. > > > > The root of the issue is that when we're interacting with the text of = an > > inserted vtable, we should use the "cache" object that was last used t= o > > insert that vtable, rather than one based on the current selected wind= ow > > and terminal. Otherwise we will experience various inconsistencies, > > e.g. inserting a new line that has different column widths from the re= st > > of the vtable text. > > > > My attached patch solves this by saving the "cache" object in a text > > property on the vtable text, and updating all the relevant vtable > > functions to access the cache via that text property rather than by > > computing a cache key from the current selected window/terminal. > > > > Adam, could you check that this solves the problem for your use case? > > > > I have a very big patch coming for vtable under > https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843 which addresses thi= s > issue, > > and a ton of other bugs (and features). That's coming in the next day > or so, if you can wait? > > Certainly I can wait. Cc me when you send the patch. > > Though if your patch is very large, maybe this relatively small patch > should land first. > > (Also, I hope that you're adding tests in your very large patch?) > > BTW, an updated version of my patch is attached, just fixing a silly bug > that was in the first version. > Your patch doesn't address several other intertwined issues that my bigger patch addresses. I've been testing it for ages now and with other vtable users. I can send a new vtable.el and vtable.texi to you off line if you'd like a look before I finish writing the long changelog. -St=C3=A9phane --0000000000008ec0ca0637f3f619 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Thu, Jun 19, 2025 at 6:02=E2=80=AFPM Spencer Baugh <<a href=3D"mailto= :sbaugh@HIDDEN">sbaugh@HIDDEN</a>> wrote:</span></div></= div><div class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"g= mail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204= ,204,204);padding-left:1ex">St=C3=A9phane Marks <<a href=3D"mailto:shipm= ints@HIDDEN" target=3D"_blank">shipmints@HIDDEN</a>> writes:<br> > On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports = for GNU Emacs, the Swiss army knife of text editors<br> > <<a href=3D"mailto:bug-gnu-emacs@HIDDEN" target=3D"_blank">bug-gnu= -emacs@HIDDEN</a>> wrote:<br> ><br> >=C2=A0 Stefan Kangas <<a href=3D"mailto:stefankangas@HIDDEN" targ= et=3D"_blank">stefankangas@HIDDEN</a>> writes:<br> ><br> >=C2=A0 > Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" target=3D= "_blank">eliz@HIDDEN</a>> writes:<br> >=C2=A0 ><br> >=C2=A0 >>> Date: Thu, 21 Mar 2024 03:36:02 -0500<br> >=C2=A0 >>> Cc: <a href=3D"mailto:69837 <at> debbugs.gnu.org" target= =3D"_blank">69837 <at> debbugs.gnu.org</a><br> >=C2=A0 >>> From: Adam Porter <<a href=3D"mailto:adam@alphap= apa.net" target=3D"_blank">adam@HIDDEN</a>><br> >=C2=A0 >>><br> >=C2=A0 >>> FWIW, I did some hacking on listen.el attempting to= further understand<br> >=C2=A0 >>> and work around this problem, and I've found wh= at seems to be a usable<br> >=C2=A0 >>> workaround (for my purposes, anyway).<br> >=C2=A0 >>><br> >=C2=A0 >>> The attached code defines a macro within which I ca= ll<br> >=C2=A0 >>> `listen-queue--vtable-update-object' (which mer= ely incorporates the fix<br> >=C2=A0 >>> to `vtable-update-object' from bug#69664).=C2= =A0 As well, I wrap<br> >=C2=A0 >>> `make-vtable' in a function that also sets two = buffer-local variables to<br> >=C2=A0 >>> the values of `frame-terminal' and `window-widt= h' at the time of the<br> >=C2=A0 >>> vtable's creation.=C2=A0 The macro locally over= rides the functions<br> >=C2=A0 >>> `frame-terminal' and `window-width' to retu= rn those saved values.<br> >=C2=A0 >>><br> >=C2=A0 >>> This allows the cache key to match unconditionally,= which allows the<br> >=C2=A0 >>> vtable's objects to be updated even when its bu= ffer is not visible.<br> >=C2=A0 >>><br> >=C2=A0 >>> In my limited testing, it seems to work fine.=C2=A0= In my estimation, the<br> >=C2=A0 >>> consequences of doing this in the worst case would = be that the rows for<br> >=C2=A0 >>> the updated objects might be drawn with some column= s at a slightly<br> >=C2=A0 >>> incorrect width, which is easily rectified by rever= ting the table<br> >=C2=A0 >>> (usually bound to "g").=C2=A0 As well, th= at worst case (e.g. imagining a<br> >=C2=A0 >>> vtable whose buffer might be initially displayed on= one terminal/monitor<br> >=C2=A0 >>> and later on another with different characteristics= ) would seem to be<br> >=C2=A0 >>> relatively rare (so for my project, it seems like a= n obviously good<br> >=C2=A0 >>> thing to do).<br> >=C2=A0 >>><br> >=C2=A0 >>> For Emacs itself, I'm not sure what the best fi= x would be.=C2=A0 I suppose a<br> >=C2=A0 >>> workaround like this could be implemented as a fall= back in case the<br> >=C2=A0 >>> cache key misses; it would seem better to update th= e object potentially<br> >=C2=A0 >>> sub-optimally than to error and not update it at al= l.<br> >=C2=A0 >>><br> >=C2=A0 >>> Another possibility would be to ignore the frame-te= rminal and<br> >=C2=A0 >>> window-width in the cache key altogether (i.e. so t= hey would always be<br> >=C2=A0 >>> assumed to be the same), but I'm sure that Lars= did it this way for a<br> >=C2=A0 >>> reason, so that would seem unwise.<br> >=C2=A0 >>><br> >=C2=A0 >>> Let me know how you'd like me to proceed.<br> >=C2=A0 >><br> >=C2=A0 >> I think you should install your workaround.=C2=A0 I don= 't see how it could<br> >=C2=A0 >> be worse than what we have now.<br> >=C2=A0 >><br> >=C2=A0 >> P.S. And sorry for a long silence.<br> >=C2=A0 ><br> >=C2=A0 > Adam, could you please install the workaround?=C2=A0 Or may= be you did<br> >=C2=A0 > already?<br> ><br> >=C2=A0 I ran into this same problem.=C2=A0 I think Adam's workaroun= d is on the right<br> >=C2=A0 track, but the issue is present in a number of other functions i= n<br> >=C2=A0 vtable.el, not just vtable-update-object.<br> ><br> >=C2=A0 The root of the issue is that when we're interacting with th= e text of an<br> >=C2=A0 inserted vtable, we should use the "cache" object that= was last used to<br> >=C2=A0 insert that vtable, rather than one based on the current selecte= d window<br> >=C2=A0 and terminal.=C2=A0 Otherwise we will experience various inconsi= stencies,<br> >=C2=A0 e.g. inserting a new line that has different column widths from = the rest<br> >=C2=A0 of the vtable text.<br> ><br> >=C2=A0 My attached patch solves this by saving the "cache" ob= ject in a text<br> >=C2=A0 property on the vtable text, and updating all the relevant vtabl= e<br> >=C2=A0 functions to access the cache via that text property rather than= by<br> >=C2=A0 computing a cache key from the current selected window/terminal.= <br> ><br> >=C2=A0 Adam, could you check that this solves the problem for your use = case?<br> ><br> > I have a very big patch coming for vtable under <a href=3D"https://deb= bugs.gnu.org/cgi/bugreport.cgi?bug=3D78843" rel=3D"noreferrer" target=3D"_b= lank">https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843</a> which addre= sses this issue,<br> > and a ton of other bugs (and features).=C2=A0 That's coming in the= next day or so, if you can wait?<br> <br> Certainly I can wait.=C2=A0 Cc me when you send the patch.<br> <br> Though if your patch is very large, maybe this relatively small patch<br> should land first.<br> <br> (Also, I hope that you're adding tests in your very large patch?)<br> <br> BTW, an updated version of my patch is attached, just fixing a silly bug<br= > that was in the first version.<br></blockquote><div><br></div><div class=3D= "gmail_default" style=3D"font-family:monospace">Your patch doesn't addr= ess several other intertwined issues that my bigger patch addresses.=C2=A0 = I've been testing it for ages now and with other vtable users.=C2=A0 I = can send a new vtable.el and vtable.texi=C2=A0to you off line=C2=A0if you&#= 39;d like a look before I finish writing the long changelog.</div><div clas= s=3D"gmail_default" style=3D"font-family:monospace"><br></div><div class=3D= "gmail_default" style=3D"font-family:monospace">-St=C3=A9phane=C2=A0</div><= /div></div> --0000000000008ec0ca0637f3f619--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.
Received: (at 69837) by debbugs.gnu.org; 19 Jun 2025 22:03:22 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 19 18:03:21 2025
Received: from localhost ([127.0.0.1]:38763 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uSNLm-0004JB-Hf
for submit <at> debbugs.gnu.org; Thu, 19 Jun 2025 18:03:21 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:51617)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1uSNLd-0004Gm-Jw
for 69837 <at> debbugs.gnu.org; Thu, 19 Jun 2025 18:03:12 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
To: =?utf-8?Q?St=C3=A9phane?= Marks <shipmints@HIDDEN>
Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible
windows
In-Reply-To: <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN>
(=?utf-8?Q?=22St=C3=A9phane?= Marks"'s message of "Thu, 19 Jun 2025
17:41:03 -0400")
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>
<86frvy3fci.fsf@HIDDEN>
<CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN>
<ierwm97jtwb.fsf@HIDDEN>
<CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN>
Date: Thu, 19 Jun 2025 18:02:59 -0400
Message-ID: <iertt4bjsoc.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1750370579;
bh=V8KvnaxSo/2ckL6GeVtEhfaxtuj0cuswy7i652wTvpE=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=IQ6y1mEDbtlpVT8BAT4aWc59ANsg5cwEZi8WJduX0mu/FoXnasZek+JzYIvexcYl5
UcJeVuOm6Gd3FhO4+9X3UIsy3LXK1EJky9QxVnZ9Hm1BL53u+Bhd2FStjK1vy8pNm5
4OFZx967HW6EquL03XFPeDTaRahTFMpCT4CmC7seIRva6ZsQx8zvx4YLpdKTIccM9k
6D/K2cpzVRWMMlfcEemmyGRUWD4MkoM5/Y80/5BFb/4V2slotppJXcI65CrzXjEAcw
15HaAzSp2SZCIGXQ/wj2GSKoVwhTmclK+ik8f9gTb69LPL+06Rs+cItJg3m3z+qhUc
X+U7oYyIOPm5A==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 69837
Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org,
Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN>
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 (---)
--=-=-=
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
St=C3=A9phane Marks <shipmints@HIDDEN> writes:
> On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports for=
GNU Emacs, the Swiss army knife of text editors
> <bug-gnu-emacs@HIDDEN> wrote:
>
> Stefan Kangas <stefankangas@HIDDEN> writes:
>
> > Eli Zaretskii <eliz@HIDDEN> writes:
> >
> >>> 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 understa=
nd
> >>> and work around this problem, and I've found what seems to be a usab=
le
> >>> 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 variable=
s 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/mon=
itor
> >>> 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 suppos=
e a
> >>> workaround like this could be implemented as a fallback in case the
> >>> cache key misses; it would seem better to update the object potentia=
lly
> >>> 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.
> >
> > Adam, could you please install the workaround? Or maybe you did
> > already?
>
> I ran into this same problem. I think Adam's workaround is on the right
> track, but the issue is present in a number of other functions in
> vtable.el, not just vtable-update-object.
>
> The root of the issue is that when we're interacting with the text of an
> inserted vtable, we should use the "cache" object that was last used to
> insert that vtable, rather than one based on the current selected window
> and terminal. Otherwise we will experience various inconsistencies,
> e.g. inserting a new line that has different column widths from the rest
> of the vtable text.
>
> My attached patch solves this by saving the "cache" object in a text
> property on the vtable text, and updating all the relevant vtable
> functions to access the cache via that text property rather than by
> computing a cache key from the current selected window/terminal.
>
> Adam, could you check that this solves the problem for your use case?
>
> I have a very big patch coming for vtable under https://debbugs.gnu.org/c=
gi/bugreport.cgi?bug=3D78843 which addresses this issue,
> and a ton of other bugs (and features). That's coming in the next day or=
so, if you can wait?
Certainly I can wait. Cc me when you send the patch.
Though if your patch is very large, maybe this relatively small patch
should land first.
(Also, I hope that you're adding tests in your very large patch?)
BTW, an updated version of my patch is attached, just fixing a silly bug
that was in the first version.
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch
From 5607bb42202e050edc5e33b8fa9c1c96d65d8746 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Thu, 19 Jun 2025 17:20:12 -0400
Subject: [PATCH] Fix implicit usage of the current window-width in vtable.el
Previously, many functions in vtable.el called vtable--cache,
which computed vtable--cache-key based on the current selected
window and frame; this could cause vtable functions to fail or
misbehave if they were not called from the selected window and
frame that vtable-insert was last called in.
Now, the vtable cache is stored with the text of the vtable, so
that functions which need to interact with some vtable text can
do so reliably without having to use the same selected window
and frame.
Also, vtable-update-object has always required TABLE to be
present at point in the current buffer; now its docstring states
this.
* lisp/emacs-lisp/vtable.el (vtable--current-cache)
(vtable--cache-widths, vtable--cache-lines): Add.
(vtable-insert): Save cache in 'vtable-cache.
(vtable--ensure-cache, vtable--recompute-cache): Inline into
vtable-insert.
(vtable--widths, vtable--cache): Delete.
(vtable-update-object): Use vtable--current-cache and update
docstring. (bug#69837)
(vtable-remove-object, vtable-insert-object): Use
vtable--current-cache and save cache in 'vtable-cache.
(vtable--sort, vtable--alter-column-width)
(vtable-previous-column, vtable-next-column): Use
vtable--current-cache.
---
lisp/emacs-lisp/vtable.el | 111 ++++++++++++++++++++------------------
1 file changed, 59 insertions(+), 52 deletions(-)
diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index 00785113edb..d6be6d361f7 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -282,10 +282,9 @@ vtable-update-object
"Update OBJECT's representation in TABLE.
If OLD-OBJECT is non-nil, replace OLD-OBJECT with OBJECT and display it.
In either case, if the existing object is not found in the table (being
-compared with `equal'), signal an error. Note a limitation: if TABLE's
-buffer is not in a visible window, or if its window has changed width
-since it was updated, updating the TABLE is not possible, and an error
-is signaled."
+compared with `equal'), signal an error.
+
+TABLE must be at point in the current buffer."
(unless old-object
(setq old-object object))
(let* ((objects (vtable-objects table))
@@ -302,14 +301,13 @@ vtable-update-object
(unless objects
(error "Can't find the old object"))
(setcar (cdr objects) object))
- ;; Then update the cache...
- ;; FIXME: If the table's buffer has no visible window, or if its
- ;; width has changed since the table was updated, the cache key will
- ;; not match and the object can't be updated. (Bug #69837).
- (if-let* ((line-number (seq-position (car (vtable--cache table)) old-object
- (lambda (a b)
- (equal (car a) b))))
- (line (elt (car (vtable--cache table)) line-number)))
+ ;; Then update the rendered vtable in the current buffer.
+ (if-let* ((cache (vtable--current-cache))
+ (line-number (seq-position (vtable--cache-lines cache)
+ old-object
+ (lambda (a b)
+ (equal (car a) b))))
+ (line (elt (vtable--cache-lines cache) line-number)))
(progn
(setcar line object)
(setcdr line (vtable--compute-cached-line table object))
@@ -320,10 +318,11 @@ vtable-update-object
(start (point)))
(delete-line)
(vtable--insert-line table line line-number
- (nth 1 (vtable--cache table))
+ (vtable--cache-widths cache)
(vtable--spacer table))
(add-text-properties start (point) (list 'keymap keymap
- 'vtable table))))
+ 'vtable table
+ 'vtable-cache cache))))
;; We may have inserted a non-numerical value into a previously
;; all-numerical table, so recompute.
(vtable--recompute-numerical table (cdr line)))
@@ -335,11 +334,12 @@ vtable-remove-object
;; First remove from the objects.
(setf (vtable-objects table) (delq object (vtable-objects table)))
;; Then adjust the cache and display.
- (let ((cache (vtable--cache table))
- (inhibit-read-only t))
- (setcar cache (delq (assq object (car cache)) (car cache)))
- (save-excursion
- (vtable-goto-table table)
+ (save-excursion
+ (vtable-goto-table table)
+ (let ((cache (vtable--current-cache))
+ (inhibit-read-only t))
+ (setcar cache (delq (assq object (vtable--cache-lines cache))
+ (vtable--cache-lines cache)))
(when (vtable-goto-object object)
(delete-line)))))
@@ -400,7 +400,7 @@ vtable-insert-object
;; Then adjust the cache and display.
(save-excursion
(vtable-goto-table table)
- (let* ((cache (vtable--cache table))
+ (let* ((cache (vtable--current-cache))
(inhibit-read-only t)
(keymap (get-text-property (point) 'keymap))
(ellipsis (if (vtable-ellipsis table)
@@ -408,13 +408,14 @@ vtable-insert-object
'face (vtable-face table))
""))
(ellipsis-width (string-pixel-width ellipsis))
- (elem (if location ; This binding mirrors the binding of `pos' above.
+ (lines (vtable--cache-lines cache))
+ (elem (if location ; This binding mirrors the binding of `pos' above.
(if (integerp location)
- (nth location (car cache))
- (or (assq location (car cache))
- (and before (caar cache))))
- (if before (caar cache))))
- (pos (memq elem (car cache)))
+ (nth location lines)
+ (or (assq location lines)
+ (and before (car lines))))
+ (if before (car lines))))
+ (pos (memq elem lines))
(line (cons object (vtable--compute-cached-line table object))))
(if (or before
(and pos (integerp location)))
@@ -433,13 +434,13 @@ vtable-insert-object
(forward-line 1) ; Insert *after*.
(vtable-end-of-table)))
;; Otherwise, append the object.
- (setcar cache (nconc (car cache) (list line)))
+ (setcar cache (nconc (vtable--cache-lines cache) (list line)))
(vtable-end-of-table)))
(let ((start (point)))
;; FIXME: We have to adjust colors in lines below this if we
;; have :row-colors.
(vtable--insert-line table line 0
- (nth 1 cache) (vtable--spacer table)
+ (vtable--cache-widths cache) (vtable--spacer table)
ellipsis ellipsis-width)
(add-text-properties start (point) (list 'keymap keymap
'vtable table)))
@@ -512,15 +513,11 @@ vtable--compute-columns
(defun vtable--spacer (table)
(vtable--compute-width table (vtable-separator-width table)))
-(defun vtable--recompute-cache (table)
- (let* ((data (vtable--compute-cache table))
- (widths (vtable--compute-widths table data)))
- (setf (gethash (vtable--cache-key) (slot-value table '-cache))
- (list data widths))))
+(defun vtable--cache-widths (cache)
+ (nth 1 cache))
-(defun vtable--ensure-cache (table)
- (or (vtable--cache table)
- (vtable--recompute-cache table)))
+(defun vtable--cache-lines (cache)
+ (car cache))
(defun vtable-insert (table)
(let* ((spacer (vtable--spacer table))
@@ -533,7 +530,12 @@ vtable-insert
;; 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).
- (widths (nth 1 (vtable--ensure-cache table))))
+ (cache (or (gethash (vtable--cache-key) (slot-value table '-cache))
+ (let* ((data (vtable--compute-cache table))
+ (widths (vtable--compute-widths table data)))
+ (setf (gethash (vtable--cache-key) (slot-value table '-cache))
+ (list data widths)))))
+ (widths (vtable--cache-widths cache)))
;; Don't insert any header or header line if the user hasn't
;; specified the columns.
(when (slot-value table '-has-column-spec)
@@ -546,18 +548,20 @@ vtable-insert
(add-text-properties start (point)
(list 'keymap vtable-header-line-map
'rear-nonsticky t
- 'vtable table))
+ 'vtable table
+ 'vtable-cache cache))
(setq start (point))))
- (vtable--sort table)
+ (vtable--sort table cache)
;; Insert the data.
(let ((line-number 0))
- (dolist (line (car (vtable--cache table)))
+ (dolist (line (vtable--cache-lines cache))
(vtable--insert-line table line line-number widths spacer
ellipsis ellipsis-width)
(setq line-number (1+ line-number))))
(add-text-properties start (point)
(list 'rear-nonsticky t
- 'vtable table))
+ 'vtable table
+ 'vtable-cache cache))
(goto-char start)))
(defun vtable--insert-line (table line line-number widths spacer
@@ -659,16 +663,22 @@ vtable--insert-line
(defun vtable--cache-key ()
(cons (frame-terminal) (window-width)))
-(defun vtable--cache (table)
- (gethash (vtable--cache-key) (slot-value table '-cache)))
+(defun vtable--current-cache ()
+ "Return the current cache for the table at point.
+
+In `vtable-insert', the lines and widths of the vtable text are computed
+based on the current selected frame and window and stored in a cache.
+Subsequent interaction with the text of the vtable should use that cache
+via this function rather than by calling `vtable--cache-key' to look up
+the cache."
+ (get-text-property (point) 'vtable-cache))
(defun vtable--clear-cache (table)
(setf (gethash (vtable--cache-key) (slot-value table '-cache)) nil))
-(defun vtable--sort (table)
+(defun vtable--sort (table cache)
(pcase-dolist (`(,index . ,direction) (vtable-sort-by table))
- (let ((cache (vtable--cache table))
- (numerical (vtable-column--numerical
+ (let ((numerical (vtable-column--numerical
(elt (vtable-columns table) index)))
(numcomp (if (eq direction 'descend)
#'> #'<))
@@ -971,9 +981,6 @@ vtable-revert
(when column
(vtable-goto-column column))))
-(defun vtable--widths (table)
- (nth 1 (vtable--ensure-cache table)))
-
;;; Commands.
(defvar-keymap vtable-header-mode-map
@@ -998,7 +1005,7 @@ vtable-narrow-current-column
(- (* (vtable--char-width table) (or n 1))))))
(defun vtable--alter-column-width (table column delta)
- (let ((widths (vtable--widths table)))
+ (let ((widths (vtable--cache-widths (vtable--current-cache))))
(setf (aref widths column)
(max (* (vtable--char-width table) 2)
(+ (aref widths column) delta)))
@@ -1020,14 +1027,14 @@ vtable-previous-column
(interactive)
(vtable-goto-column
(max 0 (1- (or (vtable-current-column)
- (length (vtable--widths (vtable-current-table))))))))
+ (length (vtable--cache-widths (vtable--current-cache))))))))
(defun vtable-next-column ()
"Go to the next column."
(interactive)
(when (vtable-current-column)
(vtable-goto-column
- (min (1- (length (vtable--widths (vtable-current-table))))
+ (min (1- (length (vtable--cache-widths (vtable--current-cache))))
(1+ (vtable-current-column))))))
(defun vtable-revert-command ()
--
2.39.3
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Received: (at 69837) by debbugs.gnu.org; 19 Jun 2025 21:41:29 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 19 17:41:29 2025 Received: from localhost ([127.0.0.1]:38707 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1uSN0f-0000ve-C1 for submit <at> debbugs.gnu.org; Thu, 19 Jun 2025 17:41:29 -0400 Received: from mail-vk1-xa2f.google.com ([2607:f8b0:4864:20::a2f]:59620) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <shipmints@HIDDEN>) id 1uSN0a-0000u5-U8 for 69837 <at> debbugs.gnu.org; Thu, 19 Jun 2025 17:41:23 -0400 Received: by mail-vk1-xa2f.google.com with SMTP id 71dfb90a1353d-531426c7139so350781e0c.2 for <69837 <at> debbugs.gnu.org>; Thu, 19 Jun 2025 14:41:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1750369275; x=1750974075; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=dHgUoTXn4istz1pv7QSkaBGfmnNvtqEwxv3FtpgK0zg=; b=juEP7csyo5FX7Lv8cu69pyI4RN1CbRcpyY0CGS6wVwH2D0CIV38lIVsVwPHdQjxqRe 55VAC4PUxOTi+mLfyBPJodZJatn3BOAubMZXGIlZprwb2+ts6fO0N0BYD2U/ENxTdx3I rTBGmg7ygNbbjP+J/J0f2PpRrZC3P6k7eTzf/Ot/m4/JvscA55nU4dmq+bEOzH2GwEoe muFF793TgRaLv677YV4yHxshN2fX2vb6Ia/dYKrMctBfFWkk23VaRXTDnN6bLfPmD+Db jAK/infOflkrAd7Ja+VMH/9jp7LgMH9bBLRnbjZoNrFi2cilV0/meiUbVL8E+jg9cKJB MeDQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750369275; x=1750974075; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=dHgUoTXn4istz1pv7QSkaBGfmnNvtqEwxv3FtpgK0zg=; b=LOOAIqwwVFa1LHA/0L4HXaRXTcWyXLcdDOeU55qhGdZgOLUgb6UMATaKofEbasDcTw +puDnEbPlU0AHq9C8mAXxI3lJey8Q5vcSaqQEkwwh3dtLZ0Feu6fde/LpaTG3mXTfBQq ucDKpHupHrzUBtw6DIFDRPjbl/pAGg7Wo5x5W9mZloIHvFUe26Jr0vA+4M3m4f3vaUVf vex+tzotBl1dfxehjd5ngdIt5LH8ahoi7LnzTJ62faRdZ/UPb31qlphQaN3GaJWjRvQP a8G7/j8qTnxH0jim/O4++93tNiR9dSkeg7XaK/WXnK6wJ3iCKAymauDqmp6PiwicaGeY mfUw== X-Forwarded-Encrypted: i=1; AJvYcCX9iteX5XU4+acffgdIXegCpIV9tUOTrbCG7noxkk0GtNSh4ERxD9c/z6oSrC45Mda7ZTsfRQ==@debbugs.gnu.org X-Gm-Message-State: AOJu0Ywpj7P3hPnHKMRBr1QPxeFNj2ovYiBLYPh6LwJ2begbxb1TzyRG Xm3jZxcyxclixMYmdzIrLrVfHngZoMBWnIllKEwTgag8DG0bDV6zYm35nDEKl4iXkNj0BeHJRTj CfpTxQ/InXrAcmyRRTE3WqabqgS73i2g= X-Gm-Gg: ASbGncsftqjbGmFnjrYac8WzsR8GDaRhMx7gq+M8XDQUtID2HcNVqzsST0kEbYhZBJt YdrnQz3+nfO69Y2DLzph1y8nUNBhGA9LQfmR1GitWxNj/OC2H7fu8UpEplrsdmzunl4W5cpOOBQ iOeLRbEa1aGOC79Pa1Pbp79yRIlwZ6VE0VueycaLKLV8qKCZJD030O6XsA X-Google-Smtp-Source: AGHT+IH5iyPbF3zyrFCqAqwU0MRMypbQRLuiBmExJ5Mu9Mcb476bYJKz8lFGh28GxJGxSni2tRtDKu0iBHC9hP/SxJw= X-Received: by 2002:a05:6122:1da4:b0:518:6286:87a4 with SMTP id 71dfb90a1353d-531ad6c3d5emr265949e0c.4.1750369275064; Thu, 19 Jun 2025 14:41:15 -0700 (PDT) MIME-Version: 1.0 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> <86frvy3fci.fsf@HIDDEN> <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> <ierwm97jtwb.fsf@HIDDEN> In-Reply-To: <ierwm97jtwb.fsf@HIDDEN> From: =?UTF-8?Q?St=C3=A9phane_Marks?= <shipmints@HIDDEN> Date: Thu, 19 Jun 2025 17:41:03 -0400 X-Gm-Features: Ac12FXzaI9tfxs9z-SiJFdYW7HKz95Q-MvZjLO8p0cAYMKM-RYfC_Ql6-h4JdT0 Message-ID: <CAN+1HbpBGQMN850raG7bxyAje2hwWXqnWphc2Ekfmx27eE-ztA@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows To: Spencer Baugh <sbaugh@HIDDEN> Content-Type: multipart/alternative; boundary="000000000000ddb79e0637f39a07" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org, Eli Zaretskii <eliz@HIDDEN>, Stefan Kangas <stefankangas@HIDDEN> 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: -1.0 (-) --000000000000ddb79e0637f39a07 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports for G= NU Emacs, the Swiss army knife of text editors <bug-gnu-emacs@HIDDEN> wrote: > Stefan Kangas <stefankangas@HIDDEN> writes: > > > Eli Zaretskii <eliz@HIDDEN> writes: > > > >>> 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 understan= d > >>> and work around this problem, and I've found what seems to be a usabl= e > >>> workaround (for my purposes, anyway). > >>> > >>> The attached code defines a macro within which I call > >>> `listen-queue--vtable-update-object' (which merely incorporates the f= ix > >>> 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 f= or > >>> 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 potential= ly > >>> 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 b= e > >>> 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. > > > > Adam, could you please install the workaround? Or maybe you did > > already? > > I ran into this same problem. I think Adam's workaround is on the right > track, but the issue is present in a number of other functions in > vtable.el, not just vtable-update-object. > > The root of the issue is that when we're interacting with the text of an > inserted vtable, we should use the "cache" object that was last used to > insert that vtable, rather than one based on the current selected window > and terminal. Otherwise we will experience various inconsistencies, > e.g. inserting a new line that has different column widths from the rest > of the vtable text. > > My attached patch solves this by saving the "cache" object in a text > property on the vtable text, and updating all the relevant vtable > functions to access the cache via that text property rather than by > computing a cache key from the current selected window/terminal. > > Adam, could you check that this solves the problem for your use case? > I have a very big patch coming for vtable under https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843 which addresses this issue, and a ton of other bugs (and features). That's coming in the next day or so, if you can wait? -St=C3=A9phane --000000000000ddb79e0637f39a07 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon= t-family:monospace"><span style=3D"font-family:Arial,Helvetica,sans-serif">= On Thu, Jun 19, 2025 at 5:37=E2=80=AFPM Spencer Baugh via Bug reports for G= NU Emacs, the Swiss army knife of text editors <<a href=3D"mailto:bug-gn= u-emacs@HIDDEN">bug-gnu-emacs@HIDDEN</a>> wrote:</span></div></div><di= v class=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_qu= ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20= 4);padding-left:1ex">Stefan Kangas <<a href=3D"mailto:stefankangas@gmail= .com" target=3D"_blank">stefankangas@HIDDEN</a>> writes:<br> <br> > Eli Zaretskii <<a href=3D"mailto:eliz@HIDDEN" target=3D"_blank">el= iz@HIDDEN</a>> writes:<br> ><br> >>> Date: Thu, 21 Mar 2024 03:36:02 -0500<br> >>> Cc: <a href=3D"mailto:69837 <at> debbugs.gnu.org" target=3D"_blank"= >69837 <at> debbugs.gnu.org</a><br> >>> From: Adam Porter <<a href=3D"mailto:adam@HIDDEN" ta= rget=3D"_blank">adam@HIDDEN</a>><br> >>><br> >>> FWIW, I did some hacking on listen.el attempting to further un= derstand<br> >>> and work around this problem, and I've found what seems to= be a usable<br> >>> workaround (for my purposes, anyway).<br> >>><br> >>> The attached code defines a macro within which I call<br> >>> `listen-queue--vtable-update-object' (which merely incorpo= rates the fix<br> >>> to `vtable-update-object' from bug#69664).=C2=A0 As well, = I wrap<br> >>> `make-vtable' in a function that also sets two buffer-loca= l variables to<br> >>> the values of `frame-terminal' and `window-width' at t= he time of the<br> >>> vtable's creation.=C2=A0 The macro locally overrides the f= unctions<br> >>> `frame-terminal' and `window-width' to return those sa= ved values.<br> >>><br> >>> This allows the cache key to match unconditionally, which allo= ws the<br> >>> vtable's objects to be updated even when its buffer is not= visible.<br> >>><br> >>> In my limited testing, it seems to work fine.=C2=A0 In my esti= mation, the<br> >>> consequences of doing this in the worst case would be that the= rows for<br> >>> the updated objects might be drawn with some columns at a slig= htly<br> >>> incorrect width, which is easily rectified by reverting the ta= ble<br> >>> (usually bound to "g").=C2=A0 As well, that worst ca= se (e.g. imagining a<br> >>> vtable whose buffer might be initially displayed on one termin= al/monitor<br> >>> and later on another with different characteristics) would see= m to be<br> >>> relatively rare (so for my project, it seems like an obviously= good<br> >>> thing to do).<br> >>><br> >>> For Emacs itself, I'm not sure what the best fix would be.= =C2=A0 I suppose a<br> >>> workaround like this could be implemented as a fallback in cas= e the<br> >>> cache key misses; it would seem better to update the object po= tentially<br> >>> sub-optimally than to error and not update it at all.<br> >>><br> >>> Another possibility would be to ignore the frame-terminal and<= br> >>> window-width in the cache key altogether (i.e. so they would a= lways be<br> >>> assumed to be the same), but I'm sure that Lars did it thi= s way for a<br> >>> reason, so that would seem unwise.<br> >>><br> >>> Let me know how you'd like me to proceed.<br> >><br> >> I think you should install your workaround.=C2=A0 I don't see = how it could<br> >> be worse than what we have now.<br> >><br> >> P.S. And sorry for a long silence.<br> ><br> > Adam, could you please install the workaround?=C2=A0 Or maybe you did<= br> > already?<br> <br> I ran into this same problem.=C2=A0 I think Adam's workaround is on the= right<br> track, but the issue is present in a number of other functions in<br> vtable.el, not just vtable-update-object.<br> <br> The root of the issue is that when we're interacting with the text of a= n<br> inserted vtable, we should use the "cache" object that was last u= sed to<br> insert that vtable, rather than one based on the current selected window<br= > and terminal.=C2=A0 Otherwise we will experience various inconsistencies,<b= r> e.g. inserting a new line that has different column widths from the rest<br= > of the vtable text.<br> <br> My attached patch solves this by saving the "cache" object in a t= ext<br> property on the vtable text, and updating all the relevant vtable<br> functions to access the cache via that text property rather than by<br> computing a cache key from the current selected window/terminal.<br> <br> Adam, could you check that this solves the problem for your use case?<br></= blockquote><div><br></div><div class=3D"gmail_default" style=3D"font-family= :monospace">I have a very big patch coming for vtable under=C2=A0<a href=3D= "https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D78843">https://debbugs.gnu= .org/cgi/bugreport.cgi?bug=3D78843</a> which addresses this issue, and a to= n of other bugs (and features).=C2=A0 That's coming in the next day or = so, if you can wait?</div><div class=3D"gmail_default" style=3D"font-family= :monospace"><br></div><div class=3D"gmail_default" style=3D"font-family:mon= ospace">-St=C3=A9phane</div></div></div> --000000000000ddb79e0637f39a07--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.
Received: (at 69837) by debbugs.gnu.org; 19 Jun 2025 21:36:58 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Thu Jun 19 17:36:57 2025
Received: from localhost ([127.0.0.1]:38700 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1uSMwF-0000Ap-4H
for submit <at> debbugs.gnu.org; Thu, 19 Jun 2025 17:36:57 -0400
Received: from mxout5.mail.janestreet.com ([64.215.233.18]:36759)
by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) (envelope-from <sbaugh@HIDDEN>)
id 1uSMw6-00008m-3p
for 69837 <at> debbugs.gnu.org; Thu, 19 Jun 2025 17:36:48 -0400
From: Spencer Baugh <sbaugh@HIDDEN>
To: Stefan Kangas <stefankangas@HIDDEN>
Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible
windows
In-Reply-To: <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN>
(Stefan Kangas's message of "Fri, 28 Feb 2025 19:09:29 -0800")
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>
<86frvy3fci.fsf@HIDDEN>
<CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN>
Date: Thu, 19 Jun 2025 17:36:36 -0400
Message-ID: <ierwm97jtwb.fsf@HIDDEN>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com;
s=waixah; t=1750368996;
bh=BFH8C1fuMoycno48yRlq9aNSDRdzmhPS9XTA32SyMhs=;
h=From:To:Cc:Subject:In-Reply-To:References:Date;
b=QjKYwnFDqIPXcPBP+V/LF+Z+lmohYuSOCspQ8Ar5Aop0HExGtZokofJ7vbzA6p0Dl
J9W4i3eCQtxK5pW0BL6UX3abbQvSC2lsZ1VLoIIStj7dShajEPHGxg4dCGAJSizyJU
A2+uypMqX+Luspub8dslS4mD+tHSyKSJApzu/bSgbfEY1zQxZtgrAe7O37kRR1QkVO
r59QePwI0HWF7+IENRsLoRLb4t1N1kYljoTeiMrMZ3qCVqaC+q6BdPCJWIxPHv9rHE
1/n/10YhNmg8781unNL34VoCCnahAmmj4+dQ1B/Ya41GggdAQCtP2gwCd8Cou/hEfW
Iex7XgKSNd16Q==
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 69837
Cc: Adam Porter <adam@HIDDEN>, 69837 <at> debbugs.gnu.org,
Eli Zaretskii <eliz@HIDDEN>
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 (---)
--=-=-=
Content-Type: text/plain
Stefan Kangas <stefankangas@HIDDEN> writes:
> Eli Zaretskii <eliz@HIDDEN> writes:
>
>>> 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.
>
> Adam, could you please install the workaround? Or maybe you did
> already?
I ran into this same problem. I think Adam's workaround is on the right
track, but the issue is present in a number of other functions in
vtable.el, not just vtable-update-object.
The root of the issue is that when we're interacting with the text of an
inserted vtable, we should use the "cache" object that was last used to
insert that vtable, rather than one based on the current selected window
and terminal. Otherwise we will experience various inconsistencies,
e.g. inserting a new line that has different column widths from the rest
of the vtable text.
My attached patch solves this by saving the "cache" object in a text
property on the vtable text, and updating all the relevant vtable
functions to access the cache via that text property rather than by
computing a cache key from the current selected window/terminal.
Adam, could you check that this solves the problem for your use case?
--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline;
filename=0001-Fix-implicit-usage-of-the-current-window-width-in-vt.patch
From cdde849bf78c20dbc3f5c3abba0e86171c8de188 Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@HIDDEN>
Date: Thu, 19 Jun 2025 17:20:12 -0400
Subject: [PATCH] Fix implicit usage of the current window-width in vtable.el
Previously, many functions in vtable.el called vtable--cache,
which computed vtable--cache-key based on the current selected
window and frame; this could cause vtable functions to fail or
misbehave if they were not called from the selected window and
frame that vtable-insert was last called in.
Now, the vtable cache is stored with the text of the vtable, so
that functions which need to interact with some vtable text can
do so reliably without having to use the same selected window
and frame.
Also, vtable-update-object has always required TABLE to be
present at point in the current buffer; now its docstring states
this.
* lisp/emacs-lisp/vtable.el (vtable--current-cache)
(vtable--cache-widths, vtable--cache-lines): Add.
(vtable-insert): Save cache in 'vtable-cache.
(vtable--ensure-cache, vtable--recompute-cache): Inline into
vtable-insert.
(vtable--widths, vtable--cache): Delete.
(vtable-update-object): Use vtable--current-cache and update
docstring. (bug#69837)
(vtable-remove-object, vtable-insert-object): Use
vtable--current-cache and save cache in 'vtable-cache.
(vtable--sort, vtable--alter-column-width)
(vtable-previous-column, vtable-next-column): Use
vtable--current-cache.
---
lisp/emacs-lisp/vtable.el | 111 ++++++++++++++++++++------------------
1 file changed, 59 insertions(+), 52 deletions(-)
diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index 00785113edb..991570b9799 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -282,10 +282,9 @@ vtable-update-object
"Update OBJECT's representation in TABLE.
If OLD-OBJECT is non-nil, replace OLD-OBJECT with OBJECT and display it.
In either case, if the existing object is not found in the table (being
-compared with `equal'), signal an error. Note a limitation: if TABLE's
-buffer is not in a visible window, or if its window has changed width
-since it was updated, updating the TABLE is not possible, and an error
-is signaled."
+compared with `equal'), signal an error.
+
+TABLE must be at point in the current buffer."
(unless old-object
(setq old-object object))
(let* ((objects (vtable-objects table))
@@ -302,14 +301,13 @@ vtable-update-object
(unless objects
(error "Can't find the old object"))
(setcar (cdr objects) object))
- ;; Then update the cache...
- ;; FIXME: If the table's buffer has no visible window, or if its
- ;; width has changed since the table was updated, the cache key will
- ;; not match and the object can't be updated. (Bug #69837).
- (if-let* ((line-number (seq-position (car (vtable--cache table)) old-object
- (lambda (a b)
- (equal (car a) b))))
- (line (elt (car (vtable--cache table)) line-number)))
+ ;; Then update the rendered vtable in the current buffer.
+ (if-let* ((cache (vtable--current-cache))
+ (line-number (seq-position (vtable--cache-lines cache)
+ old-object
+ (lambda (a b)
+ (equal (car a) b))))
+ (line (elt (vtable--cache-widths cache) line-number)))
(progn
(setcar line object)
(setcdr line (vtable--compute-cached-line table object))
@@ -320,10 +318,11 @@ vtable-update-object
(start (point)))
(delete-line)
(vtable--insert-line table line line-number
- (nth 1 (vtable--cache table))
+ (vtable--cache-lines cache)
(vtable--spacer table))
(add-text-properties start (point) (list 'keymap keymap
- 'vtable table))))
+ 'vtable table
+ 'vtable-cache cache))))
;; We may have inserted a non-numerical value into a previously
;; all-numerical table, so recompute.
(vtable--recompute-numerical table (cdr line)))
@@ -335,11 +334,12 @@ vtable-remove-object
;; First remove from the objects.
(setf (vtable-objects table) (delq object (vtable-objects table)))
;; Then adjust the cache and display.
- (let ((cache (vtable--cache table))
- (inhibit-read-only t))
- (setcar cache (delq (assq object (car cache)) (car cache)))
- (save-excursion
- (vtable-goto-table table)
+ (save-excursion
+ (vtable-goto-table table)
+ (let ((cache (vtable--current-cache))
+ (inhibit-read-only t))
+ (setcar cache (delq (assq object (vtable--cache-lines cache))
+ (vtable--cache-lines cache)))
(when (vtable-goto-object object)
(delete-line)))))
@@ -400,7 +400,7 @@ vtable-insert-object
;; Then adjust the cache and display.
(save-excursion
(vtable-goto-table table)
- (let* ((cache (vtable--cache table))
+ (let* ((cache (vtable--current-cache))
(inhibit-read-only t)
(keymap (get-text-property (point) 'keymap))
(ellipsis (if (vtable-ellipsis table)
@@ -408,13 +408,14 @@ vtable-insert-object
'face (vtable-face table))
""))
(ellipsis-width (string-pixel-width ellipsis))
- (elem (if location ; This binding mirrors the binding of `pos' above.
+ (lines (vtable--cache-lines cache))
+ (elem (if location ; This binding mirrors the binding of `pos' above.
(if (integerp location)
- (nth location (car cache))
- (or (assq location (car cache))
- (and before (caar cache))))
- (if before (caar cache))))
- (pos (memq elem (car cache)))
+ (nth location lines)
+ (or (assq location lines)
+ (and before (car lines))))
+ (if before (car lines))))
+ (pos (memq elem lines))
(line (cons object (vtable--compute-cached-line table object))))
(if (or before
(and pos (integerp location)))
@@ -433,13 +434,13 @@ vtable-insert-object
(forward-line 1) ; Insert *after*.
(vtable-end-of-table)))
;; Otherwise, append the object.
- (setcar cache (nconc (car cache) (list line)))
+ (setcar cache (nconc (vtable--cache-lines cache) (list line)))
(vtable-end-of-table)))
(let ((start (point)))
;; FIXME: We have to adjust colors in lines below this if we
;; have :row-colors.
(vtable--insert-line table line 0
- (nth 1 cache) (vtable--spacer table)
+ (vtable--cache-widths cache) (vtable--spacer table)
ellipsis ellipsis-width)
(add-text-properties start (point) (list 'keymap keymap
'vtable table)))
@@ -512,15 +513,11 @@ vtable--compute-columns
(defun vtable--spacer (table)
(vtable--compute-width table (vtable-separator-width table)))
-(defun vtable--recompute-cache (table)
- (let* ((data (vtable--compute-cache table))
- (widths (vtable--compute-widths table data)))
- (setf (gethash (vtable--cache-key) (slot-value table '-cache))
- (list data widths))))
+(defun vtable--cache-widths (cache)
+ (nth 1 cache))
-(defun vtable--ensure-cache (table)
- (or (vtable--cache table)
- (vtable--recompute-cache table)))
+(defun vtable--cache-lines (cache)
+ (car cache))
(defun vtable-insert (table)
(let* ((spacer (vtable--spacer table))
@@ -533,7 +530,12 @@ vtable-insert
;; 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).
- (widths (nth 1 (vtable--ensure-cache table))))
+ (cache (or (gethash (vtable--cache-key) (slot-value table '-cache))
+ (let* ((data (vtable--compute-cache table))
+ (widths (vtable--compute-widths table data)))
+ (setf (gethash (vtable--cache-key) (slot-value table '-cache))
+ (list data widths)))))
+ (widths (vtable--cache-widths cache)))
;; Don't insert any header or header line if the user hasn't
;; specified the columns.
(when (slot-value table '-has-column-spec)
@@ -546,18 +548,20 @@ vtable-insert
(add-text-properties start (point)
(list 'keymap vtable-header-line-map
'rear-nonsticky t
- 'vtable table))
+ 'vtable table
+ 'vtable-cache cache))
(setq start (point))))
- (vtable--sort table)
+ (vtable--sort table cache)
;; Insert the data.
(let ((line-number 0))
- (dolist (line (car (vtable--cache table)))
+ (dolist (line (vtable--cache-lines cache))
(vtable--insert-line table line line-number widths spacer
ellipsis ellipsis-width)
(setq line-number (1+ line-number))))
(add-text-properties start (point)
(list 'rear-nonsticky t
- 'vtable table))
+ 'vtable table
+ 'vtable-cache cache))
(goto-char start)))
(defun vtable--insert-line (table line line-number widths spacer
@@ -659,16 +663,22 @@ vtable--insert-line
(defun vtable--cache-key ()
(cons (frame-terminal) (window-width)))
-(defun vtable--cache (table)
- (gethash (vtable--cache-key) (slot-value table '-cache)))
+(defun vtable--current-cache ()
+ "Return the current cache for the table at point.
+
+In `vtable-insert', the lines and widths of the vtable text are computed
+based on the current selected frame and window and stored in a cache.
+Subsequent interaction with the text of the vtable should use that cache
+via this function rather than by calling `vtable--cache-key' to look up
+the cache."
+ (get-text-property (point) 'vtable-cache))
(defun vtable--clear-cache (table)
(setf (gethash (vtable--cache-key) (slot-value table '-cache)) nil))
-(defun vtable--sort (table)
+(defun vtable--sort (table cache)
(pcase-dolist (`(,index . ,direction) (vtable-sort-by table))
- (let ((cache (vtable--cache table))
- (numerical (vtable-column--numerical
+ (let ((numerical (vtable-column--numerical
(elt (vtable-columns table) index)))
(numcomp (if (eq direction 'descend)
#'> #'<))
@@ -971,9 +981,6 @@ vtable-revert
(when column
(vtable-goto-column column))))
-(defun vtable--widths (table)
- (nth 1 (vtable--ensure-cache table)))
-
;;; Commands.
(defvar-keymap vtable-header-mode-map
@@ -998,7 +1005,7 @@ vtable-narrow-current-column
(- (* (vtable--char-width table) (or n 1))))))
(defun vtable--alter-column-width (table column delta)
- (let ((widths (vtable--widths table)))
+ (let ((widths (vtable--cache-widths (vtable--current-cache))))
(setf (aref widths column)
(max (* (vtable--char-width table) 2)
(+ (aref widths column) delta)))
@@ -1020,14 +1027,14 @@ vtable-previous-column
(interactive)
(vtable-goto-column
(max 0 (1- (or (vtable-current-column)
- (length (vtable--widths (vtable-current-table))))))))
+ (length (vtable--cache-widths (vtable--current-cache))))))))
(defun vtable-next-column ()
"Go to the next column."
(interactive)
(when (vtable-current-column)
(vtable-goto-column
- (min (1- (length (vtable--widths (vtable-current-table))))
+ (min (1- (length (vtable--cache-widths (vtable--current-cache))))
(1+ (vtable-current-column))))))
(defun vtable-revert-command ()
--
2.39.3
--=-=-=--
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.Stefan Kangas <stefankangas@HIDDEN>
to control <at> debbugs.gnu.org.
Full text available.Received: (at 69837) by debbugs.gnu.org; 1 Mar 2025 03:09:40 +0000 From debbugs-submit-bounces <at> debbugs.gnu.org Fri Feb 28 22:09:39 2025 Received: from localhost ([127.0.0.1]:56938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>) id 1toDER-0003mF-Cj for submit <at> debbugs.gnu.org; Fri, 28 Feb 2025 22:09:39 -0500 Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]:60915) by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from <stefankangas@HIDDEN>) id 1toDEO-0003lS-IL for 69837 <at> debbugs.gnu.org; Fri, 28 Feb 2025 22:09:37 -0500 Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-5e4d3f92250so3061050a12.1 for <69837 <at> debbugs.gnu.org>; Fri, 28 Feb 2025 19:09:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1740798570; x=1741403370; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:from:to:cc:subject:date:message-id:reply-to; bh=ETYus2mfnLcqNfilQGLu9HBNWh6q4ZVcho0KwNTIERY=; b=LWu+kGKyL3WWkAIghKn2jN9OjWcpMDdzmCQNGFY8X/d5W/gJa3871GJ1+VxAUjNxll wnC7HDKXBfDNcqtmH7JNE6iX3cWuPdCd4OMyivlbNTS1xP/LN0Q2/i7bfgzk9YSMO3/s THqxYROzrHjmrAFXoveqS+UNccrZyiQ+Ra1r7e0VJvfJ39T7OmaaNhU5LU+7MR1wJhGr i4ebJoPj2qg5XpbJrIxVkM0UdbV8H3wvXRwTjoWrCA5Q0vqO1R2fZpvsmJvocelCBe7k Zuv4EcD0plh7hXDacqsmoe6Fnv7b0zZB6ArtjseW+gVgwIqMpf4Z6ZqLKKgRwkaj/Swt jlRw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1740798570; x=1741403370; h=cc:to:subject:message-id:date:mime-version:references:in-reply-to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=ETYus2mfnLcqNfilQGLu9HBNWh6q4ZVcho0KwNTIERY=; b=eFMPgPu8m/neYQc6ZcLv/cC6IlHk89R0mR1+TZUle8u0rn57NoJasx/6kK9eWva54z DtTW4o0gboOMS8sVl3vdGyj/TnhpPVP8qS2HvI9/heeSod2FisqhwhiegnbjG8HJX00Z /pIOZxWIMjF1WOzsp8Zg2MhjV8XFitmUCTXocW0S1bBDTbu2PzGq3/f5KXImRZgehLNm eAbKhQo5/J2nTWf42+ZdgzY3IpFbwdmRgxiAk3rAFAN5Pag1v1W4MGgh+5ur4TBpOsB7 Ps8yI2nMfHJd2/hA/1qQuoLLCgZErUGx6Wgd+LpYhru2wxRPMAmJT6nPtUSi0Vq+k+Om EGsg== X-Forwarded-Encrypted: i=1; AJvYcCWyJ89hcCMIr27SBpLCLpkvUIet/cOspjO6I3veQ+CwPb3nInvXI0FaffkGlxeNaYtuUjb7dA==@debbugs.gnu.org X-Gm-Message-State: AOJu0YySy35V1cexBnTgjTKKPvn9jL/oOaCmH7/8HahllS9yvhEysByM 5IPFka/Nt0J0AgNuZdPLrbtma/yq+DtVBVrAGC9A4APJeURnXIbCACkOVKfRrEZKRa2k53worFa xhR8ySZ+4t/8qJE0p/eLr7pxPnqIBxPqTOAg= X-Gm-Gg: ASbGnctlwF6lAfD0NSpshYP5r+yDarigYncXKdE3p7XpffS8hRt71NnMO24DeuDQsrM LicdpaC9IMCdfIVjSaQKN7eLaACOYA2gqN4g6LVw+qS7UXMVcNr/+ftXLSP0LUXxZxYEi/hn9IG 73gx9VaCZO+LPi1nJ34UHr09gzRhM= X-Google-Smtp-Source: AGHT+IHFaLyWmUA0zkoSpdrB2sG3BWuhf+Ljc8/rylhiDo9CRIRtFmKw414Cr3x/zLkFVKGMPpv3WX0aYu4khiGNZX4= X-Received: by 2002:a05:6402:42c2:b0:5de:dd31:1fad with SMTP id 4fb4d7f45d1cf-5e4d6ad45e8mr4948800a12.6.1740798570282; Fri, 28 Feb 2025 19:09:30 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Fri, 28 Feb 2025 19:09:29 -0800 From: Stefan Kangas <stefankangas@HIDDEN> In-Reply-To: <86frvy3fci.fsf@HIDDEN> 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> <86frvy3fci.fsf@HIDDEN> MIME-Version: 1.0 Date: Fri, 28 Feb 2025 19:09:29 -0800 X-Gm-Features: AQ5f1Jqd4qvoNEHPsOl2u8s6sZYxyZLNpKQ288CzhCxvL2e5u3Nd9KUPZl9TS9c Message-ID: <CADwFkmk1Z9RqN0VeU77=VmQv0ud_ApROAze-iUVtLb5BJ=kj4Q@HIDDEN> Subject: Re: bug#69837: 29.2; vtable-update-object only works in visible windows To: Eli Zaretskii <eliz@HIDDEN> Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 69837 Cc: Adam Porter <adam@HIDDEN>, 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: -1.0 (-) Eli Zaretskii <eliz@HIDDEN> writes: >> 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. Adam, could you please install the workaround? Or maybe you did already?
bug-gnu-emacs@HIDDEN:bug#69837; Package emacs.
Full text available.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.