GNU bug report logs - #77140
[PATCH] Strip text properties on recentf entries

Previous Next

To reply to this bug, email your comments to 77140 AT debbugs.gnu.org.
There is no need to reopen the bug first.

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

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

From: Ship Mints <shipmints <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Strip text properties on recentf entries
Date: Thu, 20 Mar 2025 12:56:25 -0400

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

Text properties are added by common completion frameworks, and serve no
purpose when stored in 'recentf-save-file', waste space, and slow loading
the file.

I did not add this to NEWS as I consider this non-user visible.  Happy to
add this if the maintainers disagree.

I've been running recentf with 'substring-no-properties' for ages and
others should benefit, by default.

-Stephane

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

[0001-Strip-text-properties-on-recentf-entries.patch (application/octet-stream, attachment)]

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

From: Ship Mints <shipmints <at> gmail.com>
To: 77140 <at> debbugs.gnu.org
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Thu, 20 Mar 2025 13:10:56 -0400

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

On Thu, Mar 20, 2025 at 12:57 PM Ship Mints <shipmints <at> gmail.com> wrote:

> Text properties are added by common completion frameworks, and serve no
> purpose when stored in 'recentf-save-file', waste space, and slow loading
> the file.
>
> I did not add this to NEWS as I consider this non-user visible.  Happy to
> add this if the maintainers disagree.
>
> I've been running recentf with 'substring-no-properties' for ages and
> others should benefit, by default.
>
> -Stephane
>

savehist already does this implicitly.  Perhaps it shouldn't even be
optional as I made it (it was an easy change).

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

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

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Ship Mints <shipmints <at> gmail.com>, 77140 <at> debbugs.gnu.org
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Thu, 20 Mar 2025 20:09:15 -0700

Ship Mints <shipmints <at> gmail.com> writes:

> On Thu, Mar 20, 2025 at 12:57 PM Ship Mints <shipmints <at> gmail.com> wrote:
>
>> Text properties are added by common completion frameworks, and serve no
>> purpose when stored in 'recentf-save-file', waste space, and slow loading
>> the file.
>>
>> I did not add this to NEWS as I consider this non-user visible.  Happy to
>> add this if the maintainers disagree.
>>
>> I've been running recentf with 'substring-no-properties' for ages and
>> others should benefit, by default.
>>
>> -Stephane
>>
>
> savehist already does this implicitly.  Perhaps it shouldn't even be
> optional as I made it (it was an easy change).

I think we should do this unconditionally, as the point here is to
locate the file and nothing else.

For the record, could you also provide details on which completion
frameworks that add text properties?  Do text properties cause any other
issues than wasted space?  It's enough to mention these detail here in
the bug report, I think, no need to add it to the commit message.

No need for NEWS here, I agree.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 77140 <at> debbugs.gnu.org
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 09:21:12 -0400

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

On Thu, Mar 20, 2025 at 11:09 PM Stefan Kangas <stefankangas <at> gmail.com>
wrote:

> Ship Mints <shipmints <at> gmail.com> writes:
>
> > On Thu, Mar 20, 2025 at 12:57 PM Ship Mints <shipmints <at> gmail.com> wrote:
> >
> >> Text properties are added by common completion frameworks, and serve no
> >> purpose when stored in 'recentf-save-file', waste space, and slow
> loading
> >> the file.
> >>
> >> I did not add this to NEWS as I consider this non-user visible.  Happy
> to
> >> add this if the maintainers disagree.
> >>
> >> I've been running recentf with 'substring-no-properties' for ages and
> >> others should benefit, by default.
> >>
> >> -Stephane
> >>
> >
> > savehist already does this implicitly.  Perhaps it shouldn't even be
> > optional as I made it (it was an easy change).
>
> I think we should do this unconditionally, as the point here is to
> locate the file and nothing else.
>
> For the record, could you also provide details on which completion
> frameworks that add text properties?  Do text properties cause any other
> issues than wasted space?  It's enough to mention these detail here in
> the bug report, I think, no need to add it to the commit message.
>
> No need for NEWS here, I agree.
>

Pretty much all completions, core and packages, that rely on metadata or
apply faces, add text properties to completion candidates.  The variable
'minibuffer-allow-text-properties' can be bound to nil but if you read
https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-02/msg00952.html you'll
see there cases where it can't accomplish its claim.

Revised patch attached.

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

[0001-Strip-text-properties-on-recentf-entries-when-saved.patch (application/octet-stream, attachment)]

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

From: Ship Mints <shipmints <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 77140 <at> debbugs.gnu.org
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 09:24:04 -0400

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

On Fri, Mar 21, 2025 at 9:21 AM Ship Mints <shipmints <at> gmail.com> wrote:

> On Thu, Mar 20, 2025 at 11:09 PM Stefan Kangas <stefankangas <at> gmail.com>
> wrote:
>
>> Ship Mints <shipmints <at> gmail.com> writes:
>>
>> > On Thu, Mar 20, 2025 at 12:57 PM Ship Mints <shipmints <at> gmail.com>
>> wrote:
>> >
>> >> Text properties are added by common completion frameworks, and serve no
>> >> purpose when stored in 'recentf-save-file', waste space, and slow
>> loading
>> >> the file.
>> >>
>> >> I did not add this to NEWS as I consider this non-user visible.  Happy
>> to
>> >> add this if the maintainers disagree.
>> >>
>> >> I've been running recentf with 'substring-no-properties' for ages and
>> >> others should benefit, by default.
>> >>
>> >> -Stephane
>> >>
>> >
>> > savehist already does this implicitly.  Perhaps it shouldn't even be
>> > optional as I made it (it was an easy change).
>>
>> I think we should do this unconditionally, as the point here is to
>> locate the file and nothing else.
>>
>> For the record, could you also provide details on which completion
>> frameworks that add text properties?  Do text properties cause any other
>> issues than wasted space?  It's enough to mention these detail here in
>> the bug report, I think, no need to add it to the commit message.
>>
>> No need for NEWS here, I agree.
>>
>
> Pretty much all completions, core and packages, that rely on metadata or
> apply faces, add text properties to completion candidates.  The variable
> 'minibuffer-allow-text-properties' can be bound to nil but if you read
> https://lists.gnu.org/archive/html/bug-gnu-emacs/2025-02/msg00952.html you'll
> see there cases where it can't accomplish its claim.
>
> Revised patch attached.
>

Now with the bug number in the commit log...

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

[0001-Strip-text-properties-on-recentf-entries-when-saved-.patch (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 15:52:32 +0200

> Cc: 77140 <at> debbugs.gnu.org
> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 21 Mar 2025 09:24:04 -0400
> 
> From 6eb57699f0e215e49d6071aac852740ac8cd60cc Mon Sep 17 00:00:00 2001
> From: shipmints <shipmints <at> gmail.com>
> Date: Thu, 20 Mar 2025 12:53:09 -0400
> Subject: [PATCH] Strip text properties on recentf entries, when saved
>  (bug#77140)
> 
> Text properties are added by common completion frameworks, and serve no
> purpose when stored in 'recentf-save-file', waste space, and slow loading
> the file.
> 
> * lisp/recentf.el (recentf-dump-variable): Process string values through
> 'substring-no-properties'.

Thanks, but please make the lines in the log message shorter (see
CONTRIBUTE for guidance).  This includes both the heading and the rest
of the log message.

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 10:02:56 -0400

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

On Fri, Mar 21, 2025 at 9:52 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Cc: 77140 <at> debbugs.gnu.org
> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 21 Mar 2025 09:24:04 -0400
> >
> > From 6eb57699f0e215e49d6071aac852740ac8cd60cc Mon Sep 17 00:00:00 2001
> > From: shipmints <shipmints <at> gmail.com>
> > Date: Thu, 20 Mar 2025 12:53:09 -0400
> > Subject: [PATCH] Strip text properties on recentf entries, when saved
> >  (bug#77140)
> >
> > Text properties are added by common completion frameworks, and serve no
> > purpose when stored in 'recentf-save-file', waste space, and slow loading
> > the file.
> >
> > * lisp/recentf.el (recentf-dump-variable): Process string values through
> > 'substring-no-properties'.
>
> Thanks, but please make the lines in the log message shorter (see
> CONTRIBUTE for guidance).  This includes both the heading and the rest
> of the log message.
>

This commit log entry summary is 64 chars (less than the 79 max target) and
the rest of the log is filled to 72 (.dir-locals.el is in effect), so I'm
missing what you are suggesting.

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

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 17:06:53 +0200

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Fri, 21 Mar 2025 10:02:56 -0400
> Cc: stefankangas <at> gmail.com, 77140 <at> debbugs.gnu.org
> 
>  Thanks, but please make the lines in the log message shorter (see
>  CONTRIBUTE for guidance).  This includes both the heading and the rest
>  of the log message.
> 
> This commit log entry summary is 64 chars (less than the 79 max target) and the rest of the log is filled to 72
> (.dir-locals.el is in effect), so I'm missing what you are suggesting.

The log message is indented with a TAB when we generate the ChangeLog
file from the Git log, so the 72-character lines will be 81, more than
we'd like to see in ChangeLog.  CONTRIBUTE says "Lines in ChangeLog
entries should preferably be not longer than 63 characters" for that
reason.  Please try not to exceed this limit, unless you really must
(like if you need to quote a long URL there).

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 11:13:02 -0400

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

On Fri, Mar 21, 2025 at 11:07 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Ship Mints <shipmints <at> gmail.com>
> > Date: Fri, 21 Mar 2025 10:02:56 -0400
> > Cc: stefankangas <at> gmail.com, 77140 <at> debbugs.gnu.org
> >
> >  Thanks, but please make the lines in the log message shorter (see
> >  CONTRIBUTE for guidance).  This includes both the heading and the rest
> >  of the log message.
> >
> > This commit log entry summary is 64 chars (less than the 79 max target)
> and the rest of the log is filled to 72
> > (.dir-locals.el is in effect), so I'm missing what you are suggesting.
>
> The log message is indented with a TAB when we generate the ChangeLog
> file from the Git log, so the 72-character lines will be 81, more than
> we'd like to see in ChangeLog.  CONTRIBUTE says "Lines in ChangeLog
> entries should preferably be not longer than 63 characters" for that
> reason.  Please try not to exceed this limit, unless you really must
> (like if you need to quote a long URL there).
>

Got it.  I've adjusted my 'git-commit-mode' 'fill-column' accordingly.
Revised patch attached.

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

[0001-Strip-text-properties-on-recentf-entries-when-saved-.patch (application/octet-stream, attachment)]

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77140 <at> debbugs.gnu.org, Ship Mints <shipmints <at> gmail.com>,
 stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 16:13:44 +0100

>>>>> On Fri, 21 Mar 2025 17:06:53 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Ship Mints <shipmints <at> gmail.com>
    >> Date: Fri, 21 Mar 2025 10:02:56 -0400
    >> Cc: stefankangas <at> gmail.com, 77140 <at> debbugs.gnu.org
    >> 
    >> Thanks, but please make the lines in the log message shorter (see
    >> CONTRIBUTE for guidance).  This includes both the heading and the rest
    >> of the log message.
    >> 
    >> This commit log entry summary is 64 chars (less than the 79 max target) and the rest of the log is filled to 72
    >> (.dir-locals.el is in effect), so I'm missing what you are suggesting.

    Eli> The log message is indented with a TAB when we generate the ChangeLog
    Eli> file from the Git log, so the 72-character lines will be 81, more than
    Eli> we'd like to see in ChangeLog.  CONTRIBUTE says "Lines in ChangeLog
    Eli> entries should preferably be not longer than 63 characters" for that
    Eli> reason.  Please try not to exceed this limit, unless you really must
    Eli> (like if you need to quote a long URL there).

If you use `log-edit-mode' to write your commit entries, you get this
for free. From .dir-locals.el:

 (log-edit-mode . ((log-edit-font-lock-gnu-style . t)
                   (log-edit-setup-add-author . t)
		   (vc-git-log-edit-summary-target-len . 50)
                   (fill-column . 64)))

Robert
-- 

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

From: Ship Mints <shipmints <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 11:26:46 -0400

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

On Fri, Mar 21, 2025 at 11:13 AM Robert Pluim <rpluim <at> gmail.com> wrote:

> >>>>> On Fri, 21 Mar 2025 17:06:53 +0200, Eli Zaretskii <eliz <at> gnu.org>
> said:
>
>     >> From: Ship Mints <shipmints <at> gmail.com>
>     >> Date: Fri, 21 Mar 2025 10:02:56 -0400
>     >> Cc: stefankangas <at> gmail.com, 77140 <at> debbugs.gnu.org
>     >>
>     >> Thanks, but please make the lines in the log message shorter (see
>     >> CONTRIBUTE for guidance).  This includes both the heading and the
> rest
>     >> of the log message.
>     >>
>     >> This commit log entry summary is 64 chars (less than the 79 max
> target) and the rest of the log is filled to 72
>     >> (.dir-locals.el is in effect), so I'm missing what you are
> suggesting.
>
>     Eli> The log message is indented with a TAB when we generate the
> ChangeLog
>     Eli> file from the Git log, so the 72-character lines will be 81, more
> than
>     Eli> we'd like to see in ChangeLog.  CONTRIBUTE says "Lines in
> ChangeLog
>     Eli> entries should preferably be not longer than 63 characters" for
> that
>     Eli> reason.  Please try not to exceed this limit, unless you really
> must
>     Eli> (like if you need to quote a long URL there).
>
> If you use `log-edit-mode' to write your commit entries, you get this
> for free. From .dir-locals.el:
>
>  (log-edit-mode . ((log-edit-font-lock-gnu-style . t)
>                    (log-edit-setup-add-author . t)
>                    (vc-git-log-edit-summary-target-len . 50)
>                    (fill-column . 64)))
>

Thanks.  I saw that.  magit uses its own minor mode on top of text-mode.
Jonas seems thoughtful enough to have considered log-edit-mode, probably?

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

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

From: Robert Pluim <rpluim <at> gmail.com>
To: Ship Mints <shipmints <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 16:29:35 +0100

>>>>> On Fri, 21 Mar 2025 11:26:46 -0400, Ship Mints <shipmints <at> gmail.com> said:

    Ship> Thanks.  I saw that.  magit uses its own minor mode on top of text-mode.
    Ship> Jonas seems thoughtful enough to have considered log-edit-mode, probably?

You can use the magit minor mode on top of `log-edit-mode', see
`git-commit-major-mode' (thanks to Stefan K for pointing this out to
me).

Robert
-- 

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

From: Ship Mints <shipmints <at> gmail.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Fri, 21 Mar 2025 11:43:38 -0400

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

On Fri, Mar 21, 2025 at 11:29 AM Robert Pluim <rpluim <at> gmail.com> wrote:

> >>>>> On Fri, 21 Mar 2025 11:26:46 -0400, Ship Mints <shipmints <at> gmail.com>
> said:
>
>     Ship> Thanks.  I saw that.  magit uses its own minor mode on top of
> text-mode.
>     Ship> Jonas seems thoughtful enough to have considered log-edit-mode,
> probably?
>
> You can use the magit minor mode on top of `log-edit-mode', see
> `git-commit-major-mode' (thanks to Stefan K for pointing this out to
> me).
>

Cool.  I just added the following to my emacs .dir-locals-2.el.  I'll make
it my default if I like it for Emacs.

(
 (nil . ((git-commit-major-mode . log-edit-mode)))
)

Perhaps this is worth adopting in .dir-locals.el itself.

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

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

From: Ship Mints <shipmints <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 77140 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Wed, 9 Apr 2025 16:14:04 -0400

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

On Fri, Mar 21, 2025 at 11:13 AM Ship Mints <shipmints <at> gmail.com> wrote:

> On Fri, Mar 21, 2025 at 11:07 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
>
>> > From: Ship Mints <shipmints <at> gmail.com>
>> > Date: Fri, 21 Mar 2025 10:02:56 -0400
>> > Cc: stefankangas <at> gmail.com, 77140 <at> debbugs.gnu.org
>> >
>> >  Thanks, but please make the lines in the log message shorter (see
>> >  CONTRIBUTE for guidance).  This includes both the heading and the rest
>> >  of the log message.
>> >
>> > This commit log entry summary is 64 chars (less than the 79 max target)
>> and the rest of the log is filled to 72
>> > (.dir-locals.el is in effect), so I'm missing what you are suggesting.
>>
>> The log message is indented with a TAB when we generate the ChangeLog
>> file from the Git log, so the 72-character lines will be 81, more than
>> we'd like to see in ChangeLog.  CONTRIBUTE says "Lines in ChangeLog
>> entries should preferably be not longer than 63 characters" for that
>> reason.  Please try not to exceed this limit, unless you really must
>> (like if you need to quote a long URL there).
>>
>
> Got it.  I've adjusted my 'git-commit-mode' 'fill-column' accordingly.
> Revised patch attached.
>

Possible to install this patch?  I've attached the same copy of the patch
from the above so it's easy to find.

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

[0001-Strip-text-properties-on-recentf-entries-when-saved-.patch (application/octet-stream, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ship Mints <shipmints <at> gmail.com>
Cc: 77140-done <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#77140: [PATCH] Strip text properties on recentf entries
Date: Sat, 19 Apr 2025 17:10:55 +0300

> From: Ship Mints <shipmints <at> gmail.com>
> Date: Wed, 9 Apr 2025 16:14:04 -0400
> Cc: stefankangas <at> gmail.com, 77140 <at> debbugs.gnu.org
> 
> On Fri, Mar 21, 2025 at 11:13 AM Ship Mints <shipmints <at> gmail.com> wrote:
> 
>  On Fri, Mar 21, 2025 at 11:07 AM Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>  > From: Ship Mints <shipmints <at> gmail.com>
>  > Date: Fri, 21 Mar 2025 10:02:56 -0400
>  > Cc: stefankangas <at> gmail.com, 77140 <at> debbugs.gnu.org
>  > 
>  >  Thanks, but please make the lines in the log message shorter (see
>  >  CONTRIBUTE for guidance).  This includes both the heading and the rest
>  >  of the log message.
>  > 
>  > This commit log entry summary is 64 chars (less than the 79 max target) and the rest of the log
>  is filled to 72
>  > (.dir-locals.el is in effect), so I'm missing what you are suggesting.
> 
>  The log message is indented with a TAB when we generate the ChangeLog
>  file from the Git log, so the 72-character lines will be 81, more than
>  we'd like to see in ChangeLog.  CONTRIBUTE says "Lines in ChangeLog
>  entries should preferably be not longer than 63 characters" for that
>  reason.  Please try not to exceed this limit, unless you really must
>  (like if you need to quote a long URL there).
> 
>  Got it.  I've adjusted my 'git-commit-mode' 'fill-column' accordingly.  Revised patch attached.
> 
> Possible to install this patch?  I've attached the same copy of the patch from the above so it's easy to find.

Thanks, now installed, and closing the bug.

Previous Next

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