GNU bug report logs - #35044
25.2; Description of "disappearing" faces (Emacs Manual)

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 35044 in the body.
You can then email your comments to 35044 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: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 25.2; Description of "disappearing" faces (Emacs Manual)
Date: Fri, 29 Mar 2019 20:43:33 +0100

Starting with 'emacs -Q', in text-mode or fundamental-mode, after 'M-x
table-insert' or 'M-x table-recognize', switch to outline-mode and see
table highlight (table-cell face) disappear.  Switch back to text-mode
or fundamental-mode, start 'TABing' (table-forward-cell) inside table
and face will be back cell after cell.

According to help-gnu-emacs thread
(lists.gnu.org/archive/html/help-gnu-emacs/2019-03/msg00205.html) this
is normal behaviour, but from perspective of beginner it looks like
a bug.  Therefore I suggest a sentence or two, perhaps in chapter
"11.12 Font lock mode", about how Font lock takes over control of
faces when user switches to mode with defined font-lock faces leaving
only those from this mode and turning off others (unless they have
also property font-lock-face).

Also the behaviour of reappearing table-cell face after switch back to
fundamental-mode or text-mode seems to be not quite right, shouldn't it
reappear in every cell at once (just like it disappears)?




In GNU Emacs 25.2.1 (i686-w64-mingw32)
 of 2017-04-24 built on LAPHROAIG
Windowing system distributor 'Microsoft Corp.', version 6.1.7601
Configured using:
 'configure --host=i686-w64-mingw32 --without-dbus
 --without-compress-install 'CFLAGS=-static -O2 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB
TOOLKIT_SCROLL_BARS

Important settings:
  value of $LANG: PLK
  locale-coding-system: cp1250

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  buffer-read-only: t
  line-number-mode: t
  transient-mark-mode: t

Recent messages:
Preparing diary...done
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message dired format-spec rfc822 mml
mml-sec password-cache epg gnus-util mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047
rfc2045 ietf-drums mm-util help-fns mail-prsvr mail-utils view cal-china
lunar solar cal-dst cal-bahai cal-islam cal-hebrew holidays hol-loaddefs
diary-lib diary-loaddefs cal-menu calendar cal-loaddefs finder-inf
package epg-config seq byte-opt gv bytecomp byte-compile cl-extra
help-mode easymenu cconv cl-loaddefs pcase cl-lib time-date mule-util
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table w32-win w32-vars term/common-win
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan
thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian
slovak czech european ethiopic indian cyrillic chinese charscript
case-table epa-hook jka-cmpr-hook help simple abbrev minibuffer
cl-preloaded nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote w32notify w32 multi-tty
make-network-process emacs)

Memory information:
((conses 8 115274 13462)
 (symbols 32 22270 0)
 (miscs 32 103 141)
 (strings 16 24031 4760)
 (string-bytes 1 745960)
 (vectors 8 16010)
 (vector-slots 4 486417 6170)
 (floats 8 712 304)
 (intervals 28 290 37)
 (buffers 520 22))

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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#35044: 25.2; Description of "disappearing" faces (Emacs
 Manual)
Date: Tue, 16 Apr 2019 23:33:12 +0200

Hello,

I just would like to know whether it is still alive or was rejected 
or... I'm asking because it was added 18 days ago and I'm just waiting 
for any sign.

S. U.

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

From: "Basil L. Contovounesios" <contovob <at> tcd.ie>
To: Sebastian Urban <mrsebastianurban <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Wed, 17 Apr 2019 13:59:40 +0100

Sebastian Urban <mrsebastianurban <at> gmail.com> writes:

> I just would like to know whether it is still alive or was rejected or... I'm
> asking because it was added 18 days ago and I'm just waiting for any sign.

Here's a number sign: #

Sorry about that terrible joke and the delay in responding to your
report.  The maintainers try to respond to everything within a couple of
weeks or so, but sometimes they get busy and wishlist reports slip
through the cracks.  Nothing gets rejected without express
justification.  If you are interested in helping out with and speeding
up this process, an explicit wording suggestion and/or patch is always
welcome.  A reminder email like the one you just sent every few weeks
also helps with reports not being forgotten about.

Thanks,

-- 
Basil

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Sebastian Urban <mrsebastianurban <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Wed, 17 Apr 2019 20:03:35 +0300

> From: Sebastian Urban <mrsebastianurban <at> gmail.com>
> Date: Tue, 16 Apr 2019 23:33:12 +0200
> 
> I just would like to know whether it is still alive or was rejected 
> or... I'm asking because it was added 18 days ago and I'm just waiting 
> for any sign.

Sorry for not responding earlier.

Regarding your proposal: I'm not convinced saying something like that
deep inside the manual would help.  I very much doubt that a user who
bumped into the issue like you did would look in that section for the
reason.  More likely, they will ask a question, like you did, and get
the answer you did.

But that's me; perhaps others will have other opinions about this.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Sebastian Urban <mrsebastianurban <at> gmail.com>, 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Wed, 17 Apr 2019 18:37:13 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:
> I very much doubt that a user who bumped into the issue like you did
> would look in that section for the reason.  More likely, they will ask
> a question, like you did, and get the answer you did.

Yes, but the existence of a manual page to point at lends the answers
more authority.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: mrsebastianurban <at> gmail.com, 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Thu, 18 Apr 2019 05:34:43 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Cc: Sebastian Urban <mrsebastianurban <at> gmail.com>,  35044 <at> debbugs.gnu.org
> Date: Wed, 17 Apr 2019 18:37:13 -0400
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> > I very much doubt that a user who bumped into the issue like you did
> > would look in that section for the reason.  More likely, they will ask
> > a question, like you did, and get the answer you did.
> 
> Yes, but the existence of a manual page to point at lends the answers
> more authority.

Feel free to add something there, then.

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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: "Basil L. Contovounesios" <contovob <at> tcd.ie>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2; Description of "disappearing" faces (Emacs
 Manual)
Date: Fri, 19 Apr 2019 22:19:52 +0200

Well I think I'll just wait, because writing about it could be above
my beginner level, but perhaps someone could use this hint from
minibuffer "Font-lock mode will override any faces you set in this
buffer" as a template(?).

S. U.

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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2; Description of "disappearing" faces (Emacs
 Manual)
Date: Fri, 19 Apr 2019 22:32:23 +0200

Well first thing I did was to search the manual (Emacs, not Elisp).
Even if they skip the manual, anyone will have easier way to answer
similar questions, by simply pointing to chapter in the manual - it's
easier than searching and linking my thread or writing explanation
again.

S. U.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Sebastian Urban <mrsebastianurban <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Fri, 19 Apr 2019 17:47:55 -0400

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

Sebastian Urban <mrsebastianurban <at> gmail.com> writes:

> According to help-gnu-emacs thread
> (lists.gnu.org/archive/html/help-gnu-emacs/2019-03/msg00205.html) this
> is normal behaviour, but from perspective of beginner it looks like
> a bug.  Therefore I suggest a sentence or two, perhaps in chapter
> "11.12 Font lock mode", about how Font lock takes over control of
> faces when user switches to mode with defined font-lock faces leaving
> only those from this mode and turning off others (unless they have
> also property font-lock-face).

So I've been looking at this, and I think maybe the only manual change
needed is in the Elisp manual to more strongly recommend using
font-lock-face for this sort of thing:

[0001-Recommend-using-font-lock-face-over-face-Bug-35044.patch (text/x-diff, inline)]

From 12148e9d93f885fd6e4e82f485c319486c1e9652 Mon Sep 17 00:00:00 2001
From: Noam Postavsky <npostavs <at> gmail.com>
Date: Fri, 19 Apr 2019 00:55:14 -0400
Subject: [PATCH] Recommend using font-lock-face over face (Bug#35044)

* doc/lispref/modes.texi (Precalculated Fontification): Explain
advantages of using font-lock-face over face.
---
 doc/lispref/modes.texi | 7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/doc/lispref/modes.texi b/doc/lispref/modes.texi
index 919816f3de..0ff13d72e2 100644
--- a/doc/lispref/modes.texi
+++ b/doc/lispref/modes.texi
@@ -3201,7 +3201,12 @@ is disabled, @code{font-lock-face} has no effect on the display.
   It is ok for a mode to use @code{font-lock-face} for some text and
 also use the normal Font Lock machinery.  But if the mode does not use
 the normal Font Lock machinery, it should not set the variable
-@code{font-lock-defaults}.
+@code{font-lock-defaults}.  In this case the @code{face} property will
+not be overriden, so using the @code{face} property could work too.
+However, using @code{font-lock-face} is generally preferable as it
+allows the user to control the fontification by toggling
+@code{font-lock-mode}, and lets the code work regardless of whether
+the mode uses Font Lock machinery or not.
 
 @node Faces for Font Lock
 @subsection Faces for Font Lock
-- 
2.11.0

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

> Also the behaviour of reappearing table-cell face after switch back to
> fundamental-mode or text-mode seems to be not quite right, shouldn't it
> reappear in every cell at once (just like it disappears)?

If I understand correctly, this is rather a bug in table.el: it should
use 'font-lock-face instead of 'face, and then all this buggy behaviour
will go away.  Perhaps you'd like to send a patch?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: mrsebastianurban <at> gmail.com, 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Sat, 20 Apr 2019 09:23:18 +0300

> From: Noam Postavsky <npostavs <at> gmail.com>
> Date: Fri, 19 Apr 2019 17:47:55 -0400
> Cc: 35044 <at> debbugs.gnu.org
> 
> So I've been looking at this, and I think maybe the only manual change
> needed is in the Elisp manual to more strongly recommend using
> font-lock-face for this sort of thing:

LGTM, thanks.

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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2; Description of "disappearing" faces (Emacs
 Manual)
Date: Mon, 22 Apr 2019 22:03:18 +0200

> (...) I think maybe the only manual change needed is in the Elisp
> manual (...)

I would like to remind that the target is someone new to Emacs or as
I wrote before "(...) from perspective of *beginner* (...)".  Now,
which Emacs beginner will look into Elisp manual?  This is why Emacs
Manual, not Elisp, not Elisp introduction etc., needs a simply written
line about it.  Patch for Elisp manual is nice, but for advanced
users.  Maybe something like (11.12(PDF) or 14.12(info) Font Lock mode
- 1st paragraph):

(...)
buffer’s major mode tells Font Lock mode which text to fontify; for
instance, programming language modes fontify syntactically relevant
-constructs like comments, strings, and function names.
+constructs like comments, strings, and function names.  Any faces not
+defined as font-lock-faces or by major mode will be ignored by Font
+Lock mode, i.e. these faces will not be applied.
   Font Lock mode is enabled by default.  To toggle it in the current
(...)

Maybe instead of "Any faces", "Most faces" should be used (I'm
thinking about hardcoded faces for example).

> If I understand correctly, this is rather a bug in table.el: it should
> use 'font-lock-face instead of 'face, and then all this buggy
> behaviour will go away.  Perhaps you'd like to send a patch?

Wouldn't this change ('face -> 'font-lock-face) also kill main problem
of this bug(#35044) - disappearing face?  Of course only for table.
Because if so, in addition to manual update, maybe a code update in
table.el would be nice thing to do - kind of "2 for 1"?

Unfortunately I'm last person who should do code updates right now -
I didn't even finish first 14 chapters of Emacs manual... yet.

S. U.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Sebastian Urban <mrsebastianurban <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Mon, 22 Apr 2019 16:59:23 -0400

Sebastian Urban <mrsebastianurban <at> gmail.com> writes:

> I would like to remind that the target is someone new to Emacs or as
> I wrote before "(...) from perspective of *beginner* (...)".  Now,
> which Emacs beginner will look into Elisp manual?

> buffer’s major mode tells Font Lock mode which text to fontify; for
> instance, programming language modes fontify syntactically relevant
> -constructs like comments, strings, and function names.
> +constructs like comments, strings, and function names.  Any faces not
> +defined as font-lock-faces or by major mode will be ignored by Font
> +Lock mode, i.e. these faces will not be applied.

I'm unclear how this will help a beginner user.  It sounds like
it's describing a potential source of buggy behaviour.  But we don't
want the manual to excuse buggy behaviour, we rather want users to
report bugs.

> Maybe instead of "Any faces", "Most faces" should be used (I'm
> thinking about hardcoded faces for example).

Not sure what you mean by "hardcoded" faces.

>> If I understand correctly, this is rather a bug in table.el: it should
>> use 'font-lock-face instead of 'face, and then all this buggy
>> behaviour will go away.  Perhaps you'd like to send a patch?
>
> Wouldn't this change ('face -> 'font-lock-face) also kill main problem
> of this bug(#35044) - disappearing face?  Of course only for table.

Yes, I think so (that's what I meant by "all").

> Because if so, in addition to manual update, maybe a code update in
> table.el would be nice thing to do - kind of "2 for 1"?
>
> Unfortunately I'm last person who should do code updates right now -
> I didn't even finish first 14 chapters of Emacs manual... yet.

Jump in the deep end!  You'll learn faster that way :)

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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2; Description of "disappearing" faces (Emacs
 Manual)
Date: Thu, 25 Apr 2019 00:01:16 +0200

> I'm unclear how this will help a beginner user.  It sounds like
> it's describing a potential source of buggy behaviour.

Well this is why I didn't want to write it, also it's more like
concept/idea rather than a patch.  Again new users should not be
surprised by this behaviour, so a line of warning would be nice, but
if it sounds like description of bug...  Maybe a footnote "This is not
a bug!" at the end (yes, this is a joke).

> Not sure what you mean by "hardcoded" faces.

Quote (for example) RET character (C-q RET), then do 'describe-char'
on it and you'll get something like "hardcoded face: escape-glyph" in
the description.

---

About that change 'face -> 'font-lock-face in table.el, I would
probably need to report another bug/wishlist thing, am I correct?

S. U.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Sebastian Urban <mrsebastianurban <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Fri, 26 Apr 2019 08:49:41 -0400

Sebastian Urban <mrsebastianurban <at> gmail.com> writes:

>> I'm unclear how this will help a beginner user.  It sounds like
>> it's describing a potential source of buggy behaviour.
>
> Well this is why I didn't want to write it, also it's more like
> concept/idea rather than a patch.  Again new users should not be
> surprised by this behaviour, so a line of warning would be nice, but
> if it sounds like description of bug...  Maybe a footnote "This is not
> a bug!" at the end (yes, this is a joke).

I mean, new users *should* probably be surprised by this behaviour which
is in fact a bug.  And elisp authors (ideally) should not write code
with bugs, hence my suggestion to update the elisp manual to give
stronger advice about how to avoid doing that (for this particular class
of bug).

>> Not sure what you mean by "hardcoded" faces.
>
> Quote (for example) RET character (C-q RET), then do 'describe-char'
> on it and you'll get something like "hardcoded face: escape-glyph" in
> the description.

I wasn't aware of this, looks like "hardcoded" refers to faces applied
directly by the display engine to particular characters.

> ---
>
> About that change 'face -> 'font-lock-face in table.el, I would
> probably need to report another bug/wishlist thing, am I correct?

Yeah, it would be neater to have a separate report.  Though you can just
send it in this same thread if you like.

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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2; Description of "disappearing" faces (Emacs
 Manual)
Date: Sat, 27 Apr 2019 17:55:55 +0200

To sum things up, approach for this bug won't be updating "Emacs
manual", because it could end up as an excuse for bug(s), but rather:

1. updating "Elisp manual" with advice to use 'font-lock-face' over
   'face' (which you already did with patch) - dev pov,

2. updating "table.el" to use 'font-lock-face' instead 'face' - user
   pov.

But won't it (especially point 2.) start a "face hunt", because there
may be other functions/modes that have the same problem - using 'face'
when they should use 'font-lock-face'... or should I just don't care
until it happen?

S. U.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Sebastian Urban <mrsebastianurban <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Sat, 27 Apr 2019 17:20:58 -0400

Sebastian Urban <mrsebastianurban <at> gmail.com> writes:

> To sum things up, approach for this bug won't be updating "Emacs
> manual", because it could end up as an excuse for bug(s), but rather:
>
> 1. updating "Elisp manual" with advice to use 'font-lock-face' over
>    'face' (which you already did with patch) - dev pov,
>
> 2. updating "table.el" to use 'font-lock-face' instead 'face' - user
>    pov.

Yes.

> But won't it (especially point 2.) start a "face hunt", because there
> may be other functions/modes that have the same problem - using 'face'
> when they should use 'font-lock-face'... or should I just don't care
> until it happen?

Yes, it's quite possible that other functions/modes have the same
problem.  But there's no need to specifically hunt them down (unless you
want to).

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

From: Sebastian Urban <mrsebastianurban <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2; Description of "disappearing" faces (Emacs
 Manual)
Date: Sun, 28 Apr 2019 23:17:28 +0200

Ok, so from my point of view this bug can be closed, with your patch
as part (first point) of solution.  As for second point I'll make new
bug report about need of update for "table.el".

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Sebastian Urban <mrsebastianurban <at> gmail.com>
Cc: 35044 <at> debbugs.gnu.org
Subject: Re: bug#35044: 25.2;
 Description of "disappearing" faces (Emacs Manual)
Date: Sun, 28 Apr 2019 17:22:31 -0400

close 35044 26.3
quit

Sebastian Urban <mrsebastianurban <at> gmail.com> writes:

> Ok, so from my point of view this bug can be closed, with your patch
> as part (first point) of solution.  As for second point I'll make new
> bug report about need of update for "table.el".

Alright, pushed to emacs-26.

140e7f890f 2019-04-28T17:20:17-04:00 "Recommend using font-lock-face over face (Bug#35044)"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=140e7f890fa94f8b6381dfa3e0682cacfa92a593

Previous Next

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