GNU bug report logs -
#80056
[PATCH] Add vtable column-lessp sorting comparator
Previous Next
To reply to this bug, email your comments to 80056 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#80056; Package
emacs.
(Mon, 22 Dec 2025 21:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Stéphane Marks <shipmints <at> gmail.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 22 Dec 2025 21:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
This fix allows vtable columns with complex raw values to be sorted
according to the caller's needs where before it would have been converted
to a string and sorted lexically. It can also be used to ignore case for
strings, for example.
There was some discussion about using the new sort function keyword
interface. It may be possible to dynamically construct :key and :lessp
functions from the table's sort-by criteria that covers multi-key,
multi-directional, and custom lessp sorting. This is something we can
tackle later on.
There was a suggestion to call the comparator slot lessp rather than
comparator and that's what I've done.
-Stéphane
[Message part 2 (text/html, inline)]
[0001-Add-vtable-column-lessp-sorting-comparator.patch (application/octet-stream, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#80056; Package
emacs.
(Tue, 23 Dec 2025 10:18:02 GMT)
Full text and
rfc822 format available.
Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):
Hi Stéphane,
thanks again for taking up this topic, as there's much to be improved in
vtable in this area.
I'd suggest starting with the most fundamental part, namely migrating
from the old sort API + handcrafted comparison function to using the new
sort API + value< as comparison function.
Note that this is slightly backward incompatible, since the old
comparison can e.g. compare a string against nil (badly, because it will
treat nil as "nil" instead of "", which would be more reasonable). But
that's kind of minor and a backwards incompatibility we should go
through with. Note that the current comparison function can error out
anyway if a column contains a mix of string and numbers or a mix or
numbers and nils.
Also, if there is an error in sorting, we should just skip sorting by
that column (and possibly display a warning message) instead of failing
to display the table. So the aforementioned backwards incompatibility
becomes completely innocuous.
In terms of code, what I'm saying should boil down to (although I
haven't tested):
modified lisp/emacs-lisp/vtable.el
@@ -654,28 +654,10 @@ vtable--clear-cache
(defun vtable--sort (table)
(pcase-dolist (`(,index . ,direction) (vtable-sort-by table))
- (let ((cache (vtable--cache table))
- (numerical (vtable-column--numerical
- (elt (vtable-columns table) index)))
- (numcomp (if (eq direction 'descend)
- #'> #'<))
- (stringcomp (if (eq direction 'descend)
- #'string> #'string<)))
- (setcar cache
- (sort (car cache)
- (lambda (e1 e2)
- (let ((c1 (elt e1 (1+ index)))
- (c2 (elt e2 (1+ index))))
- (if numerical
- (funcall numcomp (car c1) (car c2))
- (funcall
- stringcomp
- (if (stringp (car c1))
- (car c1)
- (format "%s" (car c1)))
- (if (stringp (car c2))
- (car c2)
- (format "%s" (car c2))))))))))))
+ (let ((cache (vtable--cache table)))
+ (cl-callf sort (car cache)
+ :key (lambda (e) (elt e (1+ index)))
+ :reverse (eq direction 'descend)))))
Next, I want to argue vtable should not support a custom comparison aka
lessp function but rather a custom sort key function. With value< as
comparison, one can achieve pretty much any effect by choosing the right
sorting key. Note also sorting with a custom, expensive key is more
efficient than sorting with the corresponding custom, expensive lessp
function, since the key function only needs to be evaluated only once
per item in the list.
Finally, the key function (or lessp function, for that matter) has to
take as input the table object and not the column value (the return
value of the :getter). The latter is not general enough; for instance I
wouldn't be able to implement what I want in Minimail with the current
approach (except by using the usual hack of sneaking the sort key as a
string property in the :getter function and fetching the string property
when sorting.)
On Mon, 22 Dec 2025 at 16:53, Stéphane Marks <shipmints <at> gmail.com> wrote:
> This fix allows vtable columns with complex raw values to be sorted according to the
> caller's needs where before it would have been converted to a string and sorted lexically.
> It can also be used to ignore case for strings, for example.
>
> There was some discussion about using the new sort function keyword interface. It may
> be possible to dynamically construct :key and :lessp functions from the table's sort-by
> criteria that covers multi-key, multi-directional, and custom lessp sorting. This is
> something we can tackle later on.
>
> There was a suggestion to call the comparator slot lessp rather than comparator and
> that's what I've done.
>
> -Stéphane
>
> [4. text/x-patch; 0001-Add-vtable-column-lessp-sorting-comparator.patch]...
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#80056; Package
emacs.
(Tue, 23 Dec 2025 11:33:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 80056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Dec 23, 2025 at 5:18 AM Augusto Stoffel <arstoffel <at> gmail.com> wrote:
> Hi Stéphane,
>
> thanks again for taking up this topic, as there's much to be improved in
> vtable in this area.
>
> I'd suggest starting with the most fundamental part, namely migrating
> from the old sort API + handcrafted comparison function to using the new
> sort API + value< as comparison function.
>
> Note that this is slightly backward incompatible, since the old
> comparison can e.g. compare a string against nil (badly, because it will
> treat nil as "nil" instead of "", which would be more reasonable). But
> that's kind of minor and a backwards incompatibility we should go
> through with. Note that the current comparison function can error out
> anyway if a column contains a mix of string and numbers or a mix or
> numbers and nils.
>
> Also, if there is an error in sorting, we should just skip sorting by
> that column (and possibly display a warning message) instead of failing
> to display the table. So the aforementioned backwards incompatibility
> becomes completely innocuous.
>
I think given vtable's youth, that could be an acceptable minor
incompatibility (and there are more serious bugs that I need to abstract
into smaller patches).
The fallback for people who need/want mixed types in a single column would
be to normalize their values in that column's sort-key function? One
common case that might bite people is a mix of integers and floats in the
same column as value< is not forgiving here and will signal an error. If
anyone mixes strings and symbols, same thing, we'd give up automatic
coercion to strings.
It won't perform any worse than what we have now, but the burden moves from
the sort implementation to the developer to normalize to strings as the
general fallback.
I know this incompatibility would not affect my vtable use, and I think the
code I've seen in the wild would be unaffected as I think column types are
uniform.
In terms of code, what I'm saying should boil down to (although I
> haven't tested):
>
> modified lisp/emacs-lisp/vtable.el
> @@ -654,28 +654,10 @@ vtable--clear-cache
>
> (defun vtable--sort (table)
> (pcase-dolist (`(,index . ,direction) (vtable-sort-by table))
> - (let ((cache (vtable--cache table))
> - (numerical (vtable-column--numerical
> - (elt (vtable-columns table) index)))
> - (numcomp (if (eq direction 'descend)
> - #'> #'<))
> - (stringcomp (if (eq direction 'descend)
> - #'string> #'string<)))
> - (setcar cache
> - (sort (car cache)
> - (lambda (e1 e2)
> - (let ((c1 (elt e1 (1+ index)))
> - (c2 (elt e2 (1+ index))))
> - (if numerical
> - (funcall numcomp (car c1) (car c2))
> - (funcall
> - stringcomp
> - (if (stringp (car c1))
> - (car c1)
> - (format "%s" (car c1)))
> - (if (stringp (car c2))
> - (car c2)
> - (format "%s" (car c2))))))))))))
> + (let ((cache (vtable--cache table)))
> + (cl-callf sort (car cache)
> + :key (lambda (e) (elt e (1+ index)))
> + :reverse (eq direction 'descend)))))
>
I agree that if we want to go the sort-key route vs. a sort-lessp route,
now's the time.
> Next, I want to argue vtable should not support a custom comparison aka
> lessp function but rather a custom sort key function. With value< as
> comparison, one can achieve pretty much any effect by choosing the right
> sorting key. Note also sorting with a custom, expensive key is more
> efficient than sorting with the corresponding custom, expensive lessp
> function, since the key function only needs to be evaluated only once
> per item in the list.
>
> Finally, the key function (or lessp function, for that matter) has to
> take as input the table object and not the column value (the return
> value of the :getter). The latter is not general enough; for instance I
> wouldn't be able to implement what I want in Minimail with the current
> approach (except by using the usual hack of sneaking the sort key as a
> string property in the :getter function and fetching the string property
> when sorting.)
>
I did toy with the idea of creating a compound key and sorting the table
only once using that key vs. sorting once per column. This would work only
if all column sort directions are the same, resorting to simple keys and
multiple sort calls otherwise. Would that help your use case?
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#80056; Package
emacs.
(Tue, 23 Dec 2025 11:48:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 80056 <at> debbugs.gnu.org (full text, mbox):
On Tue, 23 Dec 2025 at 06:32, Stéphane Marks <shipmints <at> gmail.com> wrote:
> On Tue, Dec 23, 2025 at 5:18 AM Augusto Stoffel <arstoffel <at> gmail.com> wrote:
>
> Hi Stéphane,
>
> thanks again for taking up this topic, as there's much to be improved in
> vtable in this area.
>
> I'd suggest starting with the most fundamental part, namely migrating
> from the old sort API + handcrafted comparison function to using the new
> sort API + value< as comparison function.
>
> Note that this is slightly backward incompatible, since the old
> comparison can e.g. compare a string against nil (badly, because it will
> treat nil as "nil" instead of "", which would be more reasonable). But
> that's kind of minor and a backwards incompatibility we should go
> through with. Note that the current comparison function can error out
> anyway if a column contains a mix of string and numbers or a mix or
> numbers and nils.
>
> Also, if there is an error in sorting, we should just skip sorting by
> that column (and possibly display a warning message) instead of failing
> to display the table. So the aforementioned backwards incompatibility
> becomes completely innocuous.
>
> I think given vtable's youth, that could be an acceptable minor incompatibility (and there
> are more serious bugs that I need to abstract into smaller patches).
Alright!
> The fallback for people who need/want mixed types in a single column would be to
> normalize their values in that column's sort-key function? One common case that might
> bite people is a mix of integers and floats in the same column as value< is not forgiving
> here and will signal an error.
This works fine for me: (value< 0.5 1) ==> t
> f anyone mixes strings and symbols, same thing, we'd give up automatic
> coercion to strings.
Okay, then the user would have to call symbol-name either in the :getter
or sort key function.
> It won't perform any worse than what we have now, but the burden moves from the sort
> implementation to the developer to normalize to strings as the general fallback.
>
> I know this incompatibility would not affect my vtable use, and I think the code I've seen
> in the wild would be unaffected as I think column types are uniform.
The only real problem I anticipate are columns of a fixed type but with
the occasional nil entry.
(BTW, I was going to say value< could support comparing strings and
symbols, but regarding nil as "nil" makes no sense, as I already claimed
above. So I think there's not much to do here except forcing the
library user to be consistent.)
> In terms of code, what I'm saying should boil down to (although I
> haven't tested):
>
> modified lisp/emacs-lisp/vtable.el
> @@ -654,28 +654,10 @@ vtable--clear-cache
>
> (defun vtable--sort (table)
> (pcase-dolist (`(,index . ,direction) (vtable-sort-by table))
> - (let ((cache (vtable--cache table))
> - (numerical (vtable-column--numerical
> - (elt (vtable-columns table) index)))
> - (numcomp (if (eq direction 'descend)
> - #'> #'<))
> - (stringcomp (if (eq direction 'descend)
> - #'string> #'string<)))
> - (setcar cache
> - (sort (car cache)
> - (lambda (e1 e2)
> - (let ((c1 (elt e1 (1+ index)))
> - (c2 (elt e2 (1+ index))))
> - (if numerical
> - (funcall numcomp (car c1) (car c2))
> - (funcall
> - stringcomp
> - (if (stringp (car c1))
> - (car c1)
> - (format "%s" (car c1)))
> - (if (stringp (car c2))
> - (car c2)
> - (format "%s" (car c2))))))))))))
> + (let ((cache (vtable--cache table)))
> + (cl-callf sort (car cache)
> + :key (lambda (e) (elt e (1+ index)))
> + :reverse (eq direction 'descend)))))
>
> I agree that if we want to go the sort-key route vs. a sort-lessp route, now's the time.
Good. With one more remark: nothing precludes us from adding sort-lessp
in the future if someone comes up with a really compelling case, but I'd
suggest not doing that unless really needed.
> Next, I want to argue vtable should not support a custom comparison aka
> lessp function but rather a custom sort key function. With value< as
> comparison, one can achieve pretty much any effect by choosing the right
> sorting key. Note also sorting with a custom, expensive key is more
> efficient than sorting with the corresponding custom, expensive lessp
> function, since the key function only needs to be evaluated only once
> per item in the list.
>
> Finally, the key function (or lessp function, for that matter) has to
> take as input the table object and not the column value (the return
> value of the :getter). The latter is not general enough; for instance I
> wouldn't be able to implement what I want in Minimail with the current
> approach (except by using the usual hack of sneaking the sort key as a
> string property in the :getter function and fetching the string property
> when sorting.)
>
> I did toy with the idea of creating a compound key and sorting the table only once using
> that key vs. sorting once per column. This would work only if all column sort directions
> are the same, resorting to simple keys and multiple sort calls otherwise. Would that help
> your use case?
I thought about that too, but as you point out it doesn't work with
mixed directions. So I wouldn't even attempt to pursue this
optimization. At least now one can sort the cached entries in place
with the new API, which together with the performance benefits of a sort
key and a non-consing comparison function should already improve the
situation a lot.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#80056; Package
emacs.
(Tue, 23 Dec 2025 12:08:01 GMT)
Full text and
rfc822 format available.
Message #17 received at 80056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Dec 23, 2025 at 6:47 AM Augusto Stoffel <arstoffel <at> gmail.com> wrote:
> On Tue, 23 Dec 2025 at 06:32, Stéphane Marks <shipmints <at> gmail.com> wrote:
>
> > On Tue, Dec 23, 2025 at 5:18 AM Augusto Stoffel <arstoffel <at> gmail.com>
> wrote:
> >
> > Hi Stéphane,
> >
> > thanks again for taking up this topic, as there's much to be improved in
> > vtable in this area.
> >
> > I'd suggest starting with the most fundamental part, namely migrating
> > from the old sort API + handcrafted comparison function to using the new
> > sort API + value< as comparison function.
> >
> > Note that this is slightly backward incompatible, since the old
> > comparison can e.g. compare a string against nil (badly, because it will
> > treat nil as "nil" instead of "", which would be more reasonable). But
> > that's kind of minor and a backwards incompatibility we should go
> > through with. Note that the current comparison function can error out
> > anyway if a column contains a mix of string and numbers or a mix or
> > numbers and nils.
> >
> > Also, if there is an error in sorting, we should just skip sorting by
> > that column (and possibly display a warning message) instead of failing
> > to display the table. So the aforementioned backwards incompatibility
> > becomes completely innocuous.
> >
> > I think given vtable's youth, that could be an acceptable minor
> incompatibility (and there
> > are more serious bugs that I need to abstract into smaller patches).
>
> Alright!
>
> > The fallback for people who need/want mixed types in a single column
> would be to
> > normalize their values in that column's sort-key function? One common
> case that might
> > bite people is a mix of integers and floats in the same column as value<
> is not forgiving
> > here and will signal an error.
>
> This works fine for me: (value< 0.5 1) ==> t
>
> > f anyone mixes strings and symbols, same thing, we'd give up automatic
> > coercion to strings.
>
> Okay, then the user would have to call symbol-name either in the :getter
> or sort key function.
>
> > It won't perform any worse than what we have now, but the burden moves
> from the sort
> > implementation to the developer to normalize to strings as the general
> fallback.
> >
> > I know this incompatibility would not affect my vtable use, and I think
> the code I've seen
> > in the wild would be unaffected as I think column types are uniform.
>
> The only real problem I anticipate are columns of a fixed type but with
> the occasional nil entry.
>
It's a documentation issue for sure and likely to be an annoyance.
We could lobby to have value_cmp consult an option to treat nil as not
equal. Something like this for each type:
case_Lisp_Int:
{
EMACS_INT ia = XFIXNUM (a);
if (NILP (b)) /* <===== Add this test optionally? */
return 1;
if (FIXNUMP (b))
return ia < XFIXNUM (b) ? -1 : 1; /* we know that a != b */
if (FLOATP (b))
return ia < XFLOAT_DATA (b) ? -1 : ia > XFLOAT_DATA (b);
if (BIGNUMP (b))
return -mpz_sgn (*xbignum_val (b));
}
goto type_mismatch;
Based on the code snippet, I misspoke about mixed ints and floats which
will work fine.
> (BTW, I was going to say value< could support comparing strings and
> symbols, but regarding nil as "nil" makes no sense, as I already claimed
> above. So I think there's not much to do here except forcing the
> library user to be consistent.)
>
> > In terms of code, what I'm saying should boil down to (although I
> > haven't tested):
> >
> > modified lisp/emacs-lisp/vtable.el
> > @@ -654,28 +654,10 @@ vtable--clear-cache
> >
> > (defun vtable--sort (table)
> > (pcase-dolist (`(,index . ,direction) (vtable-sort-by table))
> > - (let ((cache (vtable--cache table))
> > - (numerical (vtable-column--numerical
> > - (elt (vtable-columns table) index)))
> > - (numcomp (if (eq direction 'descend)
> > - #'> #'<))
> > - (stringcomp (if (eq direction 'descend)
> > - #'string> #'string<)))
> > - (setcar cache
> > - (sort (car cache)
> > - (lambda (e1 e2)
> > - (let ((c1 (elt e1 (1+ index)))
> > - (c2 (elt e2 (1+ index))))
> > - (if numerical
> > - (funcall numcomp (car c1) (car c2))
> > - (funcall
> > - stringcomp
> > - (if (stringp (car c1))
> > - (car c1)
> > - (format "%s" (car c1)))
> > - (if (stringp (car c2))
> > - (car c2)
> > - (format "%s" (car c2))))))))))))
> > + (let ((cache (vtable--cache table)))
> > + (cl-callf sort (car cache)
> > + :key (lambda (e) (elt e (1+ index)))
> > + :reverse (eq direction 'descend)))))
> >
> > I agree that if we want to go the sort-key route vs. a sort-lessp route,
> now's the time.
>
> Good. With one more remark: nothing precludes us from adding sort-lessp
> in the future if someone comes up with a really compelling case, but I'd
> suggest not doing that unless really needed.
>
> > Next, I want to argue vtable should not support a custom comparison aka
> > lessp function but rather a custom sort key function. With value< as
> > comparison, one can achieve pretty much any effect by choosing the right
> > sorting key. Note also sorting with a custom, expensive key is more
> > efficient than sorting with the corresponding custom, expensive lessp
> > function, since the key function only needs to be evaluated only once
> > per item in the list.
> >
> > Finally, the key function (or lessp function, for that matter) has to
> > take as input the table object and not the column value (the return
> > value of the :getter). The latter is not general enough; for instance I
> > wouldn't be able to implement what I want in Minimail with the current
> > approach (except by using the usual hack of sneaking the sort key as a
> > string property in the :getter function and fetching the string property
> > when sorting.)
> >
> > I did toy with the idea of creating a compound key and sorting the table
> only once using
> > that key vs. sorting once per column. This would work only if all
> column sort directions
> > are the same, resorting to simple keys and multiple sort calls
> otherwise. Would that help
> > your use case?
>
> I thought about that too, but as you point out it doesn't work with
> mixed directions. So I wouldn't even attempt to pursue this
> optimization. At least now one can sort the cached entries in place
> with the new API, which together with the performance benefits of a sort
> key and a non-consing comparison function should already improve the
> situation a lot.
>
Let's see what other people think.
-Stéphane
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#80056; Package
emacs.
(Tue, 23 Dec 2025 12:39:02 GMT)
Full text and
rfc822 format available.
Message #20 received at 80056 <at> debbugs.gnu.org (full text, mbox):
> Cc: Spencer Baugh <sbaugh <at> janestreet.com>,
> Kristoffer Balintona <krisbalintona <at> gmail.com>,
> Joost Kremers <joostkremers <at> fastmail.fm>, ijqq <at> protonmail.com,
> Visuwesh <visuweshm <at> gmail.com>, Adam Porter <adam <at> alphapapa.net>,
> Lars Ingebrigtsen <larsi <at> gnus.org>, Augusto Stoffel <arstoffel <at> gmail.com>
> From: Stéphane Marks <shipmints <at> gmail.com>
> Date: Mon, 22 Dec 2025 16:53:20 -0500
>
> This fix allows vtable columns with complex raw values to be sorted according to the caller's needs where
> before it would have been converted to a string and sorted lexically. It can also be used to ignore case for
> strings, for example.
Thanks.
> +@item lessp
> +If present, this function is called to sort this column's values. It a
^^
"It's"
> +two-argument equivalent of the less-than function @code{<}, and is
> +called with the raw values of two columns to compare. It should return
> +t if the first argument's value should sort before the second. This is
^
@code{t}
> +@defun column-lessp value1 value2
> +@var{value1} and @var{value2} are raw values.
> +@end defun
THis is not needed, and is actually harmful, as it will add 'lessp' to
the function index.
> (defun vtable--sort (table cache)
> + "Sort the TABLE CACHE (not its objects).
I would suggest
Sort the TABLE's CACHE (not its objects).
> + (cond
> + (lessp-func
^^^^^^^^^^^
Shouldn't this be
(functionp (lessp-func))
?
Finally, should this enhancement be called out in NEWS?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#80056; Package
emacs.
(Tue, 23 Dec 2025 12:42:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 80056 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Tue, Dec 23, 2025 at 7:38 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> > Cc: Spencer Baugh <sbaugh <at> janestreet.com>,
> > Kristoffer Balintona <krisbalintona <at> gmail.com>,
> > Joost Kremers <joostkremers <at> fastmail.fm>, ijqq <at> protonmail.com,
> > Visuwesh <visuweshm <at> gmail.com>, Adam Porter <adam <at> alphapapa.net>,
> > Lars Ingebrigtsen <larsi <at> gnus.org>, Augusto Stoffel <
> arstoffel <at> gmail.com>
> > From: Stéphane Marks <shipmints <at> gmail.com>
> > Date: Mon, 22 Dec 2025 16:53:20 -0500
> >
> > This fix allows vtable columns with complex raw values to be sorted
> according to the caller's needs where
> > before it would have been converted to a string and sorted lexically.
> It can also be used to ignore case for
> > strings, for example.
>
> Thanks.
>
> > +@item lessp
> > +If present, this function is called to sort this column's values. It a
> ^^
> "It's"
>
> > +two-argument equivalent of the less-than function @code{<}, and is
> > +called with the raw values of two columns to compare. It should return
> > +t if the first argument's value should sort before the second. This is
> ^
> @code{t}
>
> > +@defun column-lessp value1 value2
> > +@var{value1} and @var{value2} are raw values.
> > +@end defun
>
> THis is not needed, and is actually harmful, as it will add 'lessp' to
> the function index.
>
> > (defun vtable--sort (table cache)
> > + "Sort the TABLE CACHE (not its objects).
>
> I would suggest
>
> Sort the TABLE's CACHE (not its objects).
>
> > + (cond
> > + (lessp-func
> ^^^^^^^^^^^
> Shouldn't this be
>
> (functionp (lessp-func))
>
> ?
>
> Finally, should this enhancement be called out in NEWS?
>
Once we agree on the approach, the above recommendations absolutely.
I knew Augusto would chime in so let's see how this goes. Please react to
the rest of the thread if you have a view.
[Message part 2 (text/html, inline)]
This bug report was last modified 2 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.