GNU bug report logs - #35476
[PATCH] 27.0.50; font-lock-{append,prepend}-text-property and anonymous faces

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 35476 in the body.
You can then email your comments to 35476 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: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>
Subject: [PATCH] 27.0.50;
 font-lock-{append,prepend}-text-property and anonymous faces
Date: Sun, 28 Apr 2019 19:11:06 +0200

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

Hello,

This is a follow-up to the mails I sent to emacs-orgmode[1] and
help-gnu-emacs[2].

tl;dr I believe font-lock-{append,prepend}-text-property do not handle
anonymous faces correctly: they splice their attributes, producing
lists mixing keyword attributes and named faces such as this one:

    (:strike-through t org-level-1)

The patch I attach changes this to:

    ((:strike-through t) org-level-1)

To summarize my findings:

1. With org.el from Emacs's master branch (commit 88c91f53df), in an
   Org buffer with a heading such as this one:

        * *foo* /bar/ _baz_ +quux+
  
   foo (resp. bar and baz) show both the heading face and the bold
   (resp. italic and underline) decoration, whereas quux only shows
   the strike-through decoration, without the heading face.

2. C-u C-x = on quux says:

    > face        (:strike-through t org-level-1)

   A hasty look at org.el showed that it used
   `font-lock-prepend-text-property`.  I sent a trivial patch to
   emacs-orgmode which uses `font-lock-append-text-property` instead,
   although I wasn't sure that it was sound.  With this patch, C-u
   C-x = says instead:
   
    > face        (org-level-1 :strike-through t)

   … and quux shows both the org-level-1 foreground and the
   strike-through decoration.

3. On help-gnu-emacs, Stefan confirmed that my patch relies on
   undefined behavior.

4. Meanwhile, Nicolas applied it to the org-mode repository (commit
   42abf5c69).

I have now come to the conclusion that a patch such as the one I
attached in this report might be more appropriate.

[0001-Refrain-from-splicing-anonymous-faces-in-text-proper.patch (text/x-diff, attachment)]

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

I am not an expert on font-lock though, so this patch might not be
correct.  <excuses>Also, since I'm on a laptop running on battery
power, I don't intend to run make check right now.</excuses>  I am
sharing this patch in case someone well-versed in font-lock finds it
"obviously correct".

If that is the case, I have two more questions for additional patches:

1. Would it make sense to stuff most of these two functions's code
   into a third function called e.g.

        font-lock--add-text-property (start end prop value object append)

   in order to reduce duplication?

2. I guess some new automated tests would be appreciated?


Thank you for your time.

Kévin


[1]: http://lists.gnu.org/archive/html/emacs-orgmode/2019-04/msg00101.html
[2]: http://lists.gnu.org/archive/html/help-gnu-emacs/2019-04/msg00240.html



In GNU Emacs 27.0.50 (build 1, i686-pc-linux-gnu, GTK+ Version 3.22.11)
 of 2019-04-18 built on nc10-laptop
Repository revision: a18336a8dc754fa1c68e16dd8009466cf409271b
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.11902000
System Description: BunsenLabs GNU/Linux 9.8 (Helium)

Recent messages:
Saving file /home/peniblec/drafts/font-lock.md...
Wrote /home/peniblec/drafts/font-lock.md
Saving file /home/peniblec/drafts/font-lock.md...
Wrote /home/peniblec/drafts/font-lock.md
Mark set
Saving file /home/peniblec/drafts/font-lock.md...
Wrote /home/peniblec/drafts/font-lock.md
next-line: End of buffer [4 times]
Mark set [3 times]
Undo!

Configured using:
 'configure --with-xwidgets'

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB
NOTIFY INOTIFY ACL LIBSELINUX GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF
XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS XWIDGETS JSON
PDUMPER LCMS2 GMP

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: Markdown

Minor modes in effect:
  global-magit-file-mode: t
  magit-file-mode: t
  magit-auto-revert-mode: t
  global-git-commit-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  show-paren-mode: t
  minibuffer-depth-indicate-mode: t
  icomplete-mode: t
  global-page-break-lines-mode: t
  page-break-lines-mode: t
  electric-pair-mode: t
  diff-hl-flydiff-mode: t
  global-diff-hl-mode: t
  diff-hl-mode: t
  delete-selection-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: do-auto-fill
  visual-line-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow emacsbug dired-aux help-fns radix-tree cl-print debug backtrace
flyspell ediff-merg ediff-wind ediff-diff ediff-mult ediff-help
ediff-init ediff-util ediff vc-mtn vc-hg org-indent org-rmail org-mhe
org-irc org-info org-gnus org-docview doc-view jka-compr image-mode
org-bibtex bibtex org-bbdb org-w3m org-element avl-tree generator org
org-macro org-footnote org-pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob ob-tangle org-src ob-ref ob-lob ob-table
ob-keys ob-exp ob-comint ob-core ob-eval org-compat org-macs
org-loaddefs find-func cal-menu calendar cal-loaddefs ispell magit-patch
cus-edit whitespace bug-reference diff-hl-dired mailalias smtpmail
sendmail nnir markdown-mode rx color thingatpt noutline outline misearch
multi-isearch magit-extras executable magit-submodule magit-obsolete
magit-blame magit-stash magit-bisect magit-push magit-pull magit-fetch
magit-clone magit-remote magit-commit magit-sequence magit-notes
magit-worktree magit-tag magit-merge magit-branch magit-reset
magit-files magit-refs magit-status magit magit-repos magit-apply
magit-wip magit-log which-func imenu magit-diff smerge-mode magit-core
magit-autorevert autorevert filenotify magit-margin magit-transient
magit-process magit-mode transient git-commit magit-git magit-section
magit-utils crm log-edit pcvs-util add-log with-editor async-bytecomp
async shell pcomplete server dash sort gnus-cite mail-extr gnus-async
gnus-bcklg qp gnus-ml nndraft nnmh nnfolder utf-7 epa-file gnutls
network-stream nsm gnus-agent gnus-srvr gnus-score score-mode nnvirtual
gnus-msg gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp
gnus-cache gnus-sum gnus-group gnus-undo gnus-start gnus-cloud nnimap
nnmail mail-source utf7 netrc nnoo parse-time gnus-spec gnus-int
gnus-range message rmc puny dired dired-loaddefs format-spec rfc822 mml
mml-sec epa derived epg mm-decode mm-bodies mm-encode mail-parse rfc2231
mailabbrev gmm-utils mailheader gnus-win gnus nnheader gnus-util rmail
rmail-loaddefs rfc2047 rfc2045 ietf-drums text-property-search time-date
mail-utils mm-util mail-prsvr wid-edit vc-git vc-bzr vc-src vc-sccs
vc-svn vc-cvs vc-rcs project delight advice eighters-theme quail
cl-extra help-mode rg rg-ibuffer rg-result wgrep-rg wgrep s rg-history
rg-header rg-compat ibuf-ext ibuffer ibuffer-loaddefs grep compile
comint ansi-color ring edmacro kmacro disp-table paren mb-depth
icomplete page-break-lines elec-pair diff-hl-flydiff diff diff-hl vc-dir
ewoc vc vc-dispatcher diff-mode easy-mmode delsel cus-start cus-load
mule-util tex-site info package easymenu epg-config url-handlers
url-parse auth-source cl-seq eieio eieio-core cl-macs eieio-loaddefs
password-cache json subr-x map url-vars seq byte-opt gv bytecomp
byte-compile cconv cl-loaddefs cl-lib tooltip eldoc electric uniquify
ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win
term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page menu-bar rfn-eshadow isearch timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors 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 composite charscript charprop case-table epa-hook jka-cmpr-hook
help simple abbrev obarray 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 threads dbusbind inotify lcms2 dynamic-setting
system-font-setting font-render-setting xwidget-internal move-toolbar
gtk x-toolkit x multi-tty make-network-process emacs)

Memory information:
((conses 8 340103 79587)
 (symbols 24 31862 1)
 (strings 16 105392 12481)
 (string-bytes 1 3497604)
 (vectors 8 55552)
 (vector-slots 4 1313923 80148)
 (floats 8 495 324)
 (intervals 28 3532 1391)
 (buffers 564 52))

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 35476 <at> debbugs.gnu.org
Subject: Test suite
Date: Tue, 30 Apr 2019 08:08:33 +0200

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

As part of the discussion on help-gnu-emacs[1], Stefan applied a simpler
patch in commit f478082f9f, only for font-lock-prepend-text-property
though.  Does it make sense to do the same in
font-lock-append-text-property?

As a learning experience with ERT, I wrote the attached test suite; with
the current master branch, only the prepend test passes, the other
fails.  Applying the same change in font-lock-append-text-property lets
both tests pass.

[0001-Add-a-test-suite-for-anonymous-face-handling-in-text.patch (text/x-patch, attachment)]

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

Apologies for posting all over the place.


[1]: http://lists.gnu.org/archive/html/help-gnu-emacs/2019-04/msg00289.html

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: [BUMP] Some questions before closing
Date: Tue, 07 May 2019 07:24:26 +0200

Hi!

Now that Stefan committed a fix to Emacs 27, and Nicolas a workaround
to org-mode, this bug report can probably be closed; I just have a few
questions left:

1. Shouldn't Stefan's fix also be applied to
   font-lock-append-text-property?

2. Is it worth adding the test suite I posted in bug#35476#8 to the
   Emacs repository?

Thank your for your time.

Kévin

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: font-lock-{append,
 prepend}-text-property and anonymous faces
Date: Sun, 12 May 2019 08:28:39 -0400

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> Now that Stefan committed a fix to Emacs 27, and Nicolas a workaround
> to org-mode, this bug report can probably be closed; I just have a few
> questions left:
>
> 1. Shouldn't Stefan's fix also be applied to
>    font-lock-append-text-property?
>
> 2. Is it worth adding the test suite I posted in bug#35476#8 to the
>    Emacs repository?

I'd say the answers are yes and yes.  So would you mind adding the fix
for font-lock-append-text-property to your patch?

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: font-lock-{append,
 prepend}-text-property and anonymous faces
Date: Sun, 12 May 2019 19:34:01 +0200

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

Noam Postavsky <npostavs <at> gmail.com> writes:

> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
>> Now that Stefan committed a fix to Emacs 27, and Nicolas a workaround
>> to org-mode, this bug report can probably be closed; I just have a few
>> questions left:
>>
>> 1. Shouldn't Stefan's fix also be applied to
>>    font-lock-append-text-property?
>>
>> 2. Is it worth adding the test suite I posted in bug#35476#8 to the
>>    Emacs repository?
>
> I'd say the answers are yes and yes.  So would you mind adding the fix
> for font-lock-append-text-property to your patch?

Fix and test suite:

[0001-Stop-splicing-anonymous-faces-in-font-lock-append-te.patch (text/x-diff, attachment)]

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

Further refactoring (not really necessary; feel free to close the report
without applying):

[0002-Extract-common-code-for-adding-text-properties.patch (text/x-diff, attachment)]

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

Both patches were only "lightly" tested, i.e. by C-x C-e'ing every
function and test, then calling ert-run-tests-interactively; AFAICT the
tests pass[1].  Haven't run a full 'make check' yet (M-: insert-excuse
'battery); I don't think anything broke when Stefan committed the fix to
font-lock-prepend-text-property though.

Still pretty new to this, so let me know if I messed up anything
(e.g. commit message format, conventions when adding files, functions or
tests).

Thank you for your time.



[1] Although running 'make lisp/font-lock-tests' in the test/ folder
    fails on the append test.  Could it be that the Makefile runs the
    tests against the old font-lock.el that is installed on my system,
    rather than the new one in my repository?  I took a look at the
    test_template in test/Makefile, but I could not understand what the
    machinery loads at a glance.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: font-lock-{append,
 prepend}-text-property and anonymous faces
Date: Sun, 12 May 2019 15:09:36 -0400

Looks basically good, I just have a few nitpicks below.

> Subject: [PATCH 1/2] Stop splicing anonymous faces in
>  font-lock-append-text-property
>
> This is the same fix as f478082, which was only applied to

It's best to avoid using hashes in commit messages, as they're
translated to ChangeLog files which might read from the tarball (i.e.,
without a git repo to hand).  CONTRIBUTE talks about using "action
stamps" but I think date+title is more readable.  Which would be:
2019-04-29 "Refrain from splicing anonymous faces in text properties".

> +(provide 'font-lock-tests)

I don't think there is any reason to `provide' a feature in a test file
(I know some other test files do that, but I don't see why), test files
are generally not loaded via require.

> Subject: [PATCH 2/2] Extract common code for adding text properties

> +      (let ((new-value (if append
> +                           (append (if (listp prev) prev (list prev)) val)
> +                         (append val (if (listp prev) prev (list prev))))))

I would suggest to factor out the (if (listp prev) prev (list prev))
from these expressions.

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: font-lock-{append,
 prepend}-text-property and anonymous faces
Date: Sun, 12 May 2019 23:51:29 +0200

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

Noam Postavsky <npostavs <at> gmail.com> writes:

> It's best to avoid using hashes in commit messages, as they're
> translated to ChangeLog files which might read from the tarball (i.e.,
> without a git repo to hand).  CONTRIBUTE talks about using "action
> stamps" but I think date+title is more readable.  Which would be:
> 2019-04-29 "Refrain from splicing anonymous faces in text properties".

Ah, right, didn't think of the children^WChangeLog.  I went for
date+title.
  
Can e.g. git-show(1) understand action stamps?  I glanced at
gitrevisions(7) but nothing suggests Git knows anything about this
format.  It sure would make a hypothetical vc-revision-at-point command
easier to implement…

(Or, going the opposite route, maybe the git-log-to-ChangeLog machinery
could translate hashes to action stamps?)

>> +(provide 'font-lock-tests)
>
> I don't think there is any reason to `provide' a feature in a test file
> (I know some other test files do that, but I don't see why), test files
> are generally not loaded via require.

Done.

[0001-Stop-splicing-anonymous-faces-in-font-lock-append-te.patch (text/x-patch, attachment)]

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

>> Subject: [PATCH 2/2] Extract common code for adding text properties
>
>> +      (let ((new-value (if append
>> +                           (append (if (listp prev) prev (list prev)) val)
>> +                         (append val (if (listp prev) prev (list prev))))))
>
> I would suggest to factor out the (if (listp prev) prev (list prev))
> from these expressions.

And done.

[0002-Extract-common-code-for-adding-text-properties.patch (text/x-patch, attachment)]

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

Thank you for the review!  Let me know if there are further nits to
pick.

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

From: Noam Postavsky <npostavs <at> gmail.com>
To: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
Cc: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: font-lock-{append,
 prepend}-text-property and anonymous faces
Date: Mon, 13 May 2019 21:01:33 -0400

tags 35476 fixed
close 35476 27.1
quit

Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:

> [1] Although running 'make lisp/font-lock-tests' in the test/ folder
>     fails on the append test.  Could it be that the Makefile runs the
>     tests against the old font-lock.el that is installed on my system,
>     rather than the new one in my repository?  I took a look at the
>     test_template in test/Makefile, but I could not understand what the
>     machinery loads at a glance.

I forgot to answer this before.  There's two issues here:

1. The default value of load-prefer-newer means that of you change a .el
file without recompiling it, Emacs will load the .elc file instead.

2. For font-lock.el in particular, it's preloaded, so even if you
recompile it, font-lock.elc isn't loaded again, you need to redump
Emacs.

So generally, the way to test changes is

    make && make -C test font-lock-tests

Although it should also work to load the modified .el file explicitly
(untested, but):

    make -C test EMACS_EXTRAOPT='-l font-lock.el' font-lock-tests

>> It's best to avoid using hashes in commit messages, as they're
>> translated to ChangeLog files which might read from the tarball (i.e.,
>> without a git repo to hand).  CONTRIBUTE talks about using "action
>> stamps" but I think date+title is more readable.  Which would be:
>> 2019-04-29 "Refrain from splicing anonymous faces in text properties".
>
> Ah, right, didn't think of the children^WChangeLog.

:D
  
> Can e.g. git-show(1) understand action stamps?  I glanced at
> gitrevisions(7) but nothing suggests Git knows anything about this
> format.

I don't think so.  The last time I brought this up on emacs-devel there
was some suggestion that cgit (a git web frontend) would learn to
recognize them eventually, but I'm not sure if anything is really moving
in that direction.

> (Or, going the opposite route, maybe the git-log-to-ChangeLog machinery
> could translate hashes to action stamps?)

Maybe, although personally, as a human reader, I prefer date+title to
both hashes and action stamps, even when reading from git.  Yes, it's
quicker to find a commit given a hash, but that still requires at least
pressing RET or clicking or something like that.  Quite often, just
seeing the title is enough to understand what's meant and I don't need
to dig further.

> Thank you for the review!  Let me know if there are further nits to
> pick.

I think we're good here, pushed to master.

417c52b0b7 2019-05-13T20:41:02-04:00 "Extract common code for adding text properties"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=417c52b0b7fbf5cb02d229e81b7aaaacf2082bde

59ad303e8f 2019-05-13T20:41:02-04:00 "Stop splicing anonymous faces in font-lock-append-text-property"
https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=59ad303e8f3bb174ce326c76a9e7649f602120db

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

From: Kévin Le Gouguec <kevin.legouguec <at> gmail.com>
To: Noam Postavsky <npostavs <at> gmail.com>
Cc: 35476 <at> debbugs.gnu.org
Subject: Re: bug#35476: font-lock-{append,
 prepend}-text-property and anonymous faces
Date: Tue, 14 May 2019 08:01:04 +0200

Noam Postavsky <npostavs <at> gmail.com> writes:

> Kévin Le Gouguec <kevin.legouguec <at> gmail.com> writes:
>
>> [1] Although running 'make lisp/font-lock-tests' in the test/ folder
>>     fails on the append test.  Could it be that the Makefile runs the
>>     tests against the old font-lock.el that is installed on my system,
>>     rather than the new one in my repository?  I took a look at the
>>     test_template in test/Makefile, but I could not understand what the
>>     machinery loads at a glance.
>
> I forgot to answer this before.  There's two issues here:
>
> 1. The default value of load-prefer-newer means that of you change a .el
> file without recompiling it, Emacs will load the .elc file instead.
>
> 2. For font-lock.el in particular, it's preloaded, so even if you
> recompile it, font-lock.elc isn't loaded again, you need to redump
> Emacs.

Duly noted, I'll watch out for that in the future.

> So generally, the way to test changes is
>
>     make && make -C test font-lock-tests
>
> Although it should also work to load the modified .el file explicitly
> (untested, but):
>
>     make -C test EMACS_EXTRAOPT='-l font-lock.el' font-lock-tests

Just tried with and without EMACS_EXTRAOPT, and it does seem to work
around the problem.

>> Can e.g. git-show(1) understand action stamps?  I glanced at
>> gitrevisions(7) but nothing suggests Git knows anything about this
>> format.
>
> I don't think so.  The last time I brought this up on emacs-devel there
> was some suggestion that cgit (a git web frontend) would learn to
> recognize them eventually, but I'm not sure if anything is really moving
> in that direction.
>
>> (Or, going the opposite route, maybe the git-log-to-ChangeLog machinery
>> could translate hashes to action stamps?)
>
> Maybe, although personally, as a human reader, I prefer date+title to
> both hashes and action stamps, even when reading from git.  Yes, it's
> quicker to find a commit given a hash, but that still requires at least
> pressing RET or clicking or something like that.  Quite often, just
> seeing the title is enough to understand what's meant and I don't need
> to dig further.

OK.  FWIW, since I like to give context to my messages and I expect to
be doing the hash ↦ date+title dance a lot, this command seems to do the
job adequately for commit $c:

    git show --no-patch --date=short --format=format:'%ad "%s"' $c

Now to write some Lisp to make that available from vc and magit buffers…

(one-liner for action stamps left as exercise to the reader)

> I think we're good here, pushed to master.

Thanks!

Previous Next

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