GNU bug report logs - #10113
24.0.91; Isearch & `M-e'

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 10113 in the body.
You can then email your comments to 10113 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: Dani Moncayo <dmoncayo <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.91; Isearch & `M-e'
Date: Tue, 22 Nov 2011 23:44:54 +0100

Hi,

Here are two recipes (from emacs -Q) that seem to be bugs in Isearch:

--------------------------------------------
First case:
1. Write the text "buffer buffeR".
2. Type "C-a C-s b u f f e R M-e DEL RET".
--> Here the _current_ match should be the first "buffe", but it's the
second one.
--------------------------------------------
Second case:
1. Write the text "buffer buffeR".
2. Type "C-a C-s b u f f e R M-e DEL r RET".
--> Here both words should be matched, but only the first one is.
--------------------------------------------



In GNU Emacs 24.0.91.1 (i386-mingw-nt6.1.7601)
 of 2011-11-21 on DANI-PC
Windowing system distributor `Microsoft Corp.', version 6.1.7601
configured using `configure --with-gcc (4.6)'

-- 
Dani Moncayo

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 01:21:33 +0200

> Here are two recipes (from emacs -Q) that seem to be bugs in Isearch:

Thanks for recipes.

> --------------------------------------------
> First case:
> 1. Write the text "buffer buffeR".
> 2. Type "C-a C-s b u f f e R M-e DEL RET".
> --> Here the _current_ match should be the first "buffe", but it's the
> second one.

Why do think Isearch should go back to the first match without the user
typing `C-r C-r' explicitly?

> --------------------------------------------
> Second case:
> 1. Write the text "buffer buffeR".
> 2. Type "C-a C-s b u f f e R M-e DEL r RET".
> --> Here both words should be matched, but only the first one is.

Actually this is unrelated to `isearch-edit-string'.
The first time you type an upper-case letter,
Isearch switches to case-sensitive mode.
You can observe this effect with the following case:

1. Write the text "buffer buffeR buffeRr buffeRR".
2. Type "C-a C-s b u f f e R r M-c".

After you type the first upper-case letter `R', Isearch switches
to case-sensitive mode, and after typing the next lower-case `r'
Isearch doesn't match "buffeRR".  It does that only when you
switch back to case-insensitive search mode by typing `M-c'.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 09:02:27 +0100

>> --------------------------------------------
>> First case:
>> 1. Write the text "buffer buffeR".
>> 2. Type "C-a C-s b u f f e R M-e DEL RET".
>> --> Here the _current_ match should be the first "buffe", but it's the
>> second one.
>
> Why do think Isearch should go back to the first match without the user
> typing `C-r C-r' explicitly?

Because, removing the final "R" via minibuffer should be equivalent to
do it directly by typing DEL (just after the "R").  After all, the
final situation is the same in both cases:
* Search string = "buffer".
* Starting point = just before "buffer".

IOW, after editing the search string in the minibuffer, the Isearch
should be re-started from the beginning, using the new (edited) search
string.

>> --------------------------------------------
>> Second case:
>> 1. Write the text "buffer buffeR".
>> 2. Type "C-a C-s b u f f e R M-e DEL r RET".
>> --> Here both words should be matched, but only the first one is.
>
> Actually this is unrelated to `isearch-edit-string'.
> The first time you type an upper-case letter,
> Isearch switches to case-sensitive mode.
> You can observe this effect with the following case:
>
> 1. Write the text "buffer buffeR buffeRr buffeRR".
> 2. Type "C-a C-s b u f f e R r M-c".
>
> After you type the first upper-case letter `R', Isearch switches
> to case-sensitive mode, and after typing the next lower-case `r'
> Isearch doesn't match "buffeRR".  It does that only when you
> switch back to case-insensitive search mode by typing `M-c'.

In this second case, my reasoning is analogous: Changing the final "R"
with a "r" via minibuffer should be equivalent to doing that directly
(typing "DEL r" just after the "R").

IOW, the case-sensitivity of the Isearch, when it's determined
_automatically_ (not by typing `M-c'), should be revised after editing
the search string in the minibuffer, to produce a result consistent
with the principle I said before.


-- 
Dani Moncayo

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 09:30:15 -0500

> Because, removing the final "R" via minibuffer should be equivalent to
> do it directly by typing DEL (just after the "R").  After all, the
> final situation is the same in both cases:

I understand what you mean, but I don't think it's important to make the
two behave identically: after all, if you want to DEL behavior, you know
where to find it.

> IOW, after editing the search string in the minibuffer, the Isearch
> should be re-started from the beginning, using the new (edited) search
> string.

That wouldn't always result in the same behavior as what DEL does
(think of the case where you do C-s buffe C-s C-s r C-s M-e DEL RET).
Making it really reproduce the behavior of DEL would require a good bit
more care.
And if we do try to make it behave like you want when the result of M-e
is a prefix of the original string, that will make it behave
inconsistently with the other cases when the result is not a prefix.

Nah, not a good idea.

> In this second case, my reasoning is analogous: Changing the final "R"
> with a "r" via minibuffer should be equivalent to doing that directly
> (typing "DEL r" just after the "R").

> IOW, the case-sensitivity of the Isearch, when it's determined
> _automatically_ (not by typing `M-c'), should be revised after editing
> the search string in the minibuffer, to produce a result consistent
> with the principle I said before.

I could agree here, OTOH.  My reasoning is not "because this is similar
to some earlier state" but rather because I think that there's no reason
to decide that entering an upper case letter should change the state
from "auto" to "ignore-case".  Instead it should stay as "auto" (until
the user explicitly choose a case sensitivity via M-c) and hence the
decision on whether to ignore case should be re-evaluated at every step.
I.e. C-s TOTO M-e C-a C-k foo RET should search for "foo" while
ignoring case.


        Stefan

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 15:56:32 +0100

>> IOW, after editing the search string in the minibuffer, the Isearch
>> should be re-started from the beginning, using the new (edited) search
>> string.
>
> That wouldn't always result in the same behavior as what DEL does
> (think of the case where you do C-s buffe C-s C-s r C-s M-e DEL RET).
> Making it really reproduce the behavior of DEL would require a good bit
> more care.
> And if we do try to make it behave like you want when the result of M-e
> is a prefix of the original string, that will make it behave
> inconsistently with the other cases when the result is not a prefix.

Actually I didn't think of making "M-e DEL RET" equivalent to "DEL" in
all cases.

I just think that, after editing the search string in the minibuffer,
the search should be re-started from the beginning.  Not doing so
makes little sense to me.  Why continue from a point that was reached
using a different search string?


-- 
Dani Moncayo

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: Juri Linkov <juri <at> jurta.org>, 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 14:54:23 -0500

>>> IOW, after editing the search string in the minibuffer, the Isearch
>>> should be re-started from the beginning, using the new (edited) search
>>> string.
>> That wouldn't always result in the same behavior as what DEL does
>> (think of the case where you do C-s buffe C-s C-s r C-s M-e DEL RET).
>> Making it really reproduce the behavior of DEL would require a good bit
>> more care.
>> And if we do try to make it behave like you want when the result of M-e
>> is a prefix of the original string, that will make it behave
>> inconsistently with the other cases when the result is not a prefix.
> Actually I didn't think of making "M-e DEL RET" equivalent to "DEL" in
> all cases.
> I just think that, after editing the search string in the minibuffer,
> the search should be re-started from the beginning.  Not doing so
> makes little sense to me.  Why continue from a point that was reached
> using a different search string?

It's as good a starting point as any.  The original starting point for
the search is also a possibility, indeed, but I don't think that it is
better in any significant way: it's sometimes better, sometimes worse.

So it's hard to justify such a change.


        Stefan

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 22:20:24 +0200

> Because, removing the final "R" via minibuffer should be equivalent to
> do it directly by typing DEL (just after the "R").

Actually `M-e DEL RET' is not equivalent to `DEL'.
It is equivalent to `C-M-w' (`isearch-del-char').

> In this second case, my reasoning is analogous: Changing the final "R"
> with a "r" via minibuffer should be equivalent to doing that directly
> (typing "DEL r" just after the "R").

`M-e DEL r RET' is not equivalent to `DEL r'.
It is equivalent to `C-M-w r'.

> IOW, the case-sensitivity of the Isearch, when it's determined
> _automatically_ (not by typing `M-c'),

WRT automatic changing of case-sensitivity after entering
an upper-case letter, this is a traditional behavior that
you can disable by customizing `search-upper-case' to nil.

> should be revised after editing the search string in the minibuffer,
> to produce a result consistent with the principle I said before.

This is unrelated to `isearch-edit-string'.  You'll get the same result
when you type `C-a C-s b u f f e R C-M-w r'.

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 21:59:21 +0100

On Wed, Nov 23, 2011 at 21:20, Juri Linkov <juri <at> jurta.org> wrote:
>> Because, removing the final "R" via minibuffer should be equivalent to
>> do it directly by typing DEL (just after the "R").
>
> Actually `M-e DEL RET' is not equivalent to `DEL'.
> It is equivalent to `C-M-w' (`isearch-del-char').

Agreed.

>> In this second case, my reasoning is analogous: Changing the final "R"
>> with a "r" via minibuffer should be equivalent to doing that directly
>> (typing "DEL r" just after the "R").
>
> `M-e DEL r RET' is not equivalent to `DEL r'.
> It is equivalent to `C-M-w r'.

Agreed.

>> IOW, the case-sensitivity of the Isearch, when it's determined
>> _automatically_ (not by typing `M-c'),
>
> WRT automatic changing of case-sensitivity after entering
> an upper-case letter, this is a traditional behavior that
> you can disable by customizing `search-upper-case' to nil.

Customizing that variable is not what I want.  See below.

>> should be revised after editing the search string in the minibuffer,
>> to produce a result consistent with the principle I said before.
>
> This is unrelated to `isearch-edit-string'.  You'll get the same result
> when you type `C-a C-s b u f f e R C-M-w r'.

You're right, you get the same (undesirable) result that way too.

I'll try to express myself better: by default (without touching
`isearch-edit-string'), the "case fold search" behavior can be
switched on/off in two ways:
a. Manually: by typing `M-c'.
b. Automatically (only applies if the previous criterion is "case
insensitive"): based on whether the current search string contains any
uppercase letter or not.

What I say is that currently (as we are shown) the (b) criterion is
not always re-evaluated, and it should.

BTW, Stefan agrees on this, and I hope you too :-).

-- 
Dani Moncayo

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

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Juri Linkov <juri <at> jurta.org>, 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 22:14:08 +0100

>> Actually I didn't think of making "M-e DEL RET" equivalent to "DEL" in
>> all cases.
>> I just think that, after editing the search string in the minibuffer,
>> the search should be re-started from the beginning.  Not doing so
>> makes little sense to me.  Why continue from a point that was reached
>> using a different search string?
>
> It's as good a starting point as any.  The original starting point for
> the search is also a possibility, indeed, but I don't think that it is
> better in any significant way: it's sometimes better, sometimes worse.
>
> So it's hard to justify such a change.

Fair enough.  Let's forget this use-case then.

-- 
Dani Moncayo

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Wed, 23 Nov 2011 23:23:37 +0200

> I'll try to express myself better: by default (without touching
> `isearch-edit-string'), the "case fold search" behavior can be
> switched on/off in two ways:
> a. Manually: by typing `M-c'.
> b. Automatically (only applies if the previous criterion is "case
> insensitive"): based on whether the current search string contains any
> uppercase letter or not.
>
> What I say is that currently (as we are shown) the (b) criterion is
> not always re-evaluated, and it should.
>
> BTW, Stefan agrees on this, and I hope you too :-).

True, currently after the first typed upper case letter,
case-sensitivity is not re-evaluated anymore.

This behavior can be changed with the following patch:

=== modified file 'lisp/isearch.el'
--- lisp/isearch.el	2011-11-19 21:51:29 +0000
+++ lisp/isearch.el	2011-11-23 21:21:22 +0000
@@ -1658,7 +1658,7 @@ (defun isearch-search-and-update ()
 	  (setq isearch-success t
 		isearch-error nil
 		isearch-other-end (match-end 0))
-	  (if (and (eq isearch-case-fold-search t) search-upper-case)
+	  (if search-upper-case
 	      (setq isearch-case-fold-search
 		    (isearch-no-upper-case-p isearch-string isearch-regexp))))
       ;; Not regexp, not reverse, or no match at point.
@@ -2328,7 +2328,7 @@ (defun isearch-search ()
   (if isearch-message-function
       (funcall isearch-message-function nil t)
     (isearch-message nil t))
-  (if (and (eq isearch-case-fold-search t) search-upper-case)
+  (if search-upper-case
       (setq isearch-case-fold-search
 	    (isearch-no-upper-case-p isearch-string isearch-regexp)))
   (condition-case lossage

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10113 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Thu, 01 Dec 2011 14:41:22 -0500

> True, currently after the first typed upper case letter,
> case-sensitivity is not re-evaluated anymore.
> This behavior can be changed with the following patch:

I don't think this qualifies as a bug, but I think it's a good change.
So let's keep it for 24.2 (e.g. you can install it in the `pending' branch).


        Stefan

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

From: Johan Bockgård <bojohan <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10113 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Sun, 04 Dec 2011 19:14:52 +0100

Juri Linkov <juri <at> jurta.org> writes:

>> I'll try to express myself better: by default (without touching
>> `isearch-edit-string'), the "case fold search" behavior can be
>> switched on/off in two ways:
>> a. Manually: by typing `M-c'.
>> b. Automatically (only applies if the previous criterion is "case
>> insensitive"): based on whether the current search string contains any
>> uppercase letter or not.
>>
>> What I say is that currently (as we are shown) the (b) criterion is
>> not always re-evaluated, and it should.
>>
>> BTW, Stefan agrees on this, and I hope you too :-).
>
> True, currently after the first typed upper case letter,
> case-sensitivity is not re-evaluated anymore.
>
> This behavior can be changed with the following patch:

Your patch breaks the `M-c' case.

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

From: Juri Linkov <juri <at> jurta.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: 10113 <at> debbugs.gnu.org
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Mon, 05 Dec 2011 12:49:43 +0200

>>> I'll try to express myself better: by default (without touching
>>> `isearch-edit-string'), the "case fold search" behavior can be
>>> switched on/off in two ways:
>>> a. Manually: by typing `M-c'.
>>> b. Automatically (only applies if the previous criterion is "case
>>> insensitive"): based on whether the current search string contains any
>>> uppercase letter or not.
>>>
>>> What I say is that currently (as we are shown) the (b) criterion is
>>> not always re-evaluated, and it should.
>>>
>>> BTW, Stefan agrees on this, and I hope you too :-).
>>
>> True, currently after the first typed upper case letter,
>> case-sensitivity is not re-evaluated anymore.
>>
>> This behavior can be changed with the following patch:
>
> Your patch breaks the `M-c' case.

Yes, this patch makes automatic toggling in both directions:
from case-insensitive to case-sensitive and back from case-sensitive
to case-insensitive.

Without this patch the current behavior is automatic toggling in one
direction: from case-insensitive to case-sensitive (on the first
encountered upper case letter).  Toggling back from case-sensitive
to case-insensitive is manual with `M-c', and this choice is remembered
with the value `yes' of `isearch-case-fold-search'.

To remember the user's toggle in the reverse direction (from
case-insensitive to case-sensitive) we need to introduce
a new value of `isearch-case-fold-search' (e.g. `no',
but treating it as a nil value would be quite ugly).

So perhaps instead of that, a better solution would be
to re-evaluate case-sensitivity only in two places:
in `isearch-edit-string' and `isearch-del-char'.

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

From: Richard Stallman <rms <at> gnu.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10113 <at> debbugs.gnu.org, dmoncayo <at> gmail.com
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Mon, 05 Dec 2011 12:19:19 -0500

I think it was a mistake to give M-c this special meaning in an
isearch.  It is useful for M-c to exit the isearch and capitalize the
next word.

The only situation where the special M-c meaning is needed
is to search for a word only in all lower case.  That is a rare use case,
and I think that complicating the isearch interface just for that
is making things worse.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10113 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Mon, 21 Mar 2022 22:52:31 +0100

Juri Linkov <juri <at> jurta.org> writes:

> Yes, this patch makes automatic toggling in both directions:
> from case-insensitive to case-sensitive and back from case-sensitive
> to case-insensitive.

This was ten years ago, and isearch behaves the same, as far as I can
tell. 

> Without this patch the current behavior is automatic toggling in one
> direction: from case-insensitive to case-sensitive (on the first
> encountered upper case letter).  Toggling back from case-sensitive
> to case-insensitive is manual with `M-c', and this choice is remembered
> with the value `yes' of `isearch-case-fold-search'.

I think your patch makes sense -- make `M-c' toggle the case
sensitivity in both directions, if I understand correctly?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

From: Juri Linkov <juri <at> jurta.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 10113 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Tue, 22 Mar 2022 10:47:44 +0200

>> Yes, this patch makes automatic toggling in both directions:
>> from case-insensitive to case-sensitive and back from case-sensitive
>> to case-insensitive.
>
> This was ten years ago, and isearch behaves the same, as far as I can
> tell.

This request is exactly as bug#14729 - to change the traditional behavior
of isearch for no gain, only for consistency with some abstract ideas.

>> Without this patch the current behavior is automatic toggling in one
>> direction: from case-insensitive to case-sensitive (on the first
>> encountered upper case letter).  Toggling back from case-sensitive
>> to case-insensitive is manual with `M-c', and this choice is remembered
>> with the value `yes' of `isearch-case-fold-search'.
>
> I think your patch makes sense -- make `M-c' toggle the case
> sensitivity in both directions, if I understand correctly?

The patch implemented automatic case-fold toggling in both directions,
where typing a letter re-evaluates case-sensitivity of the search string.
This might break some users' habits.  So another idea was to re-evaluate
case-sensitivity only in `isearch-edit-string' and `isearch-del-char'.
Still such change might be unexpected for some users.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Juri Linkov <juri <at> jurta.org>
Cc: 10113 <at> debbugs.gnu.org, Dani Moncayo <dmoncayo <at> gmail.com>
Subject: Re: bug#10113: 24.0.91; Isearch & `M-e'
Date: Tue, 22 Mar 2022 15:12:13 +0100

Juri Linkov <juri <at> jurta.org> writes:

> The patch implemented automatic case-fold toggling in both directions,
> where typing a letter re-evaluates case-sensitivity of the search string.
> This might break some users' habits.  So another idea was to re-evaluate
> case-sensitivity only in `isearch-edit-string' and `isearch-del-char'.
> Still such change might be unexpected for some users.

So I guess the conclusion here is that we don't really want to do
anything?  The user can always use `M-c' to toggle the case sensitivity
if they've done some odd sequence of commands that end up with a
sensitivity that's not what they want.

So I'm therefore closing this bug report.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Previous Next

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