From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#69454: Not possible to insert an empty vtable Date: Thu, 14 Mar 2024 11:37:21 +0200 Message-ID: <864jd9b1da.fsf@gnu.org> References: <5aee0900-7459-4aef-b3c1-cdf83e48b874@risk-engineering.org> <86plw3yecs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19259"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, 69454@debbugs.gnu.org, eric.marsden@risk-engineering.org To: Adam Porter Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Mar 14 10:38:36 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rkhXm-0004jW-Gz for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 14 Mar 2024 10:38:34 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rkhXg-0001xu-0O; Thu, 14 Mar 2024 05:38:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rkhXf-0001xm-Bt for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2024 05:38:27 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rkhXe-0002Dh-My for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2024 05:38:27 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rkhYE-00023d-7r for bug-gnu-emacs@gnu.org; Thu, 14 Mar 2024 05:39:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 14 Mar 2024 09:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 69454 X-GNU-PR-Package: emacs Original-Received: via spool by 69454-submit@debbugs.gnu.org id=B69454.17104091117867 (code B ref 69454); Thu, 14 Mar 2024 09:39:02 +0000 Original-Received: (at 69454) by debbugs.gnu.org; 14 Mar 2024 09:38:31 +0000 Original-Received: from localhost ([127.0.0.1]:48356 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkhXi-00022p-TH for submit@debbugs.gnu.org; Thu, 14 Mar 2024 05:38:31 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rkhXh-00022c-9d for 69454@debbugs.gnu.org; Thu, 14 Mar 2024 05:38:29 -0400 Original-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 ) id 1rkhX1-00024e-5s; Thu, 14 Mar 2024 05:37:47 -0400 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=WoUCHENKTgLCK8JRpVEz1N9UeEoPrCsNzIpqwcysyXQ=; b=GfgkdPAUPBd/mgX+pFr3 VX3q+JSehkIGr6EU5Zg70KiSzy8e9FuFa9YxFjHKeSCFZ7qFu+djFDJToHPf4HQ9Aq/8e4Ub9+78N 5o6Bt2avs08tZTZY4cGPe5ZzsGYFMo2JgSQ9v48x11JCgB61JC0a6ErUniLGvRdxncfd6MLKQokWh YYweixRsjm/E73kXm3CGs4UmCmWF1F7fjJCZRRCG5RpX8sgoLTYSvzWYb3XNczjQUxliqXW4if7sJ tlQjxRWquWTJMwobabWAl5lGhd1nQMxpKMb2rdEAm91wAjzi3mW/0tWUNi2SG20Hwes+rpL3wiU4y 3FGpzzCNP8cntg==; In-Reply-To: (message from Adam Porter on Mon, 11 Mar 2024 14:57:20 -0500) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:281602 Archived-At: > Date: Mon, 11 Mar 2024 14:57:20 -0500 > Cc: 69454@debbugs.gnu.org > From: Adam Porter > > Hi Eli, > > > P.S. Adam, I took the liberty of adding you to this discussion, since > > you seem lately to be interested in vtable. > > Thanks for adding me. Indeed, I've found vtable to be very useful in my > new listen.el package. > > On 3/9/24 02:54, Eli Zaretskii wrote: > >> Date: Wed, 28 Feb 2024 15:29:11 +0100 > >> From: Eric Marsden > >> > >> Hello, > >> > >> The following generates an error. It seems to me that it would be > >> preferable to insert the header line and show zero rows for the vtable. > >> > >>    (require 'vtable) > >>    (make-vtable :columns '("tweedle" "dum") :objects (list)) > >> > >> Debugger entered--Lisp error: (wrong-number-of-arguments # 0) > >>   max() > >>   apply(max nil) > >>   seq-max(nil) > > > > I'm not sure we want to support zero-size vtables. A better error > > message would be nice, though. What do others think? > > I tend to agree with Eric that it would be helpful if vtable could > handle having an empty objects collection value to insert, because it > saves the application from having to wrap the rather large `make-vtable' > form in a `when' block, like here: > > https://github.com/alphapapa/listen.el/blob/e9ea67350cf3b6cd870561c5e52d4b5255b04d34/listen-queue.el#L135 > > Also, it's possible that, after inserting a vtable, the collection of > objects may be modified so that the collection is empty--then if the the > vtable is reverted, it should be able to handle the case of the > collection being empty. > > AFAICT there's not much the application could do to avoid errors in that > case, other than working outside of vtable's revert API and calling the > function that tested the collection and conditionally inserted the > vtable in the first place--in which case the vtable revert API would > seem useless. > > So IMO, when inserting or reverting a vtable, vtable ought to check > whether the collection is empty; and if so, handle it gracefully, > meaning that an "empty vtable" (whatever that would mean; maybe just one > line of text saying that it's an empty collection) would still be > inserted, and that if the collection became non-nil, it could be > reverted and displayed properly. Thanks. Would you or Eric like to submit a patch along these lines?