GNU bug report logs - #73775
30.0.90; vtable: can't handle 0 data rows

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 73775 in the body.
You can then email your comments to 73775 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Augusto Stoffel <arstoffel <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.0.90; vtable: can't handle 0 data rows
Date: Sat, 12 Oct 2024 19:22:46 +0200

This call produces the error (wrong-number-of-arguments #<subr max> 0):

    (make-vtable
     :use-header-line nil
     :columns (mapcar (lambda (name) (list :name name :min-width 10))
     '("A" "B" "C"))
     :objects nil)

The following would get rid of the error, but the resulting table
misbehaves slightly (say when I press S on it to sort).  Perhaps someone
else has a better idea.

modified   lisp/emacs-lisp/vtable.el
@@ -861,9 +861,10 @@ vtable--compute-widths
                    (vtable--compute-width table (vtable-column-width column)))
               ;; Compute based on the displayed widths of
               ;; the data.
-              (seq-max (seq-map (lambda (elem)
+              (seq-max (or (seq-map (lambda (elem)
                                   (nth 1 (elt (cdr elem) index)))
-                                cache)))))
+                                    cache)
+                           '(0))))))
         ;; Let min-width/max-width specs have their say.
         (when-let ((min-width (and (vtable-column-min-width column)
                                    (vtable--compute-width

Message #8 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Augusto Stoffel <arstoffel <at> gmail.com>, Adam Porter <adam <at> alphapapa.net>
Cc: 73775 <at> debbugs.gnu.org
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Sat, 12 Oct 2024 21:24:18 +0300

> From: Augusto Stoffel <arstoffel <at> gmail.com>
> Date: Sat, 12 Oct 2024 19:22:46 +0200
> 
> This call produces the error (wrong-number-of-arguments #<subr max> 0):
> 
>     (make-vtable
>      :use-header-line nil
>      :columns (mapcar (lambda (name) (list :name name :min-width 10))
>      '("A" "B" "C"))
>      :objects nil)
> 
> The following would get rid of the error, but the resulting table
> misbehaves slightly (say when I press S on it to sort).  Perhaps someone
> else has a better idea.
> 
> modified   lisp/emacs-lisp/vtable.el
> @@ -861,9 +861,10 @@ vtable--compute-widths
>                     (vtable--compute-width table (vtable-column-width column)))
>                ;; Compute based on the displayed widths of
>                ;; the data.
> -              (seq-max (seq-map (lambda (elem)
> +              (seq-max (or (seq-map (lambda (elem)
>                                    (nth 1 (elt (cdr elem) index)))
> -                                cache)))))
> +                                    cache)
> +                           '(0))))))
>          ;; Let min-width/max-width specs have their say.
>          (when-let ((min-width (and (vtable-column-min-width column)
>                                     (vtable--compute-width
> 
> 

Adam, any comments or suggestions?

Message #11 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Adam Porter <adam <at> alphapapa.net>
To: Eli Zaretskii <eliz <at> gnu.org>, Augusto Stoffel <arstoffel <at> gmail.com>
Cc: 73775 <at> debbugs.gnu.org
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Sat, 12 Oct 2024 19:12:50 -0500

Hi Eli, Augusto,

On 10/12/24 13:24, Eli Zaretskii wrote:
>> From: Augusto Stoffel <arstoffel <at> gmail.com>
>> Date: Sat, 12 Oct 2024 19:22:46 +0200
>>
>> This call produces the error (wrong-number-of-arguments #<subr max> 0):
>>
>>      (make-vtable
>>       :use-header-line nil
>>       :columns (mapcar (lambda (name) (list :name name :min-width 10))
>>       '("A" "B" "C"))
>>       :objects nil)
>>
>> The following would get rid of the error, but the resulting table
>> misbehaves slightly (say when I press S on it to sort).  Perhaps someone
>> else has a better idea.
>>
>> modified   lisp/emacs-lisp/vtable.el
>> @@ -861,9 +861,10 @@ vtable--compute-widths
>>                      (vtable--compute-width table (vtable-column-width column)))
>>                 ;; Compute based on the displayed widths of
>>                 ;; the data.
>> -              (seq-max (seq-map (lambda (elem)
>> +              (seq-max (or (seq-map (lambda (elem)
>>                                     (nth 1 (elt (cdr elem) index)))
>> -                                cache)))))
>> +                                    cache)
>> +                           '(0))))))
>>           ;; Let min-width/max-width specs have their say.
>>           (when-let ((min-width (and (vtable-column-min-width column)
>>                                      (vtable--compute-width
>>
>>
> 
> Adam, any comments or suggestions?

I may be mistaken, but this seems like a duplicate of bug#69454.

--Adam

Message #14 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Adam Porter <adam <at> alphapapa.net>, Joost Kremers <joostkremers <at> fastmail.fm>
Cc: 73775 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Sun, 13 Oct 2024 08:27:15 +0300

> Date: Sat, 12 Oct 2024 19:12:50 -0500
> Cc: 73775 <at> debbugs.gnu.org
> From: Adam Porter <adam <at> alphapapa.net>
> 
> > Adam, any comments or suggestions?
> 
> I may be mistaken, but this seems like a duplicate of bug#69454.

II had a vague memory this was already discussed, but couldn't find
such a bug.  Thanks for pointing this out.

We seem to have dropped the ball on that one.  Joost, would you please
rebase on the current master and resubmit?

Augusto, do the patches there solve the problem in your case?

Message #17 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Joost Kremers <joostkremers <at> fastmail.fm>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Adam Porter <adam <at> alphapapa.net>, 73775 <at> debbugs.gnu.org,
 arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Sun, 13 Oct 2024 10:00:24 +0200

On Sun, Oct 13 2024, Eli Zaretskii wrote:
>> Date: Sat, 12 Oct 2024 19:12:50 -0500
>> Cc: 73775 <at> debbugs.gnu.org
>> From: Adam Porter <adam <at> alphapapa.net>
>> 
>> > Adam, any comments or suggestions?
>> 
>> I may be mistaken, but this seems like a duplicate of bug#69454.
>
> II had a vague memory this was already discussed, but couldn't find
> such a bug.  Thanks for pointing this out.
>
> We seem to have dropped the ball on that one.  Joost, would you please
> rebase on the current master and resubmit?

Sure, will do. Just give me a day or two to find some time.

-- 
Joost Kremers
Life has its moments

Message #20 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Joost Kremers <joostkremers <at> fastmail.fm>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Adam Porter <adam <at> alphapapa.net>, 73775 <at> debbugs.gnu.org,
 arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Mon, 14 Oct 2024 13:25:22 +0200

[Message part 1 (text/plain, inline)]

On Sun, Oct 13 2024, Eli Zaretskii wrote:
>> Date: Sat, 12 Oct 2024 19:12:50 -0500
>> Cc: 73775 <at> debbugs.gnu.org
>> From: Adam Porter <adam <at> alphapapa.net>
>> 
>> > Adam, any comments or suggestions?
>> 
>> I may be mistaken, but this seems like a duplicate of bug#69454.
>
> II had a vague memory this was already discussed, but couldn't find
> such a bug.  Thanks for pointing this out.
>
> We seem to have dropped the ball on that one.  Joost, would you please
> rebase on the current master and resubmit?

Here is the patch again, rebased on current master (or what was current
master earlier today... :D )

As before, there are three patches, because they solve different issues
that stood in the way of having empty vtables. I could squash them into
one, of course. Also, the documentation and NEWS update are separate.

Regards,

Joost



-- 
Joost Kremers
Life has its moments

[0001-Allow-empty-vtable.patch (text/x-patch, attachment)]

[0002-Enable-inserting-new-objects-into-empty-vtable.patch (text/x-patch, attachment)]

[0003-vtable-allow-resetting-column-alignment-when-table-d.patch (text/x-patch, attachment)]

[0004-Update-vtable-documentation.patch (text/x-patch, attachment)]

Message #23 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Adam Porter <adam <at> alphapapa.net>
To: Joost Kremers <joostkremers <at> fastmail.fm>, Eli Zaretskii <eliz <at> gnu.org>
Cc: 73775 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Tue, 15 Oct 2024 23:12:08 -0500

Hi Joost,

On 10/14/24 06:25, Joost Kremers wrote:
> On Sun, Oct 13 2024, Eli Zaretskii wrote:
>>> Date: Sat, 12 Oct 2024 19:12:50 -0500
>>> Cc: 73775 <at> debbugs.gnu.org
>>> From: Adam Porter <adam <at> alphapapa.net>
>>>
>>>> Adam, any comments or suggestions?
>>>
>>> I may be mistaken, but this seems like a duplicate of bug#69454.
>>
>> II had a vague memory this was already discussed, but couldn't find
>> such a bug.  Thanks for pointing this out.
>>
>> We seem to have dropped the ball on that one.  Joost, would you please
>> rebase on the current master and resubmit?
> 
> Here is the patch again, rebased on current master (or what was current
> master earlier today... :D )
> 
> As before, there are three patches, because they solve different issues
> that stood in the way of having empty vtables. I could squash them into
> one, of course. Also, the documentation and NEWS update are separate.

Just a few minor suggestions:

+  "Compute the display widths for TABLE.
+CACHE is TABLE's cache data as returned by `vtable--compute-cache'."
+  (let ((widths (seq-map-indexed
+                 (lambda (column index)
+                   (let ((width
+                          (or
+                           ;; Explicit widths.
+                           (and (vtable-column-width column)
+                                (vtable--compute-width table 
(vtable-column-width column)))
+                           ;; If the vtable is empty and no explicit 
width is given,
+                           ;; set its width to 0 and deal with it below.
+                           (if (null cache)

I may be mistaken (as I haven't examined all of the relevant code), but 
if CACHE is nil when this function is called, won't it always be null? 
If so, you could check its value once, at first, rather than each time 
through this loop.

+    ;; If there are any zero-width columns, divide the remaining window
+    ;; width evenly over them.
+    (when (member 0 widths)
+      (let* ((combined-width (apply #'+ widths))
+             (n-0cols (length (seq-keep #'zerop widths)))

You could use SEQ-COUNT here, which would avoid consing a new list.

@@ -484,3 +495,8 @@ vtable--compute-columns
                                              table))
            (setf (elt numerical index) nil)))
        (vtable-columns table)))
+    ;; Check if any columns have an explicit `align' property.
+    (unless recompute
+      (dolist (column (vtable-columns table))
+        (if (vtable-column-align column)
+            (setf (vtable-column--aligned column) t))))

This could be a WHEN instead of a "one-armed IF".  :)

Message #26 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Joost Kremers <joostkremers <at> fastmail.fm>
To: Adam Porter <adam <at> alphapapa.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, arstoffel <at> gmail.com, 73775 <at> debbugs.gnu.org
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Wed, 16 Oct 2024 18:19:41 +0200

[Message part 1 (text/plain, inline)]

Hi Adam,

Thanks for looking at this.

On Tue, Oct 15 2024, Adam Porter wrote:
> Just a few minor suggestions:
>
> +  "Compute the display widths for TABLE.
> +CACHE is TABLE's cache data as returned by `vtable--compute-cache'."
> +  (let ((widths (seq-map-indexed
> +                 (lambda (column index)
> +                   (let ((width
> +                          (or
> +                           ;; Explicit widths.
> +                           (and (vtable-column-width column)
> +                                (vtable--compute-width table
> (vtable-column-width column)))
> +                           ;; If the vtable is empty and no explicit width
> is given,
> +                           ;; set its width to 0 and deal with it below.
> +                           (if (null cache)
>
> I may be mistaken (as I haven't examined all of the relevant code), but if
> CACHE is nil when this function is called, won't it always be null? If so,
> you could check its value once, at first, rather than each time through
> this loop.

Unfortunately, it has to be checked anew in every iteration, because it
determines for each column individually if we need to (temporarily) set its
width to 0. It also needs to keep the following `seq-max` from erroring out
(due to `seq-map` returning `nil`).

> +    ;; If there are any zero-width columns, divide the remaining window
> +    ;; width evenly over them.
> +    (when (member 0 widths)
> +      (let* ((combined-width (apply #'+ widths))
> +             (n-0cols (length (seq-keep #'zerop widths)))
>
> You could use SEQ-COUNT here, which would avoid consing a new list.

There may even be a better way. If I keep track of the number of zero-width
columns in the loop above, I don't even need to count them here. I've
implemented that in the updated patch attached to this message.

> @@ -484,3 +495,8 @@ vtable--compute-columns
>                                               table))
>             (setf (elt numerical index) nil)))
>         (vtable-columns table)))
> +    ;; Check if any columns have an explicit `align' property.
> +    (unless recompute
> +      (dolist (column (vtable-columns table))
> +        (if (vtable-column-align column)
> +            (setf (vtable-column--aligned column) t))))
>
> This could be a WHEN instead of a "one-armed IF".  :)

Yes, sirree! (I don't really agree with the "one-armed if should be
when"-stance, but I'd be hard-pressed to say when I prefer "if" and when
"when", and it's hardly a hill I want to die on, so I made the change. 😆 )

-- 
Joost Kremers
Life has its moments

[0001-Allow-empty-vtable.patch (text/x-patch, attachment)]

[0002-Enable-inserting-new-objects-into-empty-vtable.patch (text/x-patch, attachment)]

[0003-vtable-allow-resetting-column-alignment-when-table-d.patch (text/x-patch, attachment)]

[0004-Update-vtable-documentation.patch (text/x-patch, attachment)]

Message #31 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: adam <at> alphapapa.net, Joost Kremers <joostkremers <at> fastmail.fm>
Cc: 73775 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Sun, 27 Oct 2024 12:34:34 +0200

> From: Joost Kremers <joostkremers <at> fastmail.fm>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  arstoffel <at> gmail.com,  73775 <at> debbugs.gnu.org
> Date: Wed, 16 Oct 2024 18:19:41 +0200
> 
> Hi Adam,
> 
> Thanks for looking at this.
> 
> On Tue, Oct 15 2024, Adam Porter wrote:
> > Just a few minor suggestions:
> >
> > +  "Compute the display widths for TABLE.
> > +CACHE is TABLE's cache data as returned by `vtable--compute-cache'."
> > +  (let ((widths (seq-map-indexed
> > +                 (lambda (column index)
> > +                   (let ((width
> > +                          (or
> > +                           ;; Explicit widths.
> > +                           (and (vtable-column-width column)
> > +                                (vtable--compute-width table
> > (vtable-column-width column)))
> > +                           ;; If the vtable is empty and no explicit width
> > is given,
> > +                           ;; set its width to 0 and deal with it below.
> > +                           (if (null cache)
> >
> > I may be mistaken (as I haven't examined all of the relevant code), but if
> > CACHE is nil when this function is called, won't it always be null? If so,
> > you could check its value once, at first, rather than each time through
> > this loop.
> 
> Unfortunately, it has to be checked anew in every iteration, because it
> determines for each column individually if we need to (temporarily) set its
> width to 0. It also needs to keep the following `seq-max` from erroring out
> (due to `seq-map` returning `nil`).
> 
> > +    ;; If there are any zero-width columns, divide the remaining window
> > +    ;; width evenly over them.
> > +    (when (member 0 widths)
> > +      (let* ((combined-width (apply #'+ widths))
> > +             (n-0cols (length (seq-keep #'zerop widths)))
> >
> > You could use SEQ-COUNT here, which would avoid consing a new list.
> 
> There may even be a better way. If I keep track of the number of zero-width
> columns in the loop above, I don't even need to count them here. I've
> implemented that in the updated patch attached to this message.
> 
> > @@ -484,3 +495,8 @@ vtable--compute-columns
> >                                               table))
> >             (setf (elt numerical index) nil)))
> >         (vtable-columns table)))
> > +    ;; Check if any columns have an explicit `align' property.
> > +    (unless recompute
> > +      (dolist (column (vtable-columns table))
> > +        (if (vtable-column-align column)
> > +            (setf (vtable-column--aligned column) t))))
> >
> > This could be a WHEN instead of a "one-armed IF".  :)
> 
> Yes, sirree! (I don't really agree with the "one-armed if should be
> when"-stance, but I'd be hard-pressed to say when I prefer "if" and when
> "when", and it's hardly a hill I want to die on, so I made the change. 😆 )

Adam, any further comments?  Or should I install this?

Message #34 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Adam Porter <adam <at> alphapapa.net>
To: Eli Zaretskii <eliz <at> gnu.org>, Joost Kremers <joostkremers <at> fastmail.fm>
Cc: 73775 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Tue, 29 Oct 2024 18:39:48 -0500

Hi Eli,

On 10/27/24 05:34, Eli Zaretskii wrote:
> 
> Adam, any further comments?  Or should I install this?

I confess that I haven't tested the patch, but assuming that it works as 
intended, I have no objections.  :)  If you want me to test it, let me 
know; have been pretty busy lately, so I haven't taken the time.

--Adam

Message #37 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joost Kremers <joostkremers <at> fastmail.fm>
Cc: adam <at> alphapapa.net, 73775 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Thu, 31 Oct 2024 12:30:09 +0200

> From: Joost Kremers <joostkremers <at> fastmail.fm>
> Cc: Eli Zaretskii <eliz <at> gnu.org>,  arstoffel <at> gmail.com,  73775 <at> debbugs.gnu.org
> Date: Wed, 16 Oct 2024 18:19:41 +0200
> 
> Hi Adam,
> 
> Thanks for looking at this.
> 
> On Tue, Oct 15 2024, Adam Porter wrote:
> > Just a few minor suggestions:
> >
> > +  "Compute the display widths for TABLE.
> > +CACHE is TABLE's cache data as returned by `vtable--compute-cache'."
> > +  (let ((widths (seq-map-indexed
> > +                 (lambda (column index)
> > +                   (let ((width
> > +                          (or
> > +                           ;; Explicit widths.
> > +                           (and (vtable-column-width column)
> > +                                (vtable--compute-width table
> > (vtable-column-width column)))
> > +                           ;; If the vtable is empty and no explicit width
> > is given,
> > +                           ;; set its width to 0 and deal with it below.
> > +                           (if (null cache)
> >
> > I may be mistaken (as I haven't examined all of the relevant code), but if
> > CACHE is nil when this function is called, won't it always be null? If so,
> > you could check its value once, at first, rather than each time through
> > this loop.
> 
> Unfortunately, it has to be checked anew in every iteration, because it
> determines for each column individually if we need to (temporarily) set its
> width to 0. It also needs to keep the following `seq-max` from erroring out
> (due to `seq-map` returning `nil`).
> 
> > +    ;; If there are any zero-width columns, divide the remaining window
> > +    ;; width evenly over them.
> > +    (when (member 0 widths)
> > +      (let* ((combined-width (apply #'+ widths))
> > +             (n-0cols (length (seq-keep #'zerop widths)))
> >
> > You could use SEQ-COUNT here, which would avoid consing a new list.
> 
> There may even be a better way. If I keep track of the number of zero-width
> columns in the loop above, I don't even need to count them here. I've
> implemented that in the updated patch attached to this message.
> 
> > @@ -484,3 +495,8 @@ vtable--compute-columns
> >                                               table))
> >             (setf (elt numerical index) nil)))
> >         (vtable-columns table)))
> > +    ;; Check if any columns have an explicit `align' property.
> > +    (unless recompute
> > +      (dolist (column (vtable-columns table))
> > +        (if (vtable-column-align column)
> > +            (setf (vtable-column--aligned column) t))))
> >
> > This could be a WHEN instead of a "one-armed IF".  :)
> 
> Yes, sirree! (I don't really agree with the "one-armed if should be
> when"-stance, but I'd be hard-pressed to say when I prefer "if" and when
> "when", and it's hardly a hill I want to die on, so I made the change. 😆 )

Thanks.  I wanted to install this, but at least the first patch no
longer applies; could you please rebase and resubmit?  When you do,
please mention the bug number in all the commit log messages.

> * lisp/emacs-lisp/vtable.el (vtable--compute-columns): if a column was
>   not created with an explicit 'align' property, allow changing this
>   property when the column data changes from numeric to non-numeric (or
>   vice versa). This makes it possible to add data to an empty table,
>   because in a table without data all columns are assumed to be numeric
>   and right-aligned.

This should be reformatted according to our conventions: start with a
capital letter, leave two spaces between sentences, and not to indent
lines.

> +** 'make-vtable' can create an empty vtable

This should end in a period.  Also, please mark the entry with "+++",
since the manuals were updated.

Message #40 received at 73775 <at> debbugs.gnu.org (full text, mbox):

From: Joost Kremers <joostkremers <at> fastmail.fm>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: adam <at> alphapapa.net, 73775 <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Wed, 06 Nov 2024 09:53:14 +0100

[Message part 1 (text/plain, inline)]

On Thu, Oct 31 2024, Eli Zaretskii wrote:
[empty vtable patches]
> Thanks.  I wanted to install this, but at least the first patch no
> longer applies; could you please rebase and resubmit?  When you do,
> please mention the bug number in all the commit log messages.

Here are the updated patches, including the documentation changes you
requested and the when-let --> when-let* conversion.

Regards,

Joost


-- 
Joost Kremers
Life has its moments

[0001-Allow-empty-vtable.patch (text/x-patch, attachment)]

[0002-Enable-inserting-new-objects-into-empty-vtable.patch (text/x-patch, attachment)]

[0003-vtable-allow-resetting-column-alignment-when-table-d.patch (text/x-patch, attachment)]

[0004-Update-vtable-documentation.patch (text/x-patch, attachment)]

Message #45 received at 73775-done <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Joost Kremers <joostkremers <at> fastmail.fm>
Cc: adam <at> alphapapa.net, 73775-done <at> debbugs.gnu.org, arstoffel <at> gmail.com
Subject: Re: bug#73775: 30.0.90; vtable: can't handle 0 data rows
Date: Sat, 09 Nov 2024 12:15:38 +0200

> From: Joost Kremers <joostkremers <at> fastmail.fm>
> Cc: adam <at> alphapapa.net,  arstoffel <at> gmail.com,  73775 <at> debbugs.gnu.org
> Date: Wed, 06 Nov 2024 09:53:14 +0100
> 
> On Thu, Oct 31 2024, Eli Zaretskii wrote:
> [empty vtable patches]
> > Thanks.  I wanted to install this, but at least the first patch no
> > longer applies; could you please rebase and resubmit?  When you do,
> > please mention the bug number in all the commit log messages.
> 
> Here are the updated patches, including the documentation changes you
> requested and the when-let --> when-let* conversion.

Thanks, installed on the master branch, and closing the bug.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.