unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Joost Kremers <joostkremers@fastmail.fm>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Adam Porter <adam@alphapapa.net>,
	Lars Ingebrigtsen <larsi@gnus.org>,
	69454@debbugs.gnu.org,
	Eric Marsden <eric.marsden@risk-engineering.org>
Subject: bug#69454: Not possible to insert an empty vtable
Date: Tue, 30 Apr 2024 11:10:32 +0200	[thread overview]
Message-ID: <86jzkfcj1z.fsf@p200300d6272f17850b27304eb886326a.dip0.t-ipconnect.de> (raw)
In-Reply-To: <86plw3yecs.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 09 Mar 2024 10:54:43 +0200")

On Sat, Mar 09 2024, Eli Zaretskii wrote:
>> Date: Wed, 28 Feb 2024 15:29:11 +0100
>> From: Eric Marsden <eric.marsden@risk-engineering.org>
>> 
>> 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 #<subr max> 0)
>>    max()
>>    apply(max nil)
>>    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 the
widths of each column. For columns that don't have their width set explicitly,
the width is computed on the basis of the elements in the column, but if there
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 like
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, raise
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., the
window width minus the explicit column widths) is divided evenly between them.

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 are
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 window 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

-- 
Joost Kremers
Life has its moments





  parent reply	other threads:[~2024-04-30  9:10 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-28 14:29 bug#69454: Not possible to insert an empty vtable Eric Marsden
2024-03-09  8:54 ` Eli Zaretskii
2024-03-11 19:57   ` Adam Porter
2024-03-14  9:37     ` Eli Zaretskii
2024-03-16  0:14       ` Adam Porter
2024-04-30  9:10   ` Joost Kremers [this message]
2024-04-30 12:14     ` Eli Zaretskii
     [not found]       ` <8f5fb814-5d88-4ad3-b12a-8246325d5d21@alphapapa.net>
2024-05-01 11:54         ` Eli Zaretskii
2024-05-02  7:31         ` Joost Kremers
2024-05-05 12:15     ` Joost Kremers
2024-05-30 21:40       ` Joost Kremers
2024-05-30 21:52         ` Joost Kremers
2024-05-31  5:24           ` Eli Zaretskii
2024-05-31  6:54             ` Joost Kremers
2024-06-02 17:49               ` Adam Porter
2024-06-03 12:13                 ` Joost Kremers

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=86jzkfcj1z.fsf@p200300d6272f17850b27304eb886326a.dip0.t-ipconnect.de \
    --to=joostkremers@fastmail.fm \
    --cc=69454@debbugs.gnu.org \
    --cc=adam@alphapapa.net \
    --cc=eliz@gnu.org \
    --cc=eric.marsden@risk-engineering.org \
    --cc=larsi@gnus.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).