GNU bug report logs - #14595
Erroneous composition of lambda in emacs-lisp buffers with prog-prettify-symbols enabled

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 14595 in the body.
You can then email your comments to 14595 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: Juanma Barranquero <lekktu <at> gmail.com>
To: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: Erroneous composition of lambda in emacs-lisp buffers with
 prog-prettify-symbols enabled
Date: Wed, 12 Jun 2013 05:18:59 +0200

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

Package: emacs
Version: 24.3.50


With a test file lambda.el which contains 1000 identical lines:

(lambda (x) x)

emacs -Q --eval "(setq-default prog-prettify-symbols t)" lambda.el

In most cases, lambda is correctly composed to λ; in a few, it is
composed (apparently) like a supperposition of the characters in
"lambda" (attached image included).

If I visit lambda.el as in the example above, and scroll down the
buffer, I get 26 such failures, always at the same lines (168, 280,
364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
visiting the file I go to the end of the buffer and scroll up, I get
many more failures (about 60) at diferent lines, but also consistently
the same lines.


describe-char for a correct composition:

             position: 2492 of 15000 (17%), column: 1
            character: l (displayed as l) (codepoint 108, #o154, #x6c)
    preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x6C
               script: latin
               syntax: w which means: word
             category: .:Base, L:Left-to-right (strong), a:ASCII,
l:Latin, r:Roman
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #x6C
            file code: #x6C (encoded by coding system utf-8-dos)
              display: composed to form "lambda" (see below)

Composed with the following character(s) "ambda" by the rule:
(?λ)
The component character(s) are displayed by these fonts (glyph codes):
 λ: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso10646-1 (#x21C)
See the variable `reference-point-alist' for the meaning of the rule.

Character code properties: customize what to show
  name: LATIN SMALL LETTER L
  general-category: Ll (Letter, Lowercase)
  decomposition: (108) ('l')

There are text properties here:
  composition          [Show]
  face                 font-lock-keyword-face
  fontified            t


describe-char for a wrong one:

             position: 2507 of 15000 (17%), column: 1
            character: l (displayed as l) (codepoint 108, #o154, #x6c)
    preferred charset: ascii (ASCII (ISO646 IRV))
code point in charset: 0x6C
               script: latin
               syntax: w which means: word
             category: .:Base, L:Left-to-right (strong), a:ASCII,
l:Latin, r:Roman
             to input: type "C-x 8 RET HEX-CODEPOINT" or "C-x 8 RET NAME"
          buffer code: #x6C
            file code: #x6C (encoded by coding system utf-8-dos)
              display: composed to form "lambda" (see below)

Composed with the following character(s) "ambda" by the rule:
(?l ?a ?m ?b ?d ?a)
The component character(s) are displayed by these fonts (glyph codes):
 l: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x4F)
 a: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x44)
 m: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x50)
 b: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x45)
 d: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x47)
 a: uniscribe:-outline-Courier
New-normal-normal-normal-mono-13-*-*-*-c-*-iso8859-1 (#x44)
See the variable `reference-point-alist' for the meaning of the rule.

Character code properties: customize what to show
  name: LATIN SMALL LETTER L
  general-category: Ll (Letter, Lowercase)
  decomposition: (108) ('l')

There are text properties here:
  composition          [Show]
  face                 font-lock-keyword-face
  fontified            t

[bug.png (image/png, attachment)]

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 04:21:44 -0400

On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu <at> gmail.com> wrote: 

JB> If I visit lambda.el as in the example above, and scroll down the
JB> buffer, I get 26 such failures, always at the same lines (168, 280,
JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
JB> visiting the file I go to the end of the buffer and scroll up, I get
JB> many more failures (about 60) at diferent lines, but also consistently
JB> the same lines.

Ouch.  I don't think I'm doing anything strange in the fontification
keywords that implement the new prettification functionality, but why
wasn't this seen before?  The scroll behavior probably indicates a
display engine issue.

Ted

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with	prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 12:00:04 +0300

> From: Ted Zlatanov <tzz <at> lifelogs.com>
> Date: Sat, 15 Jun 2013 04:21:44 -0400
> 
> On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu <at> gmail.com> wrote: 
> 
> JB> If I visit lambda.el as in the example above, and scroll down the
> JB> buffer, I get 26 such failures, always at the same lines (168, 280,
> JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
> JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
> JB> visiting the file I go to the end of the buffer and scroll up, I get
> JB> many more failures (about 60) at diferent lines, but also consistently
> JB> the same lines.
> 
> Ouch.  I don't think I'm doing anything strange in the fontification
> keywords that implement the new prettification functionality, but why
> wasn't this seen before?  The scroll behavior probably indicates a
> display engine issue.

What issue would that be?

The problem here is that the composition rule is generated
incorrectly.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: 14595 <at> debbugs.gnu.org
Cc: Juanma Barranquero <lekktu <at> gmail.com>
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp
 buffers	with	prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 12:12:51 +0300

> Date: Sat, 15 Jun 2013 12:00:04 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Ted Zlatanov <tzz <at> lifelogs.com>
> > Date: Sat, 15 Jun 2013 04:21:44 -0400
> > 
> > On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu <at> gmail.com> wrote: 
> > 
> > JB> If I visit lambda.el as in the example above, and scroll down the
> > JB> buffer, I get 26 such failures, always at the same lines (168, 280,
> > JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
> > JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
> > JB> visiting the file I go to the end of the buffer and scroll up, I get
> > JB> many more failures (about 60) at diferent lines, but also consistently
> > JB> the same lines.
> > 
> > Ouch.  I don't think I'm doing anything strange in the fontification
> > keywords that implement the new prettification functionality, but why
> > wasn't this seen before?  The scroll behavior probably indicates a
> > display engine issue.
> 
> What issue would that be?
> 
> The problem here is that the composition rule is generated
> incorrectly.

And here's why:

The incorrect display happens when the underlined part below

      (compose-region start end (cdr (assoc (match-string 0) alist)))))
                                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

is nil.  When that happens, (match-string 0) is "(", the left
parenthesis, not the expected "lambda".

I hope fontification gurus will be able to tell us why this could
happen.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14595 <at> debbugs.gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 19:35:38 +0200

On Sat, Jun 15, 2013 at 11:12 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> The incorrect display happens when the underlined part below
>
>       (compose-region start end (cdr (assoc (match-string 0) alist)))))
>                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> is nil.  When that happens, (match-string 0) is "(", the left
> parenthesis, not the expected "lambda".

The call to syntax-ppss inside prog--prettify-font-lock-compose-symbol
is altering the match-string data. I saved (match-string 0) in the
let* as ms0, and then for the erroneous lines I get this log:

start = 2507 / end = 2513 / (match-string 0) = #("(" 0 1 (fontified
t)) / ms0 = #("lambda" 0 6 (fontified t)) / alist = (("lambda" . 955))

so it was correct when the function was called. Then I wrapped the
syntax-ppss call inside save-match-data and the bug disappears.

> I hope fontification gurus will be able to tell us why this could
> happen.

Yep.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14595 <at> debbugs.gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 19:49:10 +0200

In other words, this simple patch fixes the problem:

=== modified file 'lisp/progmodes/prog-mode.el'
--- lisp/progmodes/prog-mode.el 2013-06-06 21:32:13 +0000
+++ lisp/progmodes/prog-mode.el 2013-06-15 17:47:50 +0000
@@ -77,7 +77,7 @@
        '(?w) '(?. ?\\))))
     (if (or (memq (char-syntax (or (char-before start) ?\ )) syntaxes)
     (memq (char-syntax (or (char-after end) ?\ )) syntaxes)
-            (nth 8 (syntax-ppss)))
+            (nth 8 (save-match-data (syntax-ppss))))
  ;; No composition for you.  Let's actually remove any composition
  ;; we may have added earlier and which is now incorrect.
  (remove-text-properties start end '(composition))


but, it would still be nice to know why syntax-ppss destroys
(match-data 0) in some lines and not all of them.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 14595 <at> debbugs.gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 22:51:35 +0200

On Sat, Jun 15, 2013 at 7:49 PM, Juanma Barranquero <lekktu <at> gmail.com> wrote:

> In other words, this simple patch fixes the problem:

This one is presumably cheaper:

=== modified file 'lisp/progmodes/prog-mode.el'
--- lisp/progmodes/prog-mode.el 2013-06-06 21:32:13 +0000
+++ lisp/progmodes/prog-mode.el 2013-06-15 20:50:09 +0000
@@ -74,15 +74,17 @@
   (let* ((start (match-beginning 0))
  (end (match-end 0))
  (syntaxes (if (eq (char-syntax (char-after start)) ?w)
-       '(?w) '(?. ?\\))))
+       '(?w) '(?. ?\\)))
+         match)
     (if (or (memq (char-syntax (or (char-before start) ?\ )) syntaxes)
     (memq (char-syntax (or (char-after end) ?\ )) syntaxes)
-            (nth 8 (syntax-ppss)))
+            ;; syntax-ppss can modify the match data
+            (progn (setq match (match-string 0)) (nth 8 (syntax-ppss))))
  ;; No composition for you.  Let's actually remove any composition
  ;; we may have added earlier and which is now incorrect.
  (remove-text-properties start end '(composition))
       ;; That's a symbol alright, so add the composition.
-      (compose-region start end (cdr (assoc (match-string 0) alist)))))
+      (compose-region start end (cdr (assoc match alist)))))
   ;; Return nil because we're not adding any face property.
   nil)

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 20:13:28 -0400

On Sat, 15 Jun 2013 19:49:10 +0200 Juanma Barranquero <lekktu <at> gmail.com> wrote: 

JB> In other words, this simple patch fixes the problem:

JB> === modified file 'lisp/progmodes/prog-mode.el'
JB> --- lisp/progmodes/prog-mode.el 2013-06-06 21:32:13 +0000
JB> +++ lisp/progmodes/prog-mode.el 2013-06-15 17:47:50 +0000
JB> @@ -77,7 +77,7 @@
JB>         '(?w) '(?. ?\\))))
JB>      (if (or (memq (char-syntax (or (char-before start) ?\ )) syntaxes)
JB>      (memq (char-syntax (or (char-after end) ?\ )) syntaxes)
JB> -            (nth 8 (syntax-ppss)))
JB> +            (nth 8 (save-match-data (syntax-ppss))))
JB>   ;; No composition for you.  Let's actually remove any composition
JB>   ;; we may have added earlier and which is now incorrect.
JB>   (remove-text-properties start end '(composition))

Nice catch.

JB> but, it would still be nice to know why syntax-ppss destroys
JB> (match-data 0) in some lines and not all of them.

I took this code out of `perl-mode' but didn't write it.  I hope someone
else can answer.

Ted

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with	prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 20:17:20 -0400

On Sat, 15 Jun 2013 12:00:04 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote: 

>> From: Ted Zlatanov <tzz <at> lifelogs.com>
>> Date: Sat, 15 Jun 2013 04:21:44 -0400
>> 
>> On Wed, 12 Jun 2013 05:18:59 +0200 Juanma Barranquero <lekktu <at> gmail.com> wrote: 
>> 
JB> If I visit lambda.el as in the example above, and scroll down the
JB> buffer, I get 26 such failures, always at the same lines (168, 280,
JB> 364, 432, 489, 538, 581, 619, 654, 686, 715, 742, 767, 791, 813, 834,
JB> 854, 873, 891, 908, 924, 940, 955, 970, 984 and 998); however, if upon
JB> visiting the file I go to the end of the buffer and scroll up, I get
JB> many more failures (about 60) at diferent lines, but also consistently
JB> the same lines.
>> 
>> Ouch.  I don't think I'm doing anything strange in the fontification
>> keywords that implement the new prettification functionality, but why
>> wasn't this seen before?  The scroll behavior probably indicates a
>> display engine issue.

EZ> What issue would that be?

EZ> The problem here is that the composition rule is generated
EZ> incorrectly.

I understand that part and Juanma posted a patch that looks helpful.

The scroll behavior he described is strangely inconsistent.  If you
think it's OK to display inconsistent data with bad input data (which
IIUC is what's happening), then there's no issue.  I don't know if it's
OK to display inconsistent lines like that, so I leave it to you and Juanma.

Ted

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: 14595 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sat, 15 Jun 2013 20:53:50 -0400

> but, it would still be nice to know why syntax-ppss destroys
> (match-data 0) in some lines and not all of them.

syntax-ppss does many different things in different cases (e.g. it may
run syntax-propertize), so it's no wonder.


        Stefan

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 14595 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sun, 16 Jun 2013 03:19:01 +0200

On Sun, Jun 16, 2013 at 2:53 AM, Stefan Monnier
<monnier <at> iro.umontreal.ca> wrote:

> syntax-ppss does many different things in different cases (e.g. it may
> run syntax-propertize), so it's no wonder.

OK, I'll install my patch then,

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: 14595-done <at> debbugs.gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sun, 16 Jun 2013 03:32:30 +0200

Fixed in revno:113004

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Juanma Barranquero <lekktu <at> gmail.com>
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp
 buffers	with	prog-prettify-symbols enabled
Date: Sun, 16 Jun 2013 05:50:18 +0300

> From: Ted Zlatanov <tzz <at> lifelogs.com>
> Date: Sat, 15 Jun 2013 20:17:20 -0400
> 
> The scroll behavior [Juanma] described is strangely inconsistent.  If you
> think it's OK to display inconsistent data with bad input data (which
> IIUC is what's happening), then there's no issue.  I don't know if it's
> OK to display inconsistent lines like that, so I leave it to you and Juanma.

I wasn't aware of any inconsistent display or scrolling behavior in
his description.  Juanma, can you repeat that description, which I
probably missed?

Thanks.

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

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Bug-Gnu-Emacs <bug-gnu-emacs <at> gnu.org>
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sun, 16 Jun 2013 05:01:48 +0200

On Sun, Jun 16, 2013 at 4:50 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:

> I wasn't aware of any inconsistent display or scrolling behavior in
> his description.  Juanma, can you repeat that description, which I
> probably missed?

With a file containing 1000 identical lines "(lambda (x) x)", the
lambdas that were incorrectly composed depend on the direction you
scroll the buffer. Scrolling from the beginning towards the end (page
by page), I got about 30 errors, always in the same positions
(distributed non-uniformly). If you repeat the experiment, but go
immediately to the end and scroll up, you got a different number of
errors (double or so) at different possitions, also consistents from
one run to the next.

I suppose that's what Ted is talking about.

   J

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

From: Ted Zlatanov <tzz <at> lifelogs.com>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with prog-prettify-symbols enabled
Date: Sun, 16 Jun 2013 05:27:50 -0400

On Sun, 16 Jun 2013 05:01:48 +0200 Juanma Barranquero <lekktu <at> gmail.com> wrote: 

JB> On Sun, Jun 16, 2013 at 4:50 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> I wasn't aware of any inconsistent display or scrolling behavior in
>> his description.  Juanma, can you repeat that description, which I
>> probably missed?

JB> With a file containing 1000 identical lines "(lambda (x) x)", the
JB> lambdas that were incorrectly composed depend on the direction you
JB> scroll the buffer. Scrolling from the beginning towards the end (page
JB> by page), I got about 30 errors, always in the same positions
JB> (distributed non-uniformly). If you repeat the experiment, but go
JB> immediately to the end and scroll up, you got a different number of
JB> errors (double or so) at different possitions, also consistents from
JB> one run to the next.

JB> I suppose that's what Ted is talking about.

Yes.  Again, I don't know if this is a problem worth fixing, I was just
clarifying how it's inconsistent depending on the scroll direction.

Ted

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#14595: Erroneous composition of lambda in emacs-lisp buffers
 with	prog-prettify-symbols enabled
Date: Sun, 16 Jun 2013 19:17:36 +0300

> From: Ted Zlatanov <tzz <at> lifelogs.com>
> Date: Sun, 16 Jun 2013 05:27:50 -0400
> 
> On Sun, 16 Jun 2013 05:01:48 +0200 Juanma Barranquero <lekktu <at> gmail.com> wrote: 
> 
> JB> On Sun, Jun 16, 2013 at 4:50 AM, Eli Zaretskii <eliz <at> gnu.org> wrote:
> >> I wasn't aware of any inconsistent display or scrolling behavior in
> >> his description.  Juanma, can you repeat that description, which I
> >> probably missed?
> 
> JB> With a file containing 1000 identical lines "(lambda (x) x)", the
> JB> lambdas that were incorrectly composed depend on the direction you
> JB> scroll the buffer. Scrolling from the beginning towards the end (page
> JB> by page), I got about 30 errors, always in the same positions
> JB> (distributed non-uniformly). If you repeat the experiment, but go
> JB> immediately to the end and scroll up, you got a different number of
> JB> errors (double or so) at different possitions, also consistents from
> JB> one run to the next.
> 
> JB> I suppose that's what Ted is talking about.
> 
> Yes.  Again, I don't know if this is a problem worth fixing, I was just
> clarifying how it's inconsistent depending on the scroll direction.

It's not a problem.  There's no symmetry in how the display engine
handles scrolling up and down, so it exposes portions of the buffer to
font-lock differently depending on the direction of the scroll.

Previous Next

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