GNU bug report logs -
#40940
27.0.91; project-query-replace-regexp stops too early
Previous Next
Reported by: Simen Heggestøyl <simenheg <at> runbox.com>
Date: Tue, 28 Apr 2020 14:57:02 UTC
Severity: normal
Found in version 27.0.91
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 40940 in the body.
You can then email your comments to 40940 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Tue, 28 Apr 2020 14:57:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Simen Heggestøyl <simenheg <at> runbox.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Tue, 28 Apr 2020 14:57:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
Create a directory with two files in it: test-2.txt and test.txt:
test-dir
├── test-2.txt
└── test.txt
Enter the text "Foo" into test.txt.
Enter the text "foo" into test-2.txt.
Visit the directory or any of the files (the result is the same either
way).
Type 'M-x project-query-replace-regexp', choosing to replace "Foo"
with "Bar".
Confirm test-dir as the project directory in the next prompt.
The replacement process stops with point before "foo" in test-2.txt
with a message "Replaced 0 occurrences", without replacing "Foo" in
test.txt as it should have.
The bug appears both in emacs-27 as of
16fed05ba85c3d92d3c913657dd50a648ad3884a, and on master as of
771a6b68165b986b6bf9249c57ca11d310b0f0e4.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 03:55:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 28.04.2020 17:35, Simen Heggestøyl wrote:
>
> Create a directory with two files in it: test-2.txt and test.txt:
>
> test-dir
> ├── test-2.txt
> └── test.txt
>
> Enter the text "Foo" into test.txt.
> Enter the text "foo" into test-2.txt.
>
> Visit the directory or any of the files (the result is the same either
> way).
>
> Type 'M-x project-query-replace-regexp', choosing to replace "Foo"
> with "Bar".
>
> Confirm test-dir as the project directory in the next prompt.
>
> The replacement process stops with point before "foo" in test-2.txt
> with a message "Replaced 0 occurrences", without replacing "Foo" in
> test.txt as it should have.
>
> The bug appears both in emacs-27 as of
> 16fed05ba85c3d92d3c913657dd50a648ad3884a, and on master as of
> 771a6b68165b986b6bf9249c57ca11d310b0f0e4.
I can confirm this. Tested with the current emacs-27.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 07:37:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 29 Apr 2020 06:54:22 +0300
> Cc: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
>
> > The replacement process stops with point before "foo" in test-2.txt
> > with a message "Replaced 0 occurrences", without replacing "Foo" in
> > test.txt as it should have.
> >
> > The bug appears both in emacs-27 as of
> > 16fed05ba85c3d92d3c913657dd50a648ad3884a, and on master as of
> > 771a6b68165b986b6bf9249c57ca11d310b0f0e4.
>
> I can confirm this. Tested with the current emacs-27.
Do we need to fix this in emacs-27? Is this a regression since Emacs 26?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 08:39:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> From: Simen Heggestøyl <simenheg <at> runbox.com>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 40940 <at> debbugs.gnu.org,
> monnier <at> IRO.UMontreal.CA
> Date: Wed, 29 Apr 2020 10:29:18 +0200
>
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
> > Is this a regression since Emacs 26?
>
> project-query-replace-regexp is new in Emacs 27.
OK, so we should fix this on the release branch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 09:04:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 40940 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Is this a regression since Emacs 26?
project-query-replace-regexp is new in Emacs 27.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 09:26:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 29 Apr 2020 11:37:53 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org, dgutov <at> yandex.ru
>
> > From: Simen Heggestøyl <simenheg <at> runbox.com>
> > Cc: Dmitry Gutov <dgutov <at> yandex.ru>, 40940 <at> debbugs.gnu.org,
> > monnier <at> IRO.UMontreal.CA
> > Date: Wed, 29 Apr 2020 10:29:18 +0200
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > Is this a regression since Emacs 26?
> >
> > project-query-replace-regexp is new in Emacs 27.
>
> OK, so we should fix this on the release branch.
First, this is broken if the shell doesn't expand ~/ or if the Emacs
notion of the home directory is different from that of the shell.
Here's the proposed patch (ignoring the whitespace changes); OK to
push to the emacs-27 branch?
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 1f4cbe9..dbc967b 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -185,13 +185,17 @@ project--files-in-directory
(require 'find-dired)
(require 'xref)
(defvar find-name-arg)
- (let ((default-directory dir)
+ (let* ((default-directory dir)
+ (dirname (file-remote-p dir 'localname))
+ (dirname (or dirname
+ ;; Make sure ~/ etc. in local directory name is
+ ;; expanded and not left for the shell command
+ ;; to interpret.
+ (expand-file-name dir)))
(command (format "%s %s %s -type f %s -print0"
find-program
- (file-local-name dir)
- (xref--find-ignores-arguments
- ignores
- (expand-file-name dir))
+ dirname
+ (xref--find-ignores-arguments ignores dirname)
(if files
(concat (shell-quote-argument "(")
" " find-name-arg " "
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 10:43:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Date: Wed, 29 Apr 2020 12:24:36 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
>
> First, this is broken if the shell doesn't expand ~/ or if the Emacs
> notion of the home directory is different from that of the shell.
The patch below seems to fix the rest. Note that I've decided to make
the change in fileloop.el, since I think all the other callers need
the same fix. Also, using downcase is not entirely correct, we should
use isearch-no-upper-case-p instead.
Comments?
diff --git a/lisp/fileloop.el b/lisp/fileloop.el
index 543963f..f7a199e 100644
--- a/lisp/fileloop.el
+++ b/lisp/fileloop.el
@@ -204,14 +204,24 @@ fileloop-initialize-replace
files
(lambda ()
(let ((case-fold-search
- (if (memql case-fold '(nil t)) case-fold case-fold-search)))
+ (if (memql case-fold '(nil t))
+ case-fold
+ (if (equal from (downcase from))
+ case-fold-search
+ nil))))
(if (re-search-forward from nil t)
;; When we find a match, move back
;; to the beginning of it so perform-replace
;; will see it.
(goto-char (match-beginning 0)))))
(lambda ()
- (perform-replace from to t t delimited nil multi-query-replace-map))))
+ (let ((case-fold-search
+ (if (memql case-fold '(nil t))
+ case-fold
+ (if (equal from (downcase from))
+ case-fold-search
+ nil))))
+ (perform-replace from to t t delimited nil multi-query-replace-map)))))
(provide 'fileloop)
;;; fileloop.el ends here
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 14:52:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 29.04.2020 12:24, Eli Zaretskii wrote:
> First, this is broken if the shell doesn't expand ~/ or if the Emacs
> notion of the home directory is different from that of the shell.
The patch seems okay, but could you describe a case when the shell fails
to expand '~/'? Is that about cmd.exe? Cygwin?
AFAICT the patch doesn't fix the same problem for remote hosts, is that
a problem?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 15:00:02 GMT)
Full text and
rfc822 format available.
Message #29 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 29 Apr 2020 17:50:53 +0300
>
> On 29.04.2020 12:24, Eli Zaretskii wrote:
> > First, this is broken if the shell doesn't expand ~/ or if the Emacs
> > notion of the home directory is different from that of the shell.
>
> The patch seems okay, but could you describe a case when the shell fails
> to expand '~/'? Is that about cmd.exe? Cygwin?
I've bumped into it with cmd.exe on MS-Windows, yes.
> AFAICT the patch doesn't fix the same problem for remote hosts, is that
> a problem?
No, I don't think so. A remote host cannot be a non-Posix system,
AFAIK. Michael, can you confirm? (And in any case, this issue should
be handled in the file-remote-p handler.)
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 15:43:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 29.04.2020 17:59, Eli Zaretskii wrote:
>> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Wed, 29 Apr 2020 17:50:53 +0300
>>
>> On 29.04.2020 12:24, Eli Zaretskii wrote:
>>> First, this is broken if the shell doesn't expand ~/ or if the Emacs
>>> notion of the home directory is different from that of the shell.
>>
>> The patch seems okay, but could you describe a case when the shell fails
>> to expand '~/'? Is that about cmd.exe? Cygwin?
>
> I've bumped into it with cmd.exe on MS-Windows, yes.
I see. Then LGTM, thank you.
Could you clarify, though, does that mean that no project commands are
currently working on Windows, without this patch? Or does that only
affect the "transient" project type?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 15:51:01 GMT)
Full text and
rfc822 format available.
Message #35 received at 40940 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
Hi Eli,
>> AFAICT the patch doesn't fix the same problem for remote hosts, is that
>> a problem?
>
> No, I don't think so. A remote host cannot be a non-Posix system,
> AFAIK.
A remote host can be (kind of) non-Posix, for example not expanding
"~/". But this is a general problem then accessing such a host, and one
shall avoid to use a remote file name containing the tilde.
> Michael, can you confirm? (And in any case, this issue should
> be handled in the file-remote-p handler.)
Tramp checks for all remote hosts whether they can expand "~/" (or
"~user/" in general). If possible, it does.
Your patch uses `expand-file-name', and that's all what we have to say
to Tramp.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 15:59:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 29.04.2020 18:49, Michael Albinus wrote:
> Your patch uses `expand-file-name', and that's all what we have to say
> to Tramp.
I think it uses it only for non-Tramp dirs, doesn't it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 16:05:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 29 Apr 2020 18:42:41 +0300
>
> >> The patch seems okay, but could you describe a case when the shell fails
> >> to expand '~/'? Is that about cmd.exe? Cygwin?
> >
> > I've bumped into it with cmd.exe on MS-Windows, yes.
>
> I see. Then LGTM, thank you.
Thanks, pushed to the emacs-27 branch.
> Could you clarify, though, does that mean that no project commands are
> currently working on Windows, without this patch? Or does that only
> affect the "transient" project type?
Only the "transient" projects, AFAICT. At least I tried with a Git
repository under ~/, and got absolute file names in the list. I hope
Mercurial does the same. You can test it easily by running
(project-files (project-current t))
in a suitable set up directory.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 16:11:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: Dmitry Gutov <dgutov <at> yandex.ru>, simenheg <at> runbox.com,
> monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> Date: Wed, 29 Apr 2020 17:49:46 +0200
>
> > Michael, can you confirm? (And in any case, this issue should
> > be handled in the file-remote-p handler.)
>
> Tramp checks for all remote hosts whether they can expand "~/" (or
> "~user/" in general). If possible, it does.
>
> Your patch uses `expand-file-name', and that's all what we have to say
> to Tramp.
My patch only calls expand-file-name on local file names. For remote
file names, I've left the result of the call to file-remote-p
unaltered. Would that be a problem if the file name, after stripping
the remote protocol parts, started with "~/" ? And if so, what should
be done here about these cases?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 16:12:02 GMT)
Full text and
rfc822 format available.
Message #47 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 29.04.2020 19:04, Eli Zaretskii wrote:
>> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Wed, 29 Apr 2020 18:42:41 +0300
>>
>>>> The patch seems okay, but could you describe a case when the shell fails
>>>> to expand '~/'? Is that about cmd.exe? Cygwin?
>>>
>>> I've bumped into it with cmd.exe on MS-Windows, yes.
>>
>> I see. Then LGTM, thank you.
>
> Thanks, pushed to the emacs-27 branch.
Thanks.
>> Could you clarify, though, does that mean that no project commands are
>> currently working on Windows, without this patch? Or does that only
>> affect the "transient" project type?
>
> Only the "transient" projects, AFAICT. At least I tried with a Git
> repository under ~/, and got absolute file names in the list. I hope
> Mercurial does the same. You can test it easily by running
>
> (project-files (project-current t))
>
> in a suitable set up directory.
It does. Very good.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 16:23:01 GMT)
Full text and
rfc822 format available.
Message #50 received at 40940 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Tramp checks for all remote hosts whether they can expand "~/" (or
>> "~user/" in general). If possible, it does.
>>
>> Your patch uses `expand-file-name', and that's all what we have to say
>> to Tramp.
>
> My patch only calls expand-file-name on local file names. For remote
> file names, I've left the result of the call to file-remote-p
> unaltered. Would that be a problem if the file name, after stripping
> the remote protocol parts, started with "~/" ? And if so, what should
> be done here about these cases?
Call `expand-file-name' on the remote file name, like
'(expand-file-name "/ssh:user <at> host:~/")'. Tramp expands it to
"/ssh:user <at> host:/home/user/", in case the "/home/user" is the home
directory of "user" on "host".
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 16:46:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> From: Michael Albinus <michael.albinus <at> gmx.de>
> Cc: dgutov <at> yandex.ru, simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA,
> 40940 <at> debbugs.gnu.org
> Date: Wed, 29 Apr 2020 18:22:06 +0200
>
> > My patch only calls expand-file-name on local file names. For remote
> > file names, I've left the result of the call to file-remote-p
> > unaltered. Would that be a problem if the file name, after stripping
> > the remote protocol parts, started with "~/" ? And if so, what should
> > be done here about these cases?
>
> Call `expand-file-name' on the remote file name, like
> '(expand-file-name "/ssh:user <at> host:~/")'. Tramp expands it to
> "/ssh:user <at> host:/home/user/", in case the "/home/user" is the home
> directory of "user" on "host".
Thanks.
Dmitry, this means my change should be reworked to call
expand-file-name before file-local-name, right?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 18:21:01 GMT)
Full text and
rfc822 format available.
Message #56 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 29.04.2020 19:44, Eli Zaretskii wrote:
> Dmitry, this means my change should be reworked to call
> expand-file-name before file-local-name, right?
Seems so.
Something like this?
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index dbc967b885..f80b4328bc 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -185,17 +185,16 @@ project--files-in-directory
(require 'find-dired)
(require 'xref)
(defvar find-name-arg)
- (let* ((default-directory dir)
- (dirname (file-remote-p dir 'localname))
- (dirname (or dirname
- ;; Make sure ~/ etc. in local directory name is
- ;; expanded and not left for the shell command
- ;; to interpret.
- (expand-file-name dir)))
+ (let* ((dir
+ ;; Make sure ~/ etc. in local directory name is
+ ;; expanded and not left for the shell command
+ ;; to interpret.
+ (expand-file-name dir))
+ (default-directory dir)
(command (format "%s %s %s -type f %s -print0"
find-program
- dirname
- (xref--find-ignores-arguments ignores dirname)
+ dir
+ (xref--find-ignores-arguments ignores dir)
(if files
(concat (shell-quote-argument "(")
" " find-name-arg " "
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 18:40:02 GMT)
Full text and
rfc822 format available.
Message #59 received at 40940 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> On 29.04.2020 19:44, Eli Zaretskii wrote:
>> Dmitry, this means my change should be reworked to call
>> expand-file-name before file-local-name, right?
>
> Seems so.
>
> Something like this?
>
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index dbc967b885..f80b4328bc 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -185,17 +185,16 @@ project--files-in-directory
> (require 'find-dired)
> (require 'xref)
> (defvar find-name-arg)
> - (let* ((default-directory dir)
> - (dirname (file-remote-p dir 'localname))
> - (dirname (or dirname
> - ;; Make sure ~/ etc. in local directory name is
> - ;; expanded and not left for the shell command
> - ;; to interpret.
> - (expand-file-name dir)))
> + (let* ((dir
> + ;; Make sure ~/ etc. in local directory name is
> + ;; expanded and not left for the shell command
> + ;; to interpret.
> + (expand-file-name dir))
> + (default-directory dir)
> (command (format "%s %s %s -type f %s -print0"
> find-program
> - dirname
> - (xref--find-ignores-arguments ignores dirname)
> + dir
> + (xref--find-ignores-arguments ignores dir)
> (if files
> (concat (shell-quote-argument "(")
> " " find-name-arg " "
No. dir is a remote file name. So you must still declare dirname as
(file-local-name dir).
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 18:45:01 GMT)
Full text and
rfc822 format available.
Message #62 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 29 Apr 2020 21:20:06 +0300
>
> On 29.04.2020 19:44, Eli Zaretskii wrote:
> > Dmitry, this means my change should be reworked to call
> > expand-file-name before file-local-name, right?
>
> Seems so.
>
> Something like this?
Yes, but the original code called file-local-name, whereas this one
doesn't. We had the call to file-local-name for a reason, didn't we?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 18:57:02 GMT)
Full text and
rfc822 format available.
Message #65 received at 40940 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
> Yes, but the original code called file-local-name, whereas this one
> doesn't. We had the call to file-local-name for a reason, didn't we?
Yes. The process shall always use the local file name in its arguments.
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 19:10:02 GMT)
Full text and
rfc822 format available.
Message #68 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 29.04.2020 21:38, Michael Albinus wrote:
> No. dir is a remote file name. So you must still declare dirname as
> (file-local-name dir).
Right, thank you. I also see no reason not to pass the local name to
xref--find-ignores-arguments (xref-matches-in-directory ends up doing
that already).
So the patch will be:
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index dbc967b885..f5f4092bab 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -186,16 +186,14 @@ project--files-in-directory
(require 'xref)
(defvar find-name-arg)
(let* ((default-directory dir)
- (dirname (file-remote-p dir 'localname))
- (dirname (or dirname
- ;; Make sure ~/ etc. in local directory name is
- ;; expanded and not left for the shell command
- ;; to interpret.
- (expand-file-name dir)))
+ ;; Make sure ~/ etc. in local directory name is
+ ;; expanded and not left for the shell command
+ ;; to interpret.
+ (localdir (file-local-name (expand-file-name dir)))
(command (format "%s %s %s -type f %s -print0"
find-program
- dirname
- (xref--find-ignores-arguments ignores dirname)
+ localdir
+ (xref--find-ignores-arguments ignores localdir)
(if files
(concat (shell-quote-argument "(")
" " find-name-arg " "
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 19:16:02 GMT)
Full text and
rfc822 format available.
Message #71 received at 40940 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index dbc967b885..f5f4092bab 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -186,16 +186,14 @@ project--files-in-directory
> (require 'xref)
> (defvar find-name-arg)
> (let* ((default-directory dir)
> - (dirname (file-remote-p dir 'localname))
> - (dirname (or dirname
> - ;; Make sure ~/ etc. in local directory name is
> - ;; expanded and not left for the shell command
> - ;; to interpret.
> - (expand-file-name dir)))
> + ;; Make sure ~/ etc. in local directory name is
> + ;; expanded and not left for the shell command
> + ;; to interpret.
> + (localdir (file-local-name (expand-file-name dir)))
> (command (format "%s %s %s -type f %s -print0"
> find-program
> - dirname
> - (xref--find-ignores-arguments ignores dirname)
> + localdir
> + (xref--find-ignores-arguments ignores localdir)
> (if files
> (concat (shell-quote-argument "(")
> " " find-name-arg " "
LGTM (I haven't tested, 'tho).
Best regards, Michael.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 19:28:02 GMT)
Full text and
rfc822 format available.
Message #74 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 29 Apr 2020 22:09:12 +0300
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
>
> On 29.04.2020 21:38, Michael Albinus wrote:
> > No. dir is a remote file name. So you must still declare dirname as
> > (file-local-name dir).
>
> Right, thank you. I also see no reason not to pass the local name to
> xref--find-ignores-arguments (xref-matches-in-directory ends up doing
> that already).
>
> So the patch will be:
Yes, I think so.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Wed, 29 Apr 2020 20:54:02 GMT)
Full text and
rfc822 format available.
Message #77 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 29.04.2020 13:41, Eli Zaretskii wrote:
> The patch below seems to fix the rest. Note that I've decided to make
> the change in fileloop.el, since I think all the other callers need
> the same fix.
Naturally.
> Also, using downcase is not entirely correct, we should
> use isearch-no-upper-case-p instead.
I usually like isearch-no-upper-case-p behavior, but here it doesn't fit
the docstring, does it? There is no value of CASE-FOLD described that
would indicate that the function will be too smart about it.
So we'd need to update the docstring that the CASE-FOLD value of t will
obey the value of `search-upper-case'. Then we'll consult it as well,
like isearch-search does.
Alternatively, we could for now use the below patch which changes the
behavior less:
diff --git a/lisp/fileloop.el b/lisp/fileloop.el
index 543963feaf..c3c55badf5 100644
--- a/lisp/fileloop.el
+++ b/lisp/fileloop.el
@@ -175,14 +175,16 @@ fileloop-continue
(funcall fileloop--operate-function)))
(setq file-finished t))))
+(defun fileloop--case-fold (arg)
+ (if (memq arg '(t nil)) arg case-fold-search))
+
;;;###autoload
(defun fileloop-initialize-search (regexp files case-fold)
(let ((last-buffer (current-buffer)))
(fileloop-initialize
files
(lambda ()
- (let ((case-fold-search
- (if (memq case-fold '(t nil)) case-fold case-fold-search)))
+ (let ((case-fold-search (fileloop--case-fold case-fold)))
(re-search-forward regexp nil t)))
(lambda ()
(unless (eq last-buffer (current-buffer))
@@ -203,15 +205,16 @@ fileloop-initialize-replace
(fileloop-initialize
files
(lambda ()
- (let ((case-fold-search
- (if (memql case-fold '(nil t)) case-fold case-fold-search)))
+ (let ((case-fold-search (fileloop--case-fold case-fold)))
(if (re-search-forward from nil t)
;; When we find a match, move back
;; to the beginning of it so perform-replace
;; will see it.
(goto-char (match-beginning 0)))))
(lambda ()
- (perform-replace from to t t delimited nil multi-query-replace-map))))
+ (let ((case-fold-search (fileloop--case-fold case-fold))
+ search-upper-case)
+ (perform-replace from to t t delimited nil
multi-query-replace-map)))))
(provide 'fileloop)
;;; fileloop.el ends here
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Thu, 30 Apr 2020 20:25:03 GMT)
Full text and
rfc822 format available.
Message #80 received at 40940 <at> debbugs.gnu.org (full text, mbox):
>> Also, using downcase is not entirely correct, we should
>> use isearch-no-upper-case-p instead.
>
> I usually like isearch-no-upper-case-p behavior, but here it doesn't fit
> the docstring, does it? There is no value of CASE-FOLD described that
> would indicate that the function will be too smart about it.
>
> So we'd need to update the docstring that the CASE-FOLD value of t will
> obey the value of `search-upper-case'. Then we'll consult it as well,
> like isearch-search does.
Recently we changed hi-lock.el to follow the same logic as
isearch-no-upper-case-p, so this will make the behavior
consistent across different packages.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Fri, 01 May 2020 06:01:01 GMT)
Full text and
rfc822 format available.
Message #83 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> From: Juri Linkov <juri <at> linkov.net>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, simenheg <at> runbox.com,
> monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> Date: Thu, 30 Apr 2020 23:16:04 +0300
>
> >> Also, using downcase is not entirely correct, we should
> >> use isearch-no-upper-case-p instead.
> >
> > I usually like isearch-no-upper-case-p behavior, but here it doesn't fit
> > the docstring, does it? There is no value of CASE-FOLD described that
> > would indicate that the function will be too smart about it.
> >
> > So we'd need to update the docstring that the CASE-FOLD value of t will
> > obey the value of `search-upper-case'. Then we'll consult it as well,
> > like isearch-search does.
>
> Recently we changed hi-lock.el to follow the same logic as
> isearch-no-upper-case-p, so this will make the behavior
> consistent across different packages.
Btw, looking at the other callers of fileloop-initialize-search, don't
get their logic backwards? If the string typed by the user does NOT
include upper-case character, that means the search SHOULD obey the
default value of case-fold-search. Or am I missing something?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Fri, 01 May 2020 06:58:02 GMT)
Full text and
rfc822 format available.
Message #86 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Wed, 29 Apr 2020 23:53:46 +0300
>
> > Also, using downcase is not entirely correct, we should
> > use isearch-no-upper-case-p instead.
>
> I usually like isearch-no-upper-case-p behavior, but here it doesn't fit
> the docstring, does it? There is no value of CASE-FOLD described that
> would indicate that the function will be too smart about it.
>
> So we'd need to update the docstring that the CASE-FOLD value of t will
> obey the value of `search-upper-case'. Then we'll consult it as well,
> like isearch-search does.
I don't think I follow. isearch-no-upper-case-p is just supposed to
tell you whether a regexp includes upper-case characters that would
need the search to become case-sensitive. All the rest of the
considerations, like the value of case-fold-search, are to be applied
by the caller. I see no reference to either case-fold-search or
case-fold in isearch-no-upper-case-p. So why would we need to update
its doc string?
> Alternatively, we could for now use the below patch which changes the
> behavior less:
>
> diff --git a/lisp/fileloop.el b/lisp/fileloop.el
> index 543963feaf..c3c55badf5 100644
> --- a/lisp/fileloop.el
> +++ b/lisp/fileloop.el
> @@ -175,14 +175,16 @@ fileloop-continue
> (funcall fileloop--operate-function)))
> (setq file-finished t))))
>
> +(defun fileloop--case-fold (arg)
> + (if (memq arg '(t nil)) arg case-fold-search))
> +
> ;;;###autoload
> (defun fileloop-initialize-search (regexp files case-fold)
> (let ((last-buffer (current-buffer)))
> (fileloop-initialize
> files
> (lambda ()
> - (let ((case-fold-search
> - (if (memq case-fold '(t nil)) case-fold case-fold-search)))
> + (let ((case-fold-search (fileloop--case-fold case-fold)))
> (re-search-forward regexp nil t)))
> (lambda ()
> (unless (eq last-buffer (current-buffer))
> @@ -203,15 +205,16 @@ fileloop-initialize-replace
> (fileloop-initialize
> files
> (lambda ()
> - (let ((case-fold-search
> - (if (memql case-fold '(nil t)) case-fold case-fold-search)))
> + (let ((case-fold-search (fileloop--case-fold case-fold)))
> (if (re-search-forward from nil t)
> ;; When we find a match, move back
> ;; to the beginning of it so perform-replace
> ;; will see it.
> (goto-char (match-beginning 0)))))
> (lambda ()
> - (perform-replace from to t t delimited nil multi-query-replace-map))))
> + (let ((case-fold-search (fileloop--case-fold case-fold))
> + search-upper-case)
> + (perform-replace from to t t delimited nil multi-query-replace-map)))))
Does that really work in the case in point? Unless I'm missing
something, if case-fold-search is t by default, this patch would cause
the search to be case-insensitive even if the FROM regexp includes
upper-case characters. But in that case, perform-replace will
internally decide to be case-sensitive, and we have the same failure
on our hands. This is why the patch I proposed explicitly examined
the FROM regexp for upper-case characters. Whereas yours doesn't.
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Fri, 01 May 2020 15:28:01 GMT)
Full text and
rfc822 format available.
Message #89 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 01.05.2020 09:57, Eli Zaretskii wrote:
> I see no reference to either case-fold-search or
> case-fold in isearch-no-upper-case-p. So why would we need to update
> its doc string?
Sorry if that was unclear: I think we'd need to update the docstring of
fileloop-initialize-replace. Which doesn't offer any hints that the
logic of isearch-no-upper-case-p will be employed.
Also see the part about obeying the value of search-upper-case.
> Does that really work in the case in point? Unless I'm missing
> something, if case-fold-search is t by default, this patch would cause
> the search to be case-insensitive even if the FROM regexp includes
> upper-case characters. But in that case, perform-replace will
> internally decide to be case-sensitive, and we have the same failure
> on our hands. This is why the patch I proposed explicitly examined
> the FROM regexp for upper-case characters. Whereas yours doesn't.
Since we bind search-upper-case to nil in this patch, perform-replace
won't try to alter the value of case-fold-search internally.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Fri, 01 May 2020 15:47:02 GMT)
Full text and
rfc822 format available.
Message #92 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Fri, 1 May 2020 18:27:45 +0300
>
> On 01.05.2020 09:57, Eli Zaretskii wrote:
> > I see no reference to either case-fold-search or
> > case-fold in isearch-no-upper-case-p. So why would we need to update
> > its doc string?
>
> Sorry if that was unclear: I think we'd need to update the docstring of
> fileloop-initialize-replace. Which doesn't offer any hints that the
> logic of isearch-no-upper-case-p will be employed.
Ah, okay. Agreed.
> > Does that really work in the case in point? Unless I'm missing
> > something, if case-fold-search is t by default, this patch would cause
> > the search to be case-insensitive even if the FROM regexp includes
> > upper-case characters. But in that case, perform-replace will
> > internally decide to be case-sensitive, and we have the same failure
> > on our hands. This is why the patch I proposed explicitly examined
> > the FROM regexp for upper-case characters. Whereas yours doesn't.
>
> Since we bind search-upper-case to nil in this patch, perform-replace
> won't try to alter the value of case-fold-search internally.
But that's contrary to how query-replace works, isn't it?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Fri, 01 May 2020 23:23:01 GMT)
Full text and
rfc822 format available.
Message #95 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 01.05.2020 18:45, Eli Zaretskii wrote:
>> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
>> From: Dmitry Gutov <dgutov <at> yandex.ru>
>> Date: Fri, 1 May 2020 18:27:45 +0300
>>
>> On 01.05.2020 09:57, Eli Zaretskii wrote:
>>> I see no reference to either case-fold-search or
>>> case-fold in isearch-no-upper-case-p. So why would we need to update
>>> its doc string?
>>
>> Sorry if that was unclear: I think we'd need to update the docstring of
>> fileloop-initialize-replace. Which doesn't offer any hints that the
>> logic of isearch-no-upper-case-p will be employed.
>
> Ah, okay. Agreed.
Should I leave that to you? At least the "updated docstring" part.
>>> Does that really work in the case in point? Unless I'm missing
>>> something, if case-fold-search is t by default, this patch would cause
>>> the search to be case-insensitive even if the FROM regexp includes
>>> upper-case characters. But in that case, perform-replace will
>>> internally decide to be case-sensitive, and we have the same failure
>>> on our hands. This is why the patch I proposed explicitly examined
>>> the FROM regexp for upper-case characters. Whereas yours doesn't.
>>
>> Since we bind search-upper-case to nil in this patch, perform-replace
>> won't try to alter the value of case-fold-search internally.
>
> But that's contrary to how query-replace works, isn't it?
I suppose. But query-replace documents that aspects of its behavior:
Matching is independent of case if `case-fold-search' is non-nil and
FROM-STRING has no uppercase letters.
Though it doesn't mention the search-upper-case variable.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Sat, 02 May 2020 06:46:01 GMT)
Full text and
rfc822 format available.
Message #98 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sat, 2 May 2020 02:21:57 +0300
>
> >> Sorry if that was unclear: I think we'd need to update the docstring of
> >> fileloop-initialize-replace. Which doesn't offer any hints that the
> >> logic of isearch-no-upper-case-p will be employed.
> >
> > Ah, okay. Agreed.
>
> Should I leave that to you? At least the "updated docstring" part.
I can update the doc string, yes. But I don't think it's a good idea
to divide the coding part between us, though. So please show the
code, and I will suggest the doc change.
> >> Since we bind search-upper-case to nil in this patch, perform-replace
> >> won't try to alter the value of case-fold-search internally.
> >
> > But that's contrary to how query-replace works, isn't it?
>
> I suppose. But query-replace documents that aspects of its behavior:
>
> Matching is independent of case if `case-fold-search' is non-nil and
> FROM-STRING has no uppercase letters.
Sure. Wouldn't users of project-query-replace-regexp expect the same?
> Though it doesn't mention the search-upper-case variable.
Ugh! That should be fixed, of course.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Sat, 02 May 2020 07:57:02 GMT)
Full text and
rfc822 format available.
Message #101 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Date: Sat, 02 May 2020 09:44:30 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
>
> > Though it doesn't mention the search-upper-case variable.
>
> Ugh! That should be fixed, of course.
Now done on the emacs-27 branch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Sun, 03 May 2020 01:44:02 GMT)
Full text and
rfc822 format available.
Message #104 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 02.05.2020 09:44, Eli Zaretskii wrote:
> I can update the doc string, yes. But I don't think it's a good idea
> to divide the coding part between us, though. So please show the
> code, and I will suggest the doc change.
Here's the comprehensive fix I'd like to see:
diff --git a/lisp/fileloop.el b/lisp/fileloop.el
index 543963feaf..69825fdcae 100644
--- a/lisp/fileloop.el
+++ b/lisp/fileloop.el
@@ -181,8 +181,7 @@ fileloop-initialize-search
(fileloop-initialize
files
(lambda ()
- (let ((case-fold-search
- (if (memq case-fold '(t nil)) case-fold case-fold-search)))
+ (let ((case-fold-search (fileloop--case-fold regexp case-fold)))
(re-search-forward regexp nil t)))
(lambda ()
(unless (eq last-buffer (current-buffer))
@@ -190,6 +189,15 @@ fileloop-initialize-search
(message "Scanning file %s...found" buffer-file-name))
nil))))
+(defun fileloop--case-fold (regexp case-fold)
+ (let ((value
+ (if (memql case-fold '(nil t))
+ case-fold
+ case-fold-search)))
+ (if (and value search-upper-case)
+ (isearch-no-upper-case-p regexp t)
+ value)))
+
;;;###autoload
(defun fileloop-initialize-replace (from to files case-fold &optional
delimited)
"Initialize a new round of query&replace on several files.
@@ -203,15 +211,15 @@ fileloop-initialize-replace
(fileloop-initialize
files
(lambda ()
- (let ((case-fold-search
- (if (memql case-fold '(nil t)) case-fold case-fold-search)))
+ (let ((case-fold-search (fileloop--case-fold from case-fold)))
(if (re-search-forward from nil t)
;; When we find a match, move back
;; to the beginning of it so perform-replace
;; will see it.
(goto-char (match-beginning 0)))))
(lambda ()
- (perform-replace from to t t delimited nil multi-query-replace-map))))
+ (let ((case-fold-search (fileloop--case-fold from case-fold)))
+ (perform-replace from to t t delimited nil
multi-query-replace-map)))))
(provide 'fileloop)
;;; fileloop.el ends here
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Sun, 03 May 2020 08:19:02 GMT)
Full text and
rfc822 format available.
Message #107 received at 40940 <at> debbugs.gnu.org (full text, mbox):
Dmitry Gutov <dgutov <at> yandex.ru> writes:
> Here's the comprehensive fix I'd like to see:
This works as expected in my testing.
> + (if (memql case-fold '(nil t))
AKA (booleanp case-fold) if you'd like.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Sun, 03 May 2020 17:12:02 GMT)
Full text and
rfc822 format available.
Message #110 received at 40940 <at> debbugs.gnu.org (full text, mbox):
> Cc: simenheg <at> runbox.com, monnier <at> IRO.UMontreal.CA, 40940 <at> debbugs.gnu.org
> From: Dmitry Gutov <dgutov <at> yandex.ru>
> Date: Sun, 3 May 2020 04:43:26 +0300
>
> +(defun fileloop--case-fold (regexp case-fold)
> + (let ((value
> + (if (memql case-fold '(nil t))
> + case-fold
> + case-fold-search)))
> + (if (and value search-upper-case)
> + (isearch-no-upper-case-p regexp t)
> + value)))
LGTM, thanks. But don't you need to require isearch to get
isearch-no-upper-case-p? or to autoload it?
Here's the doc string I promised:
(defun fileloop-initialize-replace (from to files case-fold &optional delimited)
"Initialize a new round of query&replace on several files.
FROM is a regexp and TO is the replacement to use.
FILES describes the files, as in `fileloop-initialize'.
CASE-FOLD can be t, nil, or `default':
if it is nil, matching of FROM is case-sensitive.
if it is t, matching of FROM is case-insensitive, except
when `search-upper-case' is non-nil and FROM includes
upper-case letters.
if it is `default', the function uses the value of
`case-fold-search' instead.
DELIMITED if non-nil means replace only word-delimited matches."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#40940; Package
emacs.
(Sun, 03 May 2020 17:29:01 GMT)
Full text and
rfc822 format available.
Message #113 received at 40940 <at> debbugs.gnu.org (full text, mbox):
On 03.05.2020 20:10, Eli Zaretskii wrote:
> LGTM, thanks. But don't you need to require isearch to get
> isearch-no-upper-case-p? or to autoload it?
isearch is in loadup.el, isn't it?
> Here's the doc string I promised:
Looks good, thanks.
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>:
You have taken responsibility.
(Sun, 03 May 2020 23:59:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Simen Heggestøyl <simenheg <at> runbox.com>:
bug acknowledged by developer.
(Sun, 03 May 2020 23:59:02 GMT)
Full text and
rfc822 format available.
Message #118 received at 40940-done <at> debbugs.gnu.org (full text, mbox):
On 03.05.2020 20:28, Dmitry Gutov wrote:
> > Here's the doc string I promised:
>
> Looks good, thanks.
Patch installed, thanks to all.
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org.
(Mon, 01 Jun 2020 11:24:06 GMT)
Full text and
rfc822 format available.
This bug report was last modified 5 years and 112 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.