bug#69927: [PATCH] Fix function vtable--recompute-numerical

bug#69927: [PATCH] Fix function vtable--recompute-numerical

[Adam Porter]

[-- Attachment #1: Type: text/plain, Size: 105 bytes --]

Hi,

Please see the attached patch which fixes the function 
`vtable--recompute-numerical'.

Thanks,
Adam

[-- Attachment #2: 0001-Fix-vtable-recompute-numerical.patch --]
[-- Type: text/x-patch, Size: 1188 bytes --]

From 65fc7d8d17b8ead32de3d1986d5adccebc4ff7b2 Mon Sep 17 00:00:00 2001
From: Adam Porter <adam@alphapapa.net>
Date: Thu, 21 Mar 2024 02:13:28 -0500
Subject: [PATCH] Fix 'vtable--recompute-numerical'

* lisp/emacs-lisp/vtable.el (vtable--recompute-numerical): Fix function.

Each element of LINE being tested is a list, the first element of which
is the value actually being represented in the table.  Previously, the
NUMBERP test would always fail, because it was being compared with the
list rather than the intended value in it; that could cause the whole
table to be recomputed, sometimes unnecessarily.
---
 lisp/emacs-lisp/vtable.el | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lisp/emacs-lisp/vtable.el b/lisp/emacs-lisp/vtable.el
index 15a430f5c26..5f7d3ae5210 100644
--- a/lisp/emacs-lisp/vtable.el
+++ b/lisp/emacs-lisp/vtable.el
@@ -743,7 +743,7 @@ vtable--recompute-numerical
     (seq-do-indexed
      (lambda (elem index)
        (when (and (vtable-column--numerical (elt columns index))
-                  (not (numberp elem)))
+                  (not (numberp (car elem))))
          (setq recompute t)))
      line)
     (when recompute
-- 
2.30.2

bug#69927: [PATCH] Fix function vtable--recompute-numerical

[Eli Zaretskii]

> Date: Thu, 21 Mar 2024 02:20:36 -0500
> From: Adam Porter <adam@alphapapa.net>
> 
> Please see the attached patch which fixes the function 
> `vtable--recompute-numerical'.

Thanks, installed on master, and closing the bug.

Btw, I noticed that you use a style for commit log messages that is
not our preferred style.  (I'm aware of the fact that a couple of
other contributors use such a style, and it is not completely wrong,
just a bit sub-optimal.)  The preferred style describes the summary of
the change in the heading line (so "git log --format=oneline" and its
ilk produce meaningful and useful output), then comes the expanded
description of the change and its rationale, and finally the actual
changes made in specific functions.  See the way I modified the log
message when installing the changes.