From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Joost Kremers Newsgroups: gmane.emacs.bugs Subject: bug#69454: Not possible to insert an empty vtable Date: Tue, 30 Apr 2024 11:10:32 +0200 Message-ID: <86jzkfcj1z.fsf@p200300d6272f17850b27304eb886326a.dip0.t-ipconnect.de> 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: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="34193"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.12.2; emacs 29.3 Cc: Adam Porter , Lars Ingebrigtsen , 69454@debbugs.gnu.org, Eric Marsden To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 30 11:12:10 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 1s1jWx-0008bY-6u for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 30 Apr 2024 11:12:09 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1s1jWe-0001dn-HS; Tue, 30 Apr 2024 05:11:48 -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 1s1jWa-0001dO-GD for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2024 05:11:44 -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 1s1jWZ-0006yY-4F for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2024 05:11:44 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1s1jWs-00064y-CO for bug-gnu-emacs@gnu.org; Tue, 30 Apr 2024 05:12:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Joost Kremers Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 30 Apr 2024 09:12: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.171446826923347 (code B ref 69454); Tue, 30 Apr 2024 09:12:02 +0000 Original-Received: (at 69454) by debbugs.gnu.org; 30 Apr 2024 09:11:09 +0000 Original-Received: from localhost ([127.0.0.1]:59245 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1jW0-00064V-F3 for submit@debbugs.gnu.org; Tue, 30 Apr 2024 05:11:08 -0400 Original-Received: from fout8-smtp.messagingengine.com ([103.168.172.151]:33733) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1s1jVv-000648-2Y for 69454@debbugs.gnu.org; Tue, 30 Apr 2024 05:11:06 -0400 Original-Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailfout.nyi.internal (Postfix) with ESMTP id 6C0C21380914; Tue, 30 Apr 2024 05:10:37 -0400 (EDT) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Tue, 30 Apr 2024 05:10:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fastmail.fm; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to; s=fm3; t=1714468237; x=1714554637; bh=A6dQNEYqiz98gTlTYauHjNElctjpWt6gvF7Eco+3TWc=; b= 3zrznqa0yZnZSrKgGxMyJcudfakIIor9dyBR71q/J9OMbOGMZkyx4aRebONL6jFp W0wyi0hakmsd4xH6zBQguxOickd7HSMe1kOtLGpbq5QcaMvm2OJ5HHO1Ejq9McoR 6oBJDW3AIP747u+fzIPDN1JeMbffxbBnuNR7bT0FDtVdXdO2jVhlzMXGa3FI41A/ +IIxYqgOT41SgdrdY3ahOMZ4rs62VKSoj5gjdfjN1JWEXxCDt+bjseetfN1y/EhM 7d9BLiVqjLxatwjscffx53Vn22TqBJn2FcKojCw1+RRhFR3TFT9NPvMhKIY4iW4P pfH6Z2fAJzQxsVKF8Necqg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1714468237; x= 1714554637; bh=A6dQNEYqiz98gTlTYauHjNElctjpWt6gvF7Eco+3TWc=; b=O tX2m+T94AJBc2WYzhJuJjSOc4ZAITYeMLmWPzCSZd4YJkZ03NPT/R7bkWuE2ikc3 b5NypaEqECzW9aJIDEYJRfScurk6s82MppVALCvmV1+fY8fbqVe+HV9vMu+cJR0m q92n5llR1GFlhHQGClAz9K+KDp//JtX/8VjBEKpu06Q08f4L6wfpv1bAC+o750/E PQFJWMTY/gTDdz4w3ML7JijxcEE+A9O+tLLExHwYyeVYSN1j7SA6Gw/8P1LACPab ChEVaH22bJ1V37/pUiKMWpHesgFZ3Xkq9KwsP3Yucauh7WR8YlxQsDwxFTT4KEjw i6KVHII7S0aX6KmTXF92g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvledrvddufedgudefucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefujghffgffkfggtgfgsehtqhertddtreejnecuhfhrohhmpeflohho shhtucfmrhgvmhgvrhhsuceojhhoohhsthhkrhgvmhgvrhhssehfrghsthhmrghilhdrfh hmqeenucggtffrrghtthgvrhhnpeetteekvddvffefuefhkeetveejieejkeevgfdvtdej tedvjeeiteekteeitdejhfenucffohhmrghinhepghhithhhuhgsrdgtohhmnecuvehluh hsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomhepjhhoohhsthhkrhgv mhgvrhhssehfrghsthhmrghilhdrfhhm X-ME-Proxy: Feedback-ID: ie15541ac:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 30 Apr 2024 05:10:35 -0400 (EDT) In-Reply-To: <86plw3yecs.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Mar 2024 10:54:43 +0200") 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:284191 Archived-At: On Sat, Mar 09 2024, Eli Zaretskii wrote: >> Date: Wed, 28 Feb 2024 15:29:11 +0100 >> From: Eric Marsden >>=20 >> Hello, >>=20 >> The following generates an error. It seems to me that it would be=20 >> preferable to insert the header line and show zero rows for the vtable. >>=20 >> =C2=A0=C2=A0 (require 'vtable) >> =C2=A0=C2=A0 (make-vtable :columns '("tweedle" "dum") :objects (list)) >>=20 >> Debugger entered--Lisp error: (wrong-number-of-arguments # 0) >> =C2=A0 max() >> =C2=A0 apply(max nil) >> =C2=A0 seq-max(nil) > I ran into this same problem myself, trying to use vtable for my package Ebib[1]. I did some digging and found that the cause of the problem is not = that the vtable is empty, but rather that the column widths cannot be determined= . If you pass explicit widths for each column, `make-vtable` (or rather `vtable-insert`) works just fine with an empty table: ``` (make-vtable :columns '((:name "tweedle" :width 30) (:name "dum" :width 10)) :objects (list)) ``` The error occurs in `vtable--compute-widths`, which returns a vector with t= he widths of each column. For columns that don't have their width set explicit= ly, the width is computed on the basis of the elements in the column, but if th= ere are no elements, that fails. > I'm not sure we want to support zero-size vtables. A better error > message would be nice, though. What do others think? For my purpose (i.e., Ebib), support for empty vtables would be a big plus.= I wouldn't even want to display some sort of text or warning, just the header= and nothing else. (I guess this could be made configurable, though. Something l= ike an :if-empty slot specifying a function to call if the table is empty. This function could then display some text, give a warning in the minibuffer, ra= ise an error, or do nothing at all.) In order to support empty vtables, the column width issue would have to be resolved, of course. My suggestion (again coming from my use-case) would be= that if some columns have no :width slot, the remaining available width (i.e., t= he window width minus the explicit column widths) is divided evenly between th= em. Of course, that may turn out to be suboptimal once objects are added to the vtable, but I don't think it's unreasonable to expect the programmer to take that into account when using vtable.el. And the user always has the option = of regenerating the table. (There's `vtable-revert-command`, after all.) For me, the reason why this would be useful is that the data that I want to display in a vtable has one field that can be very long, while the others a= re usually fairly short. In my current, custom table implementation, this long field is the right-most column and can thus use the full width of the windo= w to display its data. This works fine with vtable, except if the table is empty. Footnotes: [1] https://github.com/joostkremers/ebib/tree/devel/vtable --=20 Joost Kremers Life has its moments