From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Adam Porter Newsgroups: gmane.emacs.bugs Subject: bug#69454: Not possible to insert an empty vtable Date: Mon, 11 Mar 2024 14:57:20 -0500 Message-ID: References: <5aee0900-7459-4aef-b3c1-cdf83e48b874@risk-engineering.org> <86plw3yecs.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10898"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: 69454@debbugs.gnu.org To: Eli Zaretskii , Eric Marsden , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 11 20:59:03 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 1rjlna-0002dn-N9 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 11 Mar 2024 20:59:03 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rjlnC-0007xv-VB; Mon, 11 Mar 2024 15:58:39 -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 1rjln2-0007xb-GH for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2024 15:58:28 -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 1rjln2-0000XV-5L for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2024 15:58:28 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rjlnZ-0006nV-UY for bug-gnu-emacs@gnu.org; Mon, 11 Mar 2024 15:59:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Adam Porter Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 11 Mar 2024 19:59:01 +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.171018708926055 (code B ref 69454); Mon, 11 Mar 2024 19:59:01 +0000 Original-Received: (at 69454) by debbugs.gnu.org; 11 Mar 2024 19:58:09 +0000 Original-Received: from localhost ([127.0.0.1]:41342 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjlmi-0006mA-Gd for submit@debbugs.gnu.org; Mon, 11 Mar 2024 15:58:08 -0400 Original-Received: from heron.birch.relay.mailchannels.net ([23.83.209.82]:47975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rjlmf-0006m0-61 for 69454@debbugs.gnu.org; Mon, 11 Mar 2024 15:58:07 -0400 X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net Original-Received: from relay.mailchannels.net (localhost [127.0.0.1]) by relay.mailchannels.net (Postfix) with ESMTP id A95EC7617F8; Mon, 11 Mar 2024 19:57:29 +0000 (UTC) Original-Received: from pdx1-sub0-mail-a311.dreamhost.com (unknown [127.0.0.6]) (Authenticated sender: dreamhost) by relay.mailchannels.net (Postfix) with ESMTPA id 099CB7616F9; Mon, 11 Mar 2024 19:57:28 +0000 (UTC) ARC-Seal: i=1; s=arc-2022; d=mailchannels.net; t=1710187048; a=rsa-sha256; cv=none; b=G7m/nw6MGLWh98GgMfgscvRQwSrRWmxKXBC88TbGwuv/lzVfCG57cDdJDJc2PitUXPuxMX GMHQjWZXVc3mG8sYCv9uTcg1/Nx0kk0tZFuAZaPNAgAF8Oru1RuGpOTgeP/xvJWy11tfW6 2Uzlans+qMbEK45pYnY7ifmOzBbdQLVY3DK7TyrmPnCV5iqLV8rNKT24DyY5api8+yH6Hz 3aCLKKQJxCR8pQmr3ceggpSzCAnZqX2ev2X+mN3dcVs3vVqFCdO/SrtfpZDLlDPp01/+G+ TcAWC7Ucbwn26MCnk9Wqi57ugHZ5Rxaz7/9i1hYmKcFEq9lxddxXf47PXMVglg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=mailchannels.net; s=arc-2022; t=1710187048; 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=a8dwhueUA8a1fK7yS7I23AqqcshLo9Jik6kB3rKLEII=; b=ykzvyzVKW4tBNmmhMZjCLP5DQfVdpQvclZgBEpCFfRpuTbMv0Go3yqNKARJUKTVbF5HsgE UpoMXHTIYieKVgyV1AXKb1Gl325fpZ+SRj4G8XuqfuJEDEohgqaJqI15jndJAhyZ+CWUxi x/KLgw79KGQ+kOUbkOCYo0pR19SjUpF+noxIu/FZMu4lJisuR9kaXToxDTjNfIP8HI8G2s yPQJ59PURWlJhwZvGZSFHtBqXiGWSGUrLtbsYuFN+5dR23oZstQgCIgYYgZhOp5BLnClhC W9IIxgVT6ENhXxhzF9ZMMn0eY19wx6n7tmmA45PLH8fpc8CGKfCC8x9bcPcRdg== ARC-Authentication-Results: i=1; rspamd-5db57bc4b6-v7clm; auth=pass smtp.auth=dreamhost smtp.mailfrom=adam@alphapapa.net X-Sender-Id: dreamhost|x-authsender|adam@alphapapa.net X-MC-Relay: Neutral X-MailChannels-SenderId: dreamhost|x-authsender|adam@alphapapa.net X-MailChannels-Auth-Id: dreamhost X-Arithmetic-Army: 103fa8495d20be1b_1710187048369_2443385048 X-MC-Loop-Signature: 1710187048369:2758609228 X-MC-Ingress-Time: 1710187048368 Original-Received: from pdx1-sub0-mail-a311.dreamhost.com (pop.dreamhost.com [64.90.62.162]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384) by 100.126.245.200 (trex/6.9.2); Mon, 11 Mar 2024 19:57:28 +0000 Original-Received: from [10.66.7.46] (unknown [91.193.232.98]) (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@alphapapa.net) by pdx1-sub0-mail-a311.dreamhost.com (Postfix) with ESMTPSA id 4TtncR1m1xz8S; Mon, 11 Mar 2024 12:57:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=alphapapa.net; s=dreamhost; t=1710187047; bh=a8dwhueUA8a1fK7yS7I23AqqcshLo9Jik6kB3rKLEII=; h=Date:Subject:To:Cc:From:Content-Type:Content-Transfer-Encoding; b=VxLc5XZcAf473SbruESokzhEtpQrVvDRPmsehYPT2ao+LQEr/q0jR87TutEkiXbVB 4mk1AQkk7777c+vJWk9BOL/QB0WIgcnlJttCMj02x0txUP/al3EyhJ9P82YmnSfFWr DcfgEpDHMPeJHCg1qKvFeCH3MwyAmGyedC+ltujgcbgBQSegsqVlbjcRcbzD+LIgST deIDE3N7oEBXyQ48NAiRwgBW7ihgihZgJ62MyuPE9LPzZlJS2d55FBZf0GjZw15JTC MbYX40ZEYQPFwUY/3i6CO/7nD0ZDhYvVTQ+6gIbuX/QW9GGOVeR4Vl7hKxuSl/uuzg aCBwkF1CDaiCw== Content-Language: en-US In-Reply-To: <86plw3yecs.fsf@gnu.org> 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:281491 Archived-At: 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.