GNU bug report logs - #78834
Feature request: make keymapp dereference symbol value slot

Previous Next

To reply to this bug, email your comments to 78834 AT debbugs.gnu.org.

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

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

From: arthur miller <arthur.miller <at> live.com>
To: "bug-gnu-emacs <at> gnu.org" <bug-gnu-emacs <at> gnu.org>
Subject: Feature request: make keymapp dereference symbol value slot
Date: Wed, 18 Jun 2025 22:33:24 +0000

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

Currently keymapp returns nil, when passed a symbol if a keymap
object is only in a symbol's value slot, but not fbound:

(keymapp emacs-lisp-mode-map) => t
(keymapp 'emacs-lisp-mode-map) => nil

(boundp 'emacs-lisp-mode-map) => t
(fboundp 'emacs-lisp-mode-map) => nil

Keymapp uses internally get_keymap to check if an object is a keymap,
and get_keymap does not check value slot of symbols. However, the
comment above says:

"Check that OBJECT is a keymap (after dereferencing through any
   symbols).  If it is, return it."

Now, I don't know why is it the case, why the value slot is not
derefenced. I guess it is by design; after all this time this function
is in existence, that must be known. I don't understand the reason
though, by just looking at it at the moment, so I do wonder why is it
so?

Anyway, that leaves me in a bit awkward situation where I can ask a
question: (keymapp some-symbol) and get two different answers:

(keymapp 'emacs-lisp-mode-map) => nil
(keymapp 'vc-mode-map) => t

because one is fbound and the other is not. The background for this is
that I want to collect all loaded keymaps in the system:

(defun collect-keymaps ()
  (cl-loop for k being the symbol when (keymapp k) collect k))

But I don't get them all, since keymapp won't recognize those that are
not fbound. That makes the whole thing quite less effective, since I
have to additionally check if a symbol is bound and if its symbol value
is a keymap.

As a suggestion, the attached patch dereferences symbol value slots as
well. If it is not a wrong thing to do for some reason I am not aware
of, I would like to suggest it as a "fix" or a "feature request",
whichever is best describing the issue.

[Message part 2 (text/html, inline)]

[0001-Make-get_keymap-dereference-symbol-value-slot.patch (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: arthur miller <arthur.miller <at> live.com>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 78834 <at> debbugs.gnu.org
Subject: Re: bug#78834: Feature request: make keymapp dereference symbol value
 slot
Date: Thu, 19 Jun 2025 09:15:49 +0300

> From: arthur miller <arthur.miller <at> live.com>
> Date: Wed, 18 Jun 2025 22:33:24 +0000
> 
> Currently keymapp returns nil, when passed a symbol if a keymap 
> object is only in a symbol's value slot, but not fbound:
> 
> (keymapp emacs-lisp-mode-map) => t
> (keymapp 'emacs-lisp-mode-map) => nil
> 
> (boundp 'emacs-lisp-mode-map) => t
> (fboundp 'emacs-lisp-mode-map) => nil
> 
> Keymapp uses internally get_keymap to check if an object is a keymap,
> and get_keymap does not check value slot of symbols. However, the
> comment above says:
> 
> "Check that OBJECT is a keymap (after dereferencing through any
>    symbols).  If it is, return it."
> 
> Now, I don't know why is it the case, why the value slot is not
> derefenced. I guess it is by design; after all this time this function
> is in existence, that must be known. I don't understand the reason
> though, by just looking at it at the moment, so I do wonder why is it
> so?
> 
> Anyway, that leaves me in a bit awkward situation where I can ask a
> question: (keymapp some-symbol) and get two different answers:
> 
> (keymapp 'emacs-lisp-mode-map) => nil
> (keymapp 'vc-mode-map) => t
> 
> because one is fbound and the other is not. The background for this is
> that I want to collect all loaded keymaps in the system:
> 
> (defun collect-keymaps ()
>   (cl-loop for k being the symbol when (keymapp k) collect k))
> 
> But I don't get them all, since keymapp won't recognize those that are
> not fbound. That makes the whole thing quite less effective, since I
> have to additionally check if a symbol is bound and if its symbol value
> is a keymap.
> 
> As a suggestion, the attached patch dereferences symbol value slots as
> well. If it is not a wrong thing to do for some reason I am not aware
> of, I would like to suggest it as a "fix" or a "feature request",
> whichever is best describing the issue.
> 
> From c29c8acc75cbd596fe42f5c262fd7d0e8285e87c Mon Sep 17 00:00:00 2001
> From: Arthur Miller <arthur.miller <at> live.com>
> Date: Thu, 19 Jun 2025 00:02:59 +0200
> Subject: [PATCH] Make get_keymap dereference symbol-value slot
> 
> * src/keymap.c (get_keymap):
> Dereference symbol slot and check for a valid keymap.
> ---
>  src/keymap.c | 10 +++++++++-
>  1 file changed, 9 insertions(+), 1 deletion(-)
> 
> diff --git a/src/keymap.c b/src/keymap.c
> index 2c250578b00..3a1b68a2113 100644
> --- a/src/keymap.c
> +++ b/src/keymap.c
> @@ -197,7 +197,15 @@ get_keymap (Lisp_Object object, bool error_if_not_keymap, bool autoload)
>    if (CONSP (object) && EQ (XCAR (object), Qkeymap))
>      return object;
>  
> -  Lisp_Object tem = indirect_function (object);
> +  Lisp_Object tem;
> +  if (SYMBOLP (object))
> +    {
> +      tem = find_symbol_value (object);
> +      if (CONSP (tem) && EQ (XCAR (tem), Qkeymap))
> +	return tem;
> +    }
> +
> +  tem = indirect_function (object);
>    if (CONSP (tem))
>      {
>        if (EQ (XCAR (tem), Qkeymap))
> -- 
> 2.50.0

Stefan, any comments?

FWIW, the ELisp manual says explicitly:

   -- Function: keymapp object
       This function returns ‘t’ if OBJECT is a keymap, ‘nil’ otherwise.
       More precisely, this function tests for a list whose CAR is
       ‘keymap’, or for a symbol whose function definition satisfies
       ‘keymapp’.

So, unless I'm missing something, the current behavior seems to match
the documentation?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: arthur miller <arthur.miller <at> live.com>
Cc: 78834 <at> debbugs.gnu.org
Subject: Re: bug#78834: Feature request: make keymapp dereference symbol
 value slot
Date: Thu, 19 Jun 2025 11:18:47 -0400

> because one is fbound and the other is not. The background for this is
> that I want to collect all loaded keymaps in the system:
>
> (defun collect-keymaps ()
>   (cl-loop for k being the symbol when (keymapp k) collect k))

The fix here is to always check the `(symbol-value k)` never `k`.
IOW think of it "I'm looking for all the loaded strings" except that
you're looking for keymaps instead of strings.  You wouldn't do
`(stringp k)` but `(stringp (symbol-value k))`, right?

It is rue that keymaps (contrary to strings) can *also* be represented
by symbols (where it works much like it does for functions).  I don't
know why this was done, but I consider as an historical accident and
don't recommend making use of that "feature".

It's mostly used in very old code that uses the weird
`define-prefix-command` function, such as the code that sets up some of
the "core" keymaps like `ctl-x-5-prefix` `ESC-prefix` `ctl-x-4-prefix`,
`Control-X-prefix`.

> As a suggestion, the attached patch dereferences symbol value slots
> as well.

It's simpler to fix *your* code rather than the rest of the world's.  🙂

> If it is not a wrong thing to do for some reason I am not aware
> of, I would like to suggest it as a "fix" or a "feature request",
> whichever is best describing the issue.

It would break existing uses when the symbol has both
a `symbol-function` value and a `symbol-value` value.  We could consider
adding it as a fallback (i.e. use the `symbol-value` slot only *after*
checking the `symbol-function` slot), but that would be
a somewhat weird/unreliable feature, so we'd need a compelling use-case
(the only advantage I can see of using `symbol-value` over
`symbol-function` is that it can be made buffer-local, so you could
e.g. make a keymap whose parent changes dynamically depending on the
current-buffer, but I don't know what would be the corresponding
"compelling use-case").


        Stefan

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

From: arthur miller <arthur.miller <at> live.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "78834 <at> debbugs.gnu.org" <78834 <at> debbugs.gnu.org>
Subject: Sv: bug#78834: Feature request: make keymapp dereference symbol value
 slot
Date: Thu, 19 Jun 2025 21:52:48 +0000

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

> > because one is fbound and the other is not. The background for this is
> > that I want to collect all loaded keymaps in the system:
> >
> > (defun collect-keymaps ()
> >   (cl-loop for k being the symbol when (keymapp k) collect k))
>
> The fix here is to always check the `(symbol-value k)` never `k`.
> IOW think of it "I'm looking for all the loaded strings" except that
> you're looking for keymaps instead of strings.

I realized that and was doing something similar, admittedly less
effeciently because I didn't know I can trust that all keymaps have the
value slot set. I thought, that some had function slot set, and other
value slot, and some both.

I was wondering why it was done this way, that keymap is stored into the
function slot, but I assumed it was some optimization
somewhere. Secondly, I was also in doubt since keymamp does the special
thing and accepts the symbol for fbounded ones. I thought there must be
some reason why it was done that way, and wondered why dereferencing
symbol was done only for fbounded symbols. I assumed that some keymaps
don't have value slot set.

> you're looking for keymaps instead of strings.  You wouldn't do
> `(stringp k)` but `(stringp (symbol-value k))`, right?

Or with bufferp, or some other "typep". Most (all?) work on objects and
not on symbols. I am aware of that one. But as explained above, I was
not sure what really to expect in the case of keymapp.

> It is rue that keymaps (contrary to strings) can *also* be represented
> by symbols (where it works much like it does for functions).  I don't
> know why this was done, but I consider as an historical accident and
> don't recommend making use of that "feature".

No, no, I am not trying to make use of it all; on the contrary :-). I
just wanted to find *all* prefix keys in all maps, and was a bit
confused why some maps where not found when I knew they should be.

> It's mostly used in very old code that uses the weird
> `define-prefix-command` function, such as the code that sets up some of
> the "core" keymaps like `ctl-x-5-prefix` `ESC-prefix` `ctl-x-4-prefix`,
> `Control-X-prefix`.

I was actually wondering why this was done, if it is just an
optimization or if there is some other reason? I am just curious, I
don't really understand the idea behind. It would be interesting to
learn, if somebody knows and is willing to explain, since it is atypical
to store value data in function slot.

> > As a suggestion, the attached patch dereferences symbol value slots
> > as well.
>
> It's simpler to fix *your* code rather than the rest of the world's.  🙂

Yeah, I understand that :).

Partially, as said above, I didn't know I can rely that *all* keymaps
have value slot set, and tbh I didn't know I can skipp the boundp
check. The code I used actually looked like this:

(defun collect-keymaps ()
  "Collect all keymaps in the system"
  (let (keymaps)
    (mapatoms
     (lambda (s)
       (if (keymapp s)
           (push s keymaps)
         (and (boundp s) (keymapp (symbol-value s))
              (push s keymaps)))))
    keymaps))

which is quite bad and innefficient. I see now I can do:

(defun xcv-collect-keymaps ()
  (cl-loop for s being the symbol when (keymapp (symbol-value s)) collect s))

When I check the length of the result list, it seems to find all maps.

> > If it is not a wrong thing to do for some reason I am not aware
> > of, I would like to suggest it as a "fix" or a "feature request",
> > whichever is best describing the issue.
>
> It would break existing uses when the symbol has both
> a `symbol-function` value and a `symbol-value` value.  We could consider

I saw the other functions using get_keymap, so I wasn't sure if they
would complain or not. I have run Emacs today, the entire day, with that
patch, I haven't noticed anything weird. But I am not an advanced
user. I probably don't hit any functions that might touch that
functionality and I don't have any tests neither.

Not pushing for it, more as a curiosa: what do you think about not
touching get_keymap at all, and refactoring out keymmapp like this:

DEFUN ("keymapp", Fkeymapp, Skeymapp, 1, 1, 0,
  (Lisp_Object object)
{
  if (NILP (object))
    return Qnil;
  if (CONSP (object) && EQ (XCAR (object), Qkeymap))
    return object;

  if (SYMBOLP (object))
    {
      Lisp_Object tem = indirect_function (object);
      if (CONSP (tem) && EQ (XCAR (tem), Qkeymap))
      return tem;

      tem = find_symbol_value (object);
      if (CONSP (tem) && EQ (XCAR (tem), Qkeymap))
      return tem;
    }

  return Qnil;
}

I don't see any use of Fkeymapp from C code, but it is used quite a lot
in Lisp code. I do run that keymapp version now in my Emacs when I write
this, but that does not mean it is always right.

> adding it as a fallback (i.e. use the `symbol-value` slot only *after*
> checking the `symbol-function` slot), but that would be
> a somewhat weird/unreliable feature, so we'd need a compelling use-case
> (the only advantage I can see of using `symbol-value` over
> `symbol-function` is that it can be made buffer-local, so you could
> e.g. make a keymap whose parent changes dynamically depending on the
> current-buffer, but I don't know what would be the corresponding
> "compelling use-case").

I am not sure I have a compelling reason. It would be just slightly more
efficient and slightly more elegant to just check for the keymmapp and
not have to take symbol-value, but my biggest motivation for the
suggestion was the confusion when I discovered what was hapening. It
wasn't clear why one symbol worked but other didn't. Now, when I know
that the value slot can always be used, it is not an issue.  I am
affraid that is the best I can come up with. Buffer local keymaps can be
achieved with a buffer-local variable, whose value is switched between
two different keymaps too, but it would be more elegant if they could be
buffer local. I don't see myself a use-case for neither, but what do I
know; someone else might have one.

Thanks for looking at it and for the detailed answer.

best regards
/a

[Message part 2 (text/html, inline)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: arthur miller <arthur.miller <at> live.com>
Cc: "78834 <at> debbugs.gnu.org" <78834 <at> debbugs.gnu.org>
Subject: Re: bug#78834: Feature request: make keymapp dereference symbol
 value slot
Date: Thu, 19 Jun 2025 18:39:05 -0400

> I realized that and was doing something similar, admittedly less
> effeciently because I didn't know I can trust that all keymaps have the
> value slot set.

Your mental model is a bit off.  Keymaps don't have a "value slot".
IOW, your old loop was looking for "symbols that are keymaps" (which is
only those whose function slot contains a keymap), but your new function
looks for "variables which *contain* a keymap".

Most useful/important keymaps are stored in variables, so yes that loop
will find almost all of the keymaps.  Not all, because some keymaps are
produced dynamically or are stored only elsewhere (such as inside one
of the sublists of `minor-mode-map-alist`).

>> It's mostly used in very old code that uses the weird
>> `define-prefix-command` function, such as the code that sets up some of
>> the "core" keymaps like `ctl-x-5-prefix` `ESC-prefix` `ctl-x-4-prefix`,
>> `Control-X-prefix`.
> I was actually wondering why this was done, if it is just an
> optimization or if there is some other reason?  I am just curious, I
> don't really understand the idea behind.

You'd have to ask Richard.  IIUC one of the benefit is that you can
refer (by name) to a keymap before it's defined.  E.g. you can do

    (global-set-key [?\C-z] 'my-z-keymap)

and then have `my-z-keymap` autoloaded from some library the first time
you hit `C-z`.  I can't remember the last time I've seen this used
successfully (I tried to use it a few times, but the keymap always
ended up being "accidentally" autoloaded much too eagerly).

Maybe it was done simply because Richard thought of keymaps as kinds of
commands?

> It would be interesting to learn, if somebody knows and is willing to
> explain, since it is atypical to store value data in function slot.

Indeed.

>> It would break existing uses when the symbol has both
>> a `symbol-function` value and a `symbol-value` value.  We could
>> consider
> I saw the other functions using get_keymap, so I wasn't sure if they
> would complain or not. I have run Emacs today, the entire day, with that
> patch, I haven't noticed anything weird.

I wouldn't expect otherwise.  The affected cases would be corner cases.

> DEFUN ("keymapp", Fkeymapp, Skeymapp, 1, 1, 0,
>   (Lisp_Object object)
> {
>   if (NILP (object))
>     return Qnil;
>   if (CONSP (object) && EQ (XCAR (object), Qkeymap))
>     return object;
>
>   if (SYMBOLP (object))
>     {
>       Lisp_Object tem = indirect_function (object);
>       if (CONSP (tem) && EQ (XCAR (tem), Qkeymap))
>       return tem;
>
>       tem = find_symbol_value (object);
>       if (CONSP (tem) && EQ (XCAR (tem), Qkeymap))
>       return tem;
>     }
>
>   return Qnil;
> }

That would be wrong.  Code can expect that if `keymapp` returns non-nil,
then you do have a keymap and you can use functions like
`set-keymap-parent`, `lookup-key`, `map-keymap`, ... on it.  So if you
change `keymapp` to return non-nil for some symbols, you need to adjust
the other operations as well.


        Stefan

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

From: Daniel Mendler <mail <at> daniel-mendler.de>
To: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
 text editors" <bug-gnu-emacs <at> gnu.org>
Cc: "78834 <at> debbugs.gnu.org" <78834 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 arthur miller <arthur.miller <at> live.com>
Subject: Re: bug#78834: Feature request: make keymapp dereference symbol
 value slot
Date: Fri, 20 Jun 2025 00:45:35 +0200

Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

>>> It's mostly used in very old code that uses the weird
>>> `define-prefix-command` function, such as the code that sets up some of
>>> the "core" keymaps like `ctl-x-5-prefix` `ESC-prefix` `ctl-x-4-prefix`,
>>> `Control-X-prefix`.
>> I was actually wondering why this was done, if it is just an
>> optimization or if there is some other reason?  I am just curious, I
>> don't really understand the idea behind.
>
> You'd have to ask Richard.  IIUC one of the benefit is that you can
> refer (by name) to a keymap before it's defined.  E.g. you can do
>
>     (global-set-key [?\C-z] 'my-z-keymap)
>
> and then have `my-z-keymap` autoloaded from some library the first time
> you hit `C-z`.  I can't remember the last time I've seen this used
> successfully (I tried to use it a few times, but the keymap always
> ended up being "accidentally" autoloaded much too eagerly).

In a bunch of my packages I use the prefix keymap autoloading
functionality successfully. See for example `cape-prefix-map' or
`osm-prefix-map'. I bind `osm-prefix-map' to `s-m', such that I can
invoke `osm-home' via `s-m h'. I've not observed that osm.el gets loaded
too eagerly.

> Maybe it was done simply because Richard thought of keymaps as kinds of
> commands?

I'd suspect it was done like this because of autoloading.

Daniel

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

From: arthur miller <arthur.miller <at> live.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: "78834 <at> debbugs.gnu.org" <78834 <at> debbugs.gnu.org>
Subject: Sv: bug#78834: Feature request: make keymapp dereference symbol value
 slot
Date: Fri, 20 Jun 2025 00:15:29 +0000

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

> > I realized that and was doing something similar, admittedly less
> > effeciently because I didn't know I can trust that all keymaps have the
> > value slot set.
>
> Your mental model is a bit off.  Keymaps don't have a "value slot".
> IOW, your old loop was looking for "symbols that are keymaps" (which is
> only those whose function slot contains a keymap), but your new function
> looks for "variables which *contain* a keymap".

Aha. Yes it was. I didn't get it that keymaps are *exclusively* symbols
with a keymap in function slot. The doc says it, but since they are also
stored in variables, I was a bit off there.

> Most useful/important keymaps are stored in variables, so yes that loop
> will find almost all of the keymaps.  Not all, because some keymaps are
> produced dynamically or are stored only elsewhere (such as inside one
> of the sublists of `minor-mode-map-alist`).

Yes. I see. Some other defined in keymap.c are also not found.

The function that does the work for me, is processing each keymap
recursively. Maps stored in those lists will hopefully also be defined
elsewhere, otherwise, I will have to iterate those lists as special
cases. I don't see otherwise how to ask for all the keymaps in the
system. Hopefully it is only those alists defined in
keymap.c. Dynamically generated ones are of the reach, unless they are
stored in some parent keymap reachable from a variable in obarray.

> >> It's mostly used in very old code that uses the weird
> >> `define-prefix-command` function, such as the code that sets up some of
> >> the "core" keymaps like `ctl-x-5-prefix` `ESC-prefix` `ctl-x-4-prefix`,
> >> `Control-X-prefix`.
> > I was actually wondering why this was done, if it is just an
> > optimization or if there is some other reason?  I am just curious, I
> > don't really understand the idea behind.
>
> You'd have to ask Richard.  IIUC one of the benefit is that you can
> refer (by name) to a keymap before it's defined.  E.g. you can do
>
>     (global-set-key [?\C-z] 'my-z-keymap)
>
> and then have `my-z-keymap` autoloaded from some library the first time
> you hit `C-z`.  I can't remember the last time I've seen this used
> successfully (I tried to use it a few times, but the keymap always
> ended up being "accidentally" autoloaded much too eagerly).
>
> Maybe it was done simply because Richard thought of keymaps as kinds of
> commands?

It seems so from the docs, but how does it work? Special code that
handles keymaps when evaluation is done? I am not familiar with Emacs
eval and how it handles commands yet.

> > It would be interesting to learn, if somebody knows and is willing to
> > explain, since it is atypical to store value data in function slot.
>
> Indeed.
>
> >> It would break existing uses when the symbol has both
> >> a `symbol-function` value and a `symbol-value` value.  We could
> >> consider
> > I saw the other functions using get_keymap, so I wasn't sure if they
> > would complain or not. I have run Emacs today, the entire day, with that
> > patch, I haven't noticed anything weird.
>
> I wouldn't expect otherwise.  The affected cases would be corner cases.
>
> > DEFUN ("keymapp", Fkeymapp, Skeymapp, 1, 1, 0,
> >   (Lisp_Object object)
> > {
> >   if (NILP (object))
> >     return Qnil;
> >   if (CONSP (object) && EQ (XCAR (object), Qkeymap))
> >     return object;
> >
> >   if (SYMBOLP (object))
> >     {
> >       Lisp_Object tem = indirect_function (object);
> >       if (CONSP (tem) && EQ (XCAR (tem), Qkeymap))
> >       return tem;
> >
> >       tem = find_symbol_value (object);
> >       if (CONSP (tem) && EQ (XCAR (tem), Qkeymap))
> >       return tem;
> >     }
> >
> >   return Qnil;
> > }
>
> That would be wrong.  Code can expect that if `keymapp` returns non-nil,
> then you do have a keymap and you can use functions like
> `set-keymap-parent`, `lookup-key`, `map-keymap`, ... on it.  So if you
> change `keymapp` to return non-nil for some symbols, you need to adjust
> the other operations as well.

Indeed, but they will get a keymap, won't they? Because the object
stored in the symbol slot is a keymap. The only difference is from which
slot the keymap is returned. But, I can imagine some code written to
expect nil in some cases, now does not get nil, and perhaps does a wrong
thing.

Anyway, that is a bit unfortunate, because I just found I still do have
to check if the variable is bound before I take the symbol-function, so
I have to type it like this:

(defun collect-keymaps ()
  (cl-loop for s being the symbols
           when
           (or (keymapp s)
               (and (boundp s) (keymapp (symbol-value s))))
           collect s))

With the above function, I could type:

(defun collect-keymaps ()
  (cl-loop for s being the symbols
           when (keymapp s)
           collect s))

However, the second one with the patch finds one keymap less, 588 vs 587,
in my Emacs :). I guess I'll better go with the old one anyway.

[Message part 2 (text/html, inline)]

Previous Next

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