GNU bug report logs -
#73530
[PATCH] Add imenu index function for Djvu files in doc-view
Previous Next
Reported by: Visuwesh <visuweshm <at> gmail.com>
Date: Sat, 28 Sep 2024 15:12:02 UTC
Severity: wishlist
Tags: patch
Done: Tassilo Horn <tsdh <at> gnu.org>
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 73530 in the body.
You can then email your comments to 73530 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#73530
; Package
emacs
.
(Sat, 28 Sep 2024 15:12:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Visuwesh <visuweshm <at> gmail.com>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Sat, 28 Sep 2024 15:12:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Tags: patch
Attached patch adds a function to create imenu index for Djvu files
using djvused. If you do not have a Djvu file available, I can point to
a file from libgen that can be used as a test file.
In GNU Emacs 31.0.50 (build 7, x86_64-pc-linux-gnu, X toolkit, cairo
version 1.18.0, Xaw scroll bars) of 2024-09-09 built on astatine
Repository revision: 7d7aa65f63db78c5732f1580213fc3767b767a4a
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101011
System Description: Debian GNU/Linux trixie/sid
Configured using:
'configure --with-sound=alsa --with-x-toolkit=lucid --without-xaw3d
--without-gconf --without-libsystemd --with-cairo'
[0001-Add-imenu-index-function-for-Djvu-files-in-doc-view.patch (text/patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 16:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 73530 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Date: Sat, 28 Sep 2024 20:40:54 +0530
>
>
> Attached patch adds a function to create imenu index for Djvu files
> using djvused. If you do not have a Djvu file available, I can point to
> a file from libgen that can be used as a test file.
Thanks, but can we please not hard-code names of programs, and instead
use variables that can be adjusted by users? I know that "mutool" was
hard-coded, but adding more hard-coded programs sounds too much.
Adding Tassilo to the discussion.
> + When the @command{mutool} or the @command{djvused} program is
> +available, DocView will use it to generate entries for an outline menu,
> +making it accessible via the @code{imenu} facility (@pxref{Imenu}). To
> +disable this functionality even when the required program can be found
> +on your system, customize the variable @code{doc-view-imenu-enabled} to
> +the @code{nil} value. You can further customize how @code{imenu} items
> +are formatted and displayed using the variables
> +@code{doc-view-imenu-format} and @code{doc-view-imenu-flatten}.
This is misleading, I think: it leaves the impression that the two
tools are interchangeable, where in reality each one supports
different format of files. The text should say explicitly that one is
for PDF, the other for Djvu.
> -(defcustom doc-view-imenu-enabled (and (executable-find "mutool") t)
> - "Whether to generate an imenu outline when \"mutool\" is available."
> +(defcustom doc-view-imenu-enabled (and (or (executable-find "mutool")
> + (executable-find "djvused"))
> + t)
> + "Whether to generate an imenu outline when available.
"When available" sounds awkward. "When possible", perhaps?
Also, "generate imenu outline" is too general. Don't forget that the
first line of a doc string is shown by apropos commands, and so should
speak for itself. I would say
Whether to generate imenu outline for PDF and DJVU files.
The "when available" part is unnecessary, because Emacs checks for
availability, and the user can override that.
> +Optional argument LEVEL is the current heading level. If nil, then 1 is
> +used."
Optional argument LEVEL is the current heading level, which defaults
to 1.
> +(defun doc-view--outline (&optional file-name)
> + "Return the outline for the file FILE-NAME.
> +If FILE-NAME is nil, use the current file instead."
Since FILE-NAME can be omitted, it is better to use our usual style:
If FILE-NAME is nil or omitted, it defaults to the current buffer's
file name.
> + (unless file-name (setq file-name (buffer-file-name)))
> + (pcase doc-view-doc-type
> + ('djvu
> + (when (executable-find "djvused")
> + (doc-view--djvu-outline file-name)))
> + (_
> + (when (executable-find "mutool")
> + (doc-view--pdf-outline file-name)))))
We already tested that the relevant tool is available, so why test
that here again?
Thanks.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 17:04:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> Attached patch adds a function to create imenu index for Djvu files
>> using djvused. If you do not have a Djvu file available, I can point
>> to a file from libgen that can be used as a test file.
>
> Thanks, but can we please not hard-code names of programs, and instead
> use variables that can be adjusted by users? I know that "mutool" was
> hard-coded, but adding more hard-coded programs sounds too much.
That would be good, yes.
> Adding Tassilo to the discussion.
>
>> + When the @command{mutool} or the @command{djvused} program is
>> +available, DocView will use it to generate entries for an outline menu,
>> +making it accessible via the @code{imenu} facility (@pxref{Imenu}). To
>> +disable this functionality even when the required program can be found
>> +on your system, customize the variable @code{doc-view-imenu-enabled} to
>> +the @code{nil} value. You can further customize how @code{imenu} items
>> +are formatted and displayed using the variables
>> +@code{doc-view-imenu-format} and @code{doc-view-imenu-flatten}.
>
> This is misleading, I think: it leaves the impression that the two
> tools are interchangeable, where in reality each one supports
> different format of files. The text should say explicitly that one is
> for PDF, the other for Djvu.
Indeed. And while we are here: doesn anyone know why we have an option
to disable imenu support? I see that we have that since Jose
contributed the initial imenu support but why? I can't see any harm
done if it was always enabled and would give a user-error like "For
imenu support for XXX files, program YYY has to be installed" or
something when invoking imenu. And why someone might want to disable it
even if the required program is available is beyond my imagination. I
mean, if you don't want to use imenu, then just don't invoke it...
>> -(defcustom doc-view-imenu-enabled (and (executable-find "mutool") t)
>> - "Whether to generate an imenu outline when \"mutool\" is available."
>> +(defcustom doc-view-imenu-enabled (and (or (executable-find "mutool")
>> + (executable-find "djvused"))
>> + t)
>> + "Whether to generate an imenu outline when available.
>
> "When available" sounds awkward. "When possible", perhaps?
>
> Also, "generate imenu outline" is too general. Don't forget that the
> first line of a doc string is shown by apropos commands, and so should
> speak for itself. I would say
>
> Whether to generate imenu outline for PDF and DJVU files.
>
> The "when available" part is unnecessary, because Emacs checks for
> availability, and the user can override that.
Well, if we must keep this defcustom, then it should probably allow
enabling/disabling the feature for each file type separately, i.e., its
value should be a set (pdf djvu).
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 17:38:02 GMT)
Full text and
rfc822 format available.
Message #14 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[சனி செப்டம்பர் 28, 2024] Tassilo Horn wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> Attached patch adds a function to create imenu index for Djvu files
>>> using djvused. If you do not have a Djvu file available, I can point
>>> to a file from libgen that can be used as a test file.
>>
>> Thanks, but can we please not hard-code names of programs, and instead
>> use variables that can be adjusted by users? I know that "mutool" was
>> hard-coded, but adding more hard-coded programs sounds too much.
>
> That would be good, yes.
Will do.
>> Adding Tassilo to the discussion.
>>
>>> + When the @command{mutool} or the @command{djvused} program is
>>> +available, DocView will use it to generate entries for an outline menu,
>>> +making it accessible via the @code{imenu} facility (@pxref{Imenu}). To
>>> +disable this functionality even when the required program can be found
>>> +on your system, customize the variable @code{doc-view-imenu-enabled} to
>>> +the @code{nil} value. You can further customize how @code{imenu} items
>>> +are formatted and displayed using the variables
>>> +@code{doc-view-imenu-format} and @code{doc-view-imenu-flatten}.
>>
>> This is misleading, I think: it leaves the impression that the two
>> tools are interchangeable, where in reality each one supports
>> different format of files. The text should say explicitly that one is
>> for PDF, the other for Djvu.
OK, will rewrite.
> Indeed. And while we are here: doesn anyone know why we have an option
> to disable imenu support? I see that we have that since Jose
> contributed the initial imenu support but why? I can't see any harm
> done if it was always enabled and would give a user-error like "For
> imenu support for XXX files, program YYY has to be installed" or
> something when invoking imenu. And why someone might want to disable it
> even if the required program is available is beyond my imagination. I
> mean, if you don't want to use imenu, then just don't invoke it...
I was wondering the same thing, especially since the cost of making the
imenu index is not that high.
>>> -(defcustom doc-view-imenu-enabled (and (executable-find "mutool") t)
>>> - "Whether to generate an imenu outline when \"mutool\" is available."
>>> +(defcustom doc-view-imenu-enabled (and (or (executable-find "mutool")
>>> + (executable-find "djvused"))
>>> + t)
>>> + "Whether to generate an imenu outline when available.
>>
>> "When available" sounds awkward. "When possible", perhaps?
>>
>> Also, "generate imenu outline" is too general. Don't forget that the
>> first line of a doc string is shown by apropos commands, and so should
>> speak for itself. I would say
>>
>> Whether to generate imenu outline for PDF and DJVU files.
>>
>> The "when available" part is unnecessary, because Emacs checks for
>> availability, and the user can override that.
>
> Well, if we must keep this defcustom, then it should probably allow
> enabling/disabling the feature for each file type separately, i.e., its
> value should be a set (pdf djvu).
That would make sense. I was wondering if we should create separate
defcustom for each program but this is a better approach.
[ BTW, is it "DJVU" or "Djvu"? The comments in doc-view.el uses the
latter AFAICT. ]
> Bye,
> Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 17:55:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 73530 <at> debbugs.gnu.org (full text, mbox):
> From: Visuwesh <visuweshm <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 73530 <at> debbugs.gnu.org
> Date: Sat, 28 Sep 2024 23:05:33 +0530
>
> [ BTW, is it "DJVU" or "Djvu"? The comments in doc-view.el uses the
> latter AFAICT. ]
I think it's actually DjVu.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 18:13:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
>>> doc-view-imenu-enabled
>>
>> Indeed. And while we are here: doesn anyone know why we have an
>> option to disable imenu support? I see that we have that since Jose
>> contributed the initial imenu support but why? I can't see any harm
>> done if it was always enabled and would give a user-error like "For
>> imenu support for XXX files, program YYY has to be installed" or
>> something when invoking imenu. And why someone might want to disable
>> it even if the required program is available is beyond my
>> imagination. I mean, if you don't want to use imenu, then just don't
>> invoke it...
>
> I was wondering the same thing, especially since the cost of making the
> imenu index is not that high.
So lets ask Jose (added to Cc).
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 19:05:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 73530 <at> debbugs.gnu.org (full text, mbox):
On Sat, Sep 28 2024, Tassilo Horn wrote:
> Visuwesh <visuweshm <at> gmail.com> writes:
>
>>>> doc-view-imenu-enabled
>>>
>>> Indeed. And while we are here: doesn anyone know why we have an
>>> option to disable imenu support? I see that we have that since Jose
>>> contributed the initial imenu support but why? I can't see any harm
>>> done if it was always enabled and would give a user-error like "For
>>> imenu support for XXX files, program YYY has to be installed" or
>>> something when invoking imenu. And why someone might want to disable
>>> it even if the required program is available is beyond my
>>> imagination. I mean, if you don't want to use imenu, then just don't
>>> invoke it...
>>
>> I was wondering the same thing, especially since the cost of making the
>> imenu index is not that high.
>
> So lets ask Jose (added to Cc).
If I recall correctly, that flag is there to save CPU cycles in case
users of doc-view are not interested in imenu.
The PDF's outline is scanned using mutool when doc-view-mode is
activated if doc-view-imenu-enabled is true, and for big files that can
take a second or two.
I am not sure why I didn't delay creation of the index, but it's
probably because there are menu entries to create and I didn't bother to
investigate deeper. Also, because I didn't want to see a pause the first
time imenu was invoked on a PDF.
Admittedly, most of the time the pause is small enough to make all of
the above moot.
Cheers,
jao
--
Many people take no care of their money till they come nearly to the end
of it, and others do just the same with their time.
-Johann Wolfgang von Goethe (1749-1832)
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 19:17:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 73530 <at> debbugs.gnu.org (full text, mbox):
jao <jao <at> gnu.org> writes:
>>>>> doc-view-imenu-enabled
>
> If I recall correctly, that flag is there to save CPU cycles in case
> users of doc-view are not interested in imenu.
>
> The PDF's outline is scanned using mutool when doc-view-mode is
> activated if doc-view-imenu-enabled is true, and for big files that
> can take a second or two.
>
> I am not sure why I didn't delay creation of the index, but it's
> probably because there are menu entries to create and I didn't bother
> to investigate deeper. Also, because I didn't want to see a pause the
> first time imenu was invoked on a PDF.
Thanks for explaining!
> Admittedly, most of the time the pause is small enough to make all of
> the above moot.
I think I'd prefer to delay the creation of the index until imenu is
invoked the first time and get rid of doc-view-imenu-enabled. If we
really wanted to and the requirements are met, we could also run the
index creation in an idle-timer. Probably not by default but maybe by
adding and documenting a function one could add to doc-view-mode-hook
for that purpose.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sat, 28 Sep 2024 19:51:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 73530 <at> debbugs.gnu.org (full text, mbox):
On Sat, Sep 28 2024, Tassilo Horn wrote:
[...]
> I think I'd prefer to delay the creation of the index until imenu is
> invoked the first time and get rid of doc-view-imenu-enabled. If we
> really wanted to and the requirements are met, we could also run the
> index creation in an idle-timer. Probably not by default but maybe by
> adding and documenting a function one could add to doc-view-mode-hook
> for that purpose.
FWIW, I'd keep doc-view-imenu-enabled, and use it to control the
creation of the idle timer. The latter sounds like the right solution to
avoid delays, and the former a much simpler strategy than asking users
to configure hooks.
I also very much like the idea of being able to tell emacs not to call
executables in my path and create other processes behind my
back. Personally, I find that ability reason enough to keep the flag,
delays or not, and, now that i think of it, that was perhaps the main
reason I introduced doc-view-imenu-enabled. Unconditionally spawning
external processes doesn't feel right to me.
Just my 2c,
jao
--
I took a speed reading course and read War and Peace in twenty
minutes. It involves Russia. -Woody Allen
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sun, 29 Sep 2024 14:05:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 73530 <at> debbugs.gnu.org (full text, mbox):
"Jose A. Ortega Ruiz" <jao <at> gnu.org> writes:
>> I think I'd prefer to delay the creation of the index until imenu is
>> invoked the first time and get rid of doc-view-imenu-enabled. If we
>> really wanted to and the requirements are met, we could also run the
>> index creation in an idle-timer. Probably not by default but maybe by
>> adding and documenting a function one could add to doc-view-mode-hook
>> for that purpose.
>
> FWIW, I'd keep doc-view-imenu-enabled, and use it to control the
> creation of the idle timer. The latter sounds like the right solution
> to avoid delays, and the former a much simpler strategy than asking
> users to configure hooks.
Also fine with me. Visuwesh, would you like to proceed in that
direction?
Thanks,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sun, 29 Sep 2024 14:36:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு செப்டம்பர் 29, 2024] Tassilo Horn wrote:
> "Jose A. Ortega Ruiz" <jao <at> gnu.org> writes:
>
>>> I think I'd prefer to delay the creation of the index until imenu is
>>> invoked the first time and get rid of doc-view-imenu-enabled. If we
>>> really wanted to and the requirements are met, we could also run the
>>> index creation in an idle-timer. Probably not by default but maybe by
>>> adding and documenting a function one could add to doc-view-mode-hook
>>> for that purpose.
>>
>> FWIW, I'd keep doc-view-imenu-enabled, and use it to control the
>> creation of the idle timer. The latter sounds like the right solution
>> to avoid delays, and the former a much simpler strategy than asking
>> users to configure hooks.
>
> Also fine with me. Visuwesh, would you like to proceed in that
> direction?
Is an idle timer necessary? Imenu calls the index function only when it
finds that the index hasn't been created yet so we can rely on that
mechanism instead. This would be simpler than using an idle timer.
WDYT?
> Thanks,
> Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sun, 29 Sep 2024 16:22:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
>>> FWIW, I'd keep doc-view-imenu-enabled, and use it to control the
>>> creation of the idle timer. The latter sounds like the right
>>> solution to avoid delays, and the former a much simpler strategy
>>> than asking users to configure hooks.
>>
>> Also fine with me. Visuwesh, would you like to proceed in that
>> direction?
>
> Is an idle timer necessary?
I don't know yet. Jose said the index building could take a little
while.
> Imenu calls the index function only when it finds that the index
> hasn't been created yet so we can rely on that mechanism instead.
> This would be simpler than using an idle timer. WDYT?
Then let's do it the simple way and then test how long the index
building actually takes on reasonable large PDFs/DjVu files.
Thanks,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sun, 29 Sep 2024 16:41:02 GMT)
Full text and
rfc822 format available.
Message #41 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[ஞாயிறு செப்டம்பர் 29, 2024] Tassilo Horn wrote:
>> Imenu calls the index function only when it finds that the index
>> hasn't been created yet so we can rely on that mechanism instead.
>> This would be simpler than using an idle timer. WDYT?
>
> Then let's do it the simple way and then test how long the index
> building actually takes on reasonable large PDFs/DjVu files.
OK, I will send an updated patch in a few days.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Sun, 29 Sep 2024 17:17:03 GMT)
Full text and
rfc822 format available.
Message #44 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Am So, 29. Sep 2024, um 18:38, schrieb Visuwesh:
> [ஞாயிறு செப்டம்பர் 29, 2024] Tassilo Horn wrote:
>
>>> Imenu calls the index function only when it finds that the index
>>> hasn't been created yet so we can rely on that mechanism instead.
>>> This would be simpler than using an idle timer. WDYT?
>>
>> Then let's do it the simple way and then test how long the index
>> building actually takes on reasonable large PDFs/DjVu files.
>
> OK, I will send an updated patch in a few days.
Great, thank you!
Tassilo
Severity set to 'wishlist' from 'normal'
Request was from
Stefan Kangas <stefankangas <at> gmail.com>
to
control <at> debbugs.gnu.org
.
(Mon, 30 Sep 2024 01:37:23 GMT)
Full text and
rfc822 format available.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Mon, 30 Sep 2024 17:32:01 GMT)
Full text and
rfc822 format available.
Message #49 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[ஞாயிறு செப்டம்பர் 29, 2024] Tassilo Horn wrote:
> Am So, 29. Sep 2024, um 18:38, schrieb Visuwesh:
>> [ஞாயிறு செப்டம்பர் 29, 2024] Tassilo Horn wrote:
>>
>>>> Imenu calls the index function only when it finds that the index
>>>> hasn't been created yet so we can rely on that mechanism instead.
>>>> This would be simpler than using an idle timer. WDYT?
>>>
>>> Then let's do it the simple way and then test how long the index
>>> building actually takes on reasonable large PDFs/DjVu files.
>>
>> OK, I will send an updated patch in a few days.
>
> Great, thank you!
Please review the attached.
[0001-Add-imenu-index-function-for-Djvu-files-in-doc-view.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Wed, 02 Oct 2024 06:44:02 GMT)
Full text and
rfc822 format available.
Message #52 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
Hi Visuwesh,
[Sorry if this message appears twice but it seems to have bounced
yesterday.]
> Please review the attached.
First of all, the patch doesn't apply on master's NEWS and misc.texi
here. If I exclude those, the changes to doc-view.el can be applied.
Unfortunately, I didn't find a PDF nor DjVu document on my computer
where an index can be built. I have the relevant tools installed but
get the message that no index can be built for that document and
doc-view--outline becomes 'unavailable.
I've tried various PDFs generated by LaTeX with many section,
subsections, etc. For DjVu, my sample size is 1, and that's a
presentation, so at least here I'm not sure if there should be an index
available...
That said, I haven't used the imenu feature before so I can't say if it
ever worked for me...
> diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
> index e19e554fb26..332d5b1468f 100644
> --- a/doc/emacs/misc.texi
> +++ b/doc/emacs/misc.texi
> @@ -581,17 +581,14 @@ DocView Navigation
> default size for DocView, customize the variable
> @code{doc-view-resolution}.
>
> -@vindex doc-view-imenu-enabled
> @vindex doc-view-imenu-flatten
> @vindex doc-view-imenu-format
> - When the @command{mutool} program is available, DocView will use it
> -to generate entries for an outline menu, making it accessible via the
> -@code{imenu} facility (@pxref{Imenu}). To disable this functionality
> -even when @command{mutool} can be found on your system, customize the
> -variable @code{doc-view-imenu-enabled} to the @code{nil} value. You
> -can further customize how @code{imenu} items are formatted and
> -displayed using the variables @code{doc-view-imenu-format} and
> -@code{doc-view-imenu-flatten}.
> + DocView can generate an outline menu for PDF and Djvu documents using
Didn't Eli say the official spelling was DjVu? That's at least the
spelling that the djvused man pages also uses and they should know.
> +the @command{mutool} and the @command{djvused} programs respectively
> +when they are available. This is made accessible via the
> @code{imenu} +facility (@pxref{Imenu}). You can customize how
> @code{imenu} items are +formatted and displayed using the variables
> @code{doc-view-imenu-format} +and @code{doc-view-imenu-flatten}.
I guess you should mention the new defcustom doc-view-djvused-program
here, too.
> +(defcustom doc-view-imenu-enabled (and (or (executable-find "mutool")
> + (executable-find "djvused"))
> + t)
> + "Whether to generate imenu outline for PDF and Djvu files.
> +This uses \"mutool\" for PDF files and \"djvused\" for Djvu files."
> :type 'boolean
> - :version "29.1")
> + :version "31.1")
> +(make-obsolete-variable 'doc-view-imenu-enabled
> + "Imenu index is generated unconditionally, when available"
> + "31.1")
Ah, I thought our last agreement was that we keep that variable (as
suggested by Jose) as it is used right now but make it possible to have
a value that tells to index only PDF or DjVu documents.
Well, I actually have no strong opinion here. Technically, I like your
approach better because of its simplicity. I would like to test with
some larger documents to see how long index building takes, though.
Anyhow, please write a complete sentence in the deprecation, so a dot at
the end. And remove the comma.
Bye,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Wed, 02 Oct 2024 08:22:01 GMT)
Full text and
rfc822 format available.
Message #55 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[புதன் அக்டோபர் 02, 2024] Tassilo Horn wrote:
> Visuwesh <visuweshm <at> gmail.com> writes:
>
> Hi Visuwesh,
>
> [Sorry if this message appears twice but it seems to have bounced
> yesterday.]
[ I did not get the previous mail FYI. ]
>> Please review the attached.
>
> First of all, the patch doesn't apply on master's NEWS and misc.texi
> here. If I exclude those, the changes to doc-view.el can be applied.
Oops, I suppose I can no longer be lazy about pulling from remote
anymore.
> Unfortunately, I didn't find a PDF nor DjVu document on my computer
> where an index can be built. I have the relevant tools installed but
> get the message that no index can be built for that document and
> doc-view--outline becomes 'unavailable.
>
> I've tried various PDFs generated by LaTeX with many section,
> subsections, etc.
The PDF generated by LaTeX can have a wildly different outline than
matched by doc-view's regexp:
% mutool show test.pdf outline
| "Text" #nameddest=section.1
| "Annotations" #nameddest=section.2
| "Links" #nameddest=section.3
| "Attachments" #nameddest=section.4
+ "Outline" #nameddest=section.5
+ "subsection" #nameddest=subsection.5.1
| "subsubsection" #nameddest=subsubsection.5.1.1
Compare it with:
% mutool show atkins_physical_chemistry.pdf outline
| "Cover" #page=1&view=Fit
| "PREFACE" #page=7&view=Fit
| "USING THE BOOK" #page=8&view=Fit
| "ABOUT THE AUTHORS" #page=12&view=Fit
| "ACKNOWLEDGEMENTS" #page=13&view=Fit
| "BRIEF CONTENTS" #page=15&view=Fit
| "FULL CONTENTS" #page=17&view=Fit
| "CONVENTIONS" #page=27&view=Fit
| "LIST OF TABLES" #page=28&view=Fit
...
> For DjVu, my sample size is 1, and that's a presentation, so at least
> here I'm not sure if there should be an index available...
I will send the link to the DjVu file that I wrote the feature for
off-list. I will send a link to a PDF file too.
> That said, I haven't used the imenu feature before so I can't say if it
> ever worked for me...
>
>> diff --git a/doc/emacs/misc.texi b/doc/emacs/misc.texi
>> index e19e554fb26..332d5b1468f 100644
>> --- a/doc/emacs/misc.texi
>> +++ b/doc/emacs/misc.texi
>> @@ -581,17 +581,14 @@ DocView Navigation
>> default size for DocView, customize the variable
>> @code{doc-view-resolution}.
>>
>> -@vindex doc-view-imenu-enabled
>> @vindex doc-view-imenu-flatten
>> @vindex doc-view-imenu-format
>> - When the @command{mutool} program is available, DocView will use it
>> -to generate entries for an outline menu, making it accessible via the
>> -@code{imenu} facility (@pxref{Imenu}). To disable this functionality
>> -even when @command{mutool} can be found on your system, customize the
>> -variable @code{doc-view-imenu-enabled} to the @code{nil} value. You
>> -can further customize how @code{imenu} items are formatted and
>> -displayed using the variables @code{doc-view-imenu-format} and
>> -@code{doc-view-imenu-flatten}.
>> + DocView can generate an outline menu for PDF and Djvu documents using
>
> Didn't Eli say the official spelling was DjVu? That's at least the
> spelling that the djvused man pages also uses and they should know.
Fixed.
>> +the @command{mutool} and the @command{djvused} programs respectively
>> +when they are available. This is made accessible via the
>> @code{imenu} +facility (@pxref{Imenu}). You can customize how
>> @code{imenu} items are +formatted and displayed using the variables
>> @code{doc-view-imenu-format} +and @code{doc-view-imenu-flatten}.
>
> I guess you should mention the new defcustom doc-view-djvused-program
> here, too.
Done.
On this note, should we use doc-view-pdfdraw-program in place of mutool
in doc-view--pdf-outline?
>> +(defcustom doc-view-imenu-enabled (and (or (executable-find "mutool")
>> + (executable-find "djvused"))
>> + t)
>> + "Whether to generate imenu outline for PDF and Djvu files.
>> +This uses \"mutool\" for PDF files and \"djvused\" for Djvu files."
>> :type 'boolean
>> - :version "29.1")
>> + :version "31.1")
>> +(make-obsolete-variable 'doc-view-imenu-enabled
>> + "Imenu index is generated unconditionally, when available"
>> + "31.1")
>
> Ah, I thought our last agreement was that we keep that variable (as
> suggested by Jose) as it is used right now but make it possible to have
> a value that tells to index only PDF or DjVu documents.
Ahh, I misunderstood the suggestion.
> Well, I actually have no strong opinion here. Technically, I like your
> approach better because of its simplicity. I would like to test with
> some larger documents to see how long index building takes, though.
I tried the function with a large PDF file:
% time mutool show atkins_physical_chemistry.pdf outline >/dev/null
0m00.32s real 0m00.30s user 0m00.02s system
% time mutool show atkins_physical_chemistry.pdf outline >/dev/null
0m00.30s real 0m00.26s user 0m00.03s system
% mutool show atkins_physical_chemistry.pdf outline |wc -l
925
% du -h atkins_physical_chemistry.pdf
97M atkins_physical_chemistry.pdf
(benchmark-run 10
(doc-view--pdf-outline "~/doc/uni/refb/atkins_physical_chemistry.pdf"))
;; => (3.0118861719999996 0 0.0)
(benchmark-run 1
(doc-view--pdf-outline "~/doc/uni/refb/atkins_physical_chemistry.pdf"))
;; => (0.306343039 0 0.0)
which honestly isn't that long a time to wait for the first time you say
M-g i.
Now for the DjVu file that I was testing on:
% time djvused -e print-outline Solid_State_Physics_Ashcroft.djvu >/dev/null
0m00.24s real 0m00.23s user 0m00.01s system
% djvused -e print-outline Solid_State_Physics_Ashcroft.djvu |wc -l
115
% du -sh Solid_State_Physics_Ashcroft.djvu
83M Solid_State_Physics_Ashcroft.djvu
(benchmark-run 10
(doc-view--djvu-outline "~/tmp/Solid_State_Physics_Ashcroft.djvu"))
;; => (2.2234427809999997 0 0.0)
(benchmark-run 1
(doc-view--djvu-outline "~/tmp/Solid_State_Physics_Ashcroft.djvu"))
;; => (0.239040117 0 0.0)
IIRC, there's a djvu file somewhere stashed in my home directory that
had an index. I can benchmark making the index for that file too if
you want.
For my init.el which has a (length imenu--index-alist) = 852,
(benchmark-run 10
(setq imenu--index-alist nil)
(imenu--make-index-alist)) ;; => (7.113529254 0 0.0)
with REPETITIONS=1, I get (0.854962398 0 0.0).
In conclusion, the waiting time is barely an inconvenience.
> Anyhow, please write a complete sentence in the deprecation, so a dot at
> the end. And remove the comma.
Done.
[0001-Add-imenu-index-function-for-DjVu-files-in-doc-view.patch (text/x-diff, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Wed, 02 Oct 2024 14:56:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
>> Unfortunately, I didn't find a PDF nor DjVu document on my computer
>> where an index can be built. I have the relevant tools installed but
>> get the message that no index can be built for that document and
>> doc-view--outline becomes 'unavailable.
>>
>> I've tried various PDFs generated by LaTeX with many section,
>> subsections, etc.
>
> The PDF generated by LaTeX can have a wildly different outline than
> matched by doc-view's regexp:
>
> % mutool show test.pdf outline
> | "Text" #nameddest=section.1
> | "Annotations" #nameddest=section.2
>
> Compare it with:
>
> % mutool show atkins_physical_chemistry.pdf outline
> | "Cover" #page=1&view=Fit
> | "PREFACE" #page=7&view=Fit
> | "USING THE BOOK" #page=8&view=Fit
Ok, I see. All my LaTeX PDFs have #nameddest=section.x values instead
of #page=X values, so that's the reason they don't work. It would be
good if we could mention that it won't work because there are no page
references in the outline in the error message.
>> For DjVu, my sample size is 1, and that's a presentation, so at least
>> here I'm not sure if there should be an index available...
>
> I will send the link to the DjVu file that I wrote the feature for
> off-list. I will send a link to a PDF file too.
Thanks, will try with those two files.
> On this note, should we use doc-view-pdfdraw-program in place of mutool
> in doc-view--pdf-outline?
Yes, but only if the older names pdfdraw and mudraw already had the
"show <file> outline" feature.
>> Well, I actually have no strong opinion here. Technically, I like
>> your approach better because of its simplicity. I would like to test
>> with some larger documents to see how long index building takes,
>> though.
>
> I tried the function with a large PDF file:
Will try with the large two you've linked later.
Thanks,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Thu, 03 Oct 2024 08:39:02 GMT)
Full text and
rfc822 format available.
Message #61 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Tassilo Horn <tsdh <at> gnu.org> writes:
Hi again,
>> The PDF generated by LaTeX can have a wildly different outline than
>> matched by doc-view's regexp:
>>
>> % mutool show test.pdf outline
>> | "Text" #nameddest=section.1
>> | "Annotations" #nameddest=section.2
>>
>> Compare it with:
>>
>> % mutool show atkins_physical_chemistry.pdf outline
>> | "Cover" #page=1&view=Fit
>> | "PREFACE" #page=7&view=Fit
>> | "USING THE BOOK" #page=8&view=Fit
>
> Ok, I see. All my LaTeX PDFs have #nameddest=section.x values instead
> of #page=X values, so that's the reason they don't work. It would be
> good if we could mention that it won't work because there are no page
> references in the outline in the error message.
Would you mind doing that in a new version of the patch?
And I wonder if it mutool could spit out page references in addition to
the nameddest references. Do you know if there's a technical limitation
or if it's just not implemented?
Sadly, their communication platform seems to be Discord where I didn't
want to register an account to ask. They seem to use the ghostscript
bugzilla, so one could create a ticket there... If nobody else here in
the discussion already has an account there, I wouldn't mind creating
ony myself and asking.
>>> For DjVu, my sample size is 1, and that's a presentation, so at least
>>> here I'm not sure if there should be an index available...
>>
>> I will send the link to the DjVu file that I wrote the feature for
>> off-list. I will send a link to a PDF file too.
>
> Thanks, will try with those two files.
I did so now and it is blazingly fast for those 80+mb PDF/DjVu files
even on my almost 10 years old laptop, so I'd say your simpler approach
is the right choice.
>> On this note, should we use doc-view-pdfdraw-program in place of
>> mutool in doc-view--pdf-outline?
>
> Yes, but only if the older names pdfdraw and mudraw already had the
> "show <file> outline" feature.
I revert the "but only if" part. If mupdf is old and comes with, e.g.,
the pdfdraw executable, chances are almost zero that mutool is
installed, too. And if it is, then we should prefer it anywhere. So I
think the way to go is to (executable-find "mutool") in
doc-view-pdfdraw-program first so that it takes precedence and use
doc-view-pdfdraw-program in doc-view--pdf-outline.
>>> Well, I actually have no strong opinion here. Technically, I like
>>> your approach better because of its simplicity. I would like to test
>>> with some larger documents to see how long index building takes,
>>> though.
>>
>> I tried the function with a large PDF file:
>
> Will try with the large two you've linked later.
As said above, it's more than fast enough, so let's take your approach.
Thanks,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Thu, 03 Oct 2024 11:12:02 GMT)
Full text and
rfc822 format available.
Message #64 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[வியாழன் அக்டோபர் 03, 2024] Tassilo Horn wrote:
> Tassilo Horn <tsdh <at> gnu.org> writes:
>
> Hi again,
>
>>> The PDF generated by LaTeX can have a wildly different outline than
>>> matched by doc-view's regexp:
>>>
>>> % mutool show test.pdf outline
>>> | "Text" #nameddest=section.1
>>> | "Annotations" #nameddest=section.2
>>>
>>> Compare it with:
>>>
>>> % mutool show atkins_physical_chemistry.pdf outline
>>> | "Cover" #page=1&view=Fit
>>> | "PREFACE" #page=7&view=Fit
>>> | "USING THE BOOK" #page=8&view=Fit
>>
>> Ok, I see. All my LaTeX PDFs have #nameddest=section.x values instead
>> of #page=X values, so that's the reason they don't work. It would be
>> good if we could mention that it won't work because there are no page
>> references in the outline in the error message.
>
> Would you mind doing that in a new version of the patch?
>
> And I wonder if it mutool could spit out page references in addition to
> the nameddest references. Do you know if there's a technical limitation
> or if it's just not implemented?
Unfortunately, I have no idea. I actually don't use doc-view for PDF
files, only for docx and DjVu.
> Sadly, their communication platform seems to be Discord where I didn't
> want to register an account to ask. They seem to use the ghostscript
> bugzilla, so one could create a ticket there... If nobody else here in
> the discussion already has an account there, I wouldn't mind creating
> ony myself and asking.
If I cannot find anything in the man page, I can ask in their Discord.
I do have an account lying around, I can at least put it to good use.
Can this be done in another patch later on? I am not sure if I will get
the time soon to follow up on this part of the problem. It would be
cleaner if we open another bug report to track this too.
>>>> For DjVu, my sample size is 1, and that's a presentation, so at least
>>>> here I'm not sure if there should be an index available...
>>>
>>> I will send the link to the DjVu file that I wrote the feature for
>>> off-list. I will send a link to a PDF file too.
>>
>> Thanks, will try with those two files.
>
> I did so now and it is blazingly fast for those 80+mb PDF/DjVu files
> even on my almost 10 years old laptop, so I'd say your simpler approach
> is the right choice.
>
>>> On this note, should we use doc-view-pdfdraw-program in place of
>>> mutool in doc-view--pdf-outline?
>>
>> Yes, but only if the older names pdfdraw and mudraw already had the
>> "show <file> outline" feature.
>
> I revert the "but only if" part. If mupdf is old and comes with, e.g.,
> the pdfdraw executable, chances are almost zero that mutool is
> installed, too. And if it is, then we should prefer it anywhere. So I
> think the way to go is to (executable-find "mutool") in
> doc-view-pdfdraw-program first so that it takes precedence and use
> doc-view-pdfdraw-program in doc-view--pdf-outline.
OK, I will post a patch if you're okay with opening another bug report
for the nameddest PDF thingy.
>>>> Well, I actually have no strong opinion here. Technically, I like
>>>> your approach better because of its simplicity. I would like to test
>>>> with some larger documents to see how long index building takes,
>>>> though.
>>>
>>> I tried the function with a large PDF file:
>>
>> Will try with the large two you've linked later.
>
> As said above, it's more than fast enough, so let's take your approach.
Great, thank you for taking the time to test the patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Thu, 03 Oct 2024 12:13:01 GMT)
Full text and
rfc822 format available.
Message #67 received at 73530 <at> debbugs.gnu.org (full text, mbox):
Hi again,
of course we should do the nameddest thing in another patch. No reason to put this one on hold.
Thanks,
Tassilo
Am Do, 3. Okt 2024, um 13:10, schrieb Visuwesh:
> [வியாழன் அக்டோபர் 03, 2024] Tassilo Horn wrote:
>
>> Tassilo Horn <tsdh <at> gnu.org> writes:
>>
>> Hi again,
>>
>>>> The PDF generated by LaTeX can have a wildly different outline than
>>>> matched by doc-view's regexp:
>>>>
>>>> % mutool show test.pdf outline
>>>> | "Text" #nameddest=section.1
>>>> | "Annotations" #nameddest=section.2
>>>>
>>>> Compare it with:
>>>>
>>>> % mutool show atkins_physical_chemistry.pdf outline
>>>> | "Cover" #page=1&view=Fit
>>>> | "PREFACE" #page=7&view=Fit
>>>> | "USING THE BOOK" #page=8&view=Fit
>>>
>>> Ok, I see. All my LaTeX PDFs have #nameddest=section.x values instead
>>> of #page=X values, so that's the reason they don't work. It would be
>>> good if we could mention that it won't work because there are no page
>>> references in the outline in the error message.
>>
>> Would you mind doing that in a new version of the patch?
>>
>> And I wonder if it mutool could spit out page references in addition to
>> the nameddest references. Do you know if there's a technical limitation
>> or if it's just not implemented?
>
> Unfortunately, I have no idea. I actually don't use doc-view for PDF
> files, only for docx and DjVu.
>
>> Sadly, their communication platform seems to be Discord where I didn't
>> want to register an account to ask. They seem to use the ghostscript
>> bugzilla, so one could create a ticket there... If nobody else here in
>> the discussion already has an account there, I wouldn't mind creating
>> ony myself and asking.
>
> If I cannot find anything in the man page, I can ask in their Discord.
> I do have an account lying around, I can at least put it to good use.
>
> Can this be done in another patch later on? I am not sure if I will get
> the time soon to follow up on this part of the problem. It would be
> cleaner if we open another bug report to track this too.
>
>>>>> For DjVu, my sample size is 1, and that's a presentation, so at least
>>>>> here I'm not sure if there should be an index available...
>>>>
>>>> I will send the link to the DjVu file that I wrote the feature for
>>>> off-list. I will send a link to a PDF file too.
>>>
>>> Thanks, will try with those two files.
>>
>> I did so now and it is blazingly fast for those 80+mb PDF/DjVu files
>> even on my almost 10 years old laptop, so I'd say your simpler approach
>> is the right choice.
>>
>>>> On this note, should we use doc-view-pdfdraw-program in place of
>>>> mutool in doc-view--pdf-outline?
>>>
>>> Yes, but only if the older names pdfdraw and mudraw already had the
>>> "show <file> outline" feature.
>>
>> I revert the "but only if" part. If mupdf is old and comes with, e.g.,
>> the pdfdraw executable, chances are almost zero that mutool is
>> installed, too. And if it is, then we should prefer it anywhere. So I
>> think the way to go is to (executable-find "mutool") in
>> doc-view-pdfdraw-program first so that it takes precedence and use
>> doc-view-pdfdraw-program in doc-view--pdf-outline.
>
> OK, I will post a patch if you're okay with opening another bug report
> for the nameddest PDF thingy.
>
>>>>> Well, I actually have no strong opinion here. Technically, I like
>>>>> your approach better because of its simplicity. I would like to test
>>>>> with some larger documents to see how long index building takes,
>>>>> though.
>>>>
>>>> I tried the function with a large PDF file:
>>>
>>> Will try with the large two you've linked later.
>>
>> As said above, it's more than fast enough, so let's take your approach.
>
> Great, thank you for taking the time to test the patch.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Thu, 03 Oct 2024 14:53:02 GMT)
Full text and
rfc822 format available.
Message #70 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
[வியாழன் அக்டோபர் 03, 2024] Tassilo Horn wrote:
>>>> For DjVu, my sample size is 1, and that's a presentation, so at least
>>>> here I'm not sure if there should be an index available...
>>>
>>> I will send the link to the DjVu file that I wrote the feature for
>>> off-list. I will send a link to a PDF file too.
>>
>> Thanks, will try with those two files.
>
> I did so now and it is blazingly fast for those 80+mb PDF/DjVu files
> even on my almost 10 years old laptop, so I'd say your simpler approach
> is the right choice.
>
>>> On this note, should we use doc-view-pdfdraw-program in place of
>>> mutool in doc-view--pdf-outline?
>>
>> Yes, but only if the older names pdfdraw and mudraw already had the
>> "show <file> outline" feature.
>
> I revert the "but only if" part. If mupdf is old and comes with, e.g.,
> the pdfdraw executable, chances are almost zero that mutool is
> installed, too. And if it is, then we should prefer it anywhere. So I
> think the way to go is to (executable-find "mutool") in
> doc-view-pdfdraw-program first so that it takes precedence and use
> doc-view-pdfdraw-program in doc-view--pdf-outline.
>
>>>> Well, I actually have no strong opinion here. Technically, I like
>>>> your approach better because of its simplicity. I would like to test
>>>> with some larger documents to see how long index building takes,
>>>> though.
>>>
>>> I tried the function with a large PDF file:
>>
>> Will try with the large two you've linked later.
>
> As said above, it's more than fast enough, so let's take your approach.
I have now attached a patch with the above change.
[0001-Add-imenu-index-function-for-DjVu-files-in-doc-view.patch (text/x-diff, attachment)]
Reply sent
to
Tassilo Horn <tsdh <at> gnu.org>
:
You have taken responsibility.
(Fri, 04 Oct 2024 05:35:01 GMT)
Full text and
rfc822 format available.
Notification sent
to
Visuwesh <visuweshm <at> gmail.com>
:
bug acknowledged by developer.
(Fri, 04 Oct 2024 05:35:02 GMT)
Full text and
rfc822 format available.
Message #75 received at 73530-done <at> debbugs.gnu.org (full text, mbox):
Visuwesh <visuweshm <at> gmail.com> writes:
>> As said above, it's more than fast enough, so let's take your approach.
>
> I have now attached a patch with the above change.
Applied and pushed to master. I'm closing this issue.
Thanks a lot,
Tassilo
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#73530
; Package
emacs
.
(Fri, 04 Oct 2024 07:34:02 GMT)
Full text and
rfc822 format available.
Message #78 received at 73530 <at> debbugs.gnu.org (full text, mbox):
[வெள்ளி அக்டோபர் 04, 2024] Tassilo Horn wrote:
> Visuwesh <visuweshm <at> gmail.com> writes:
>
>>> As said above, it's more than fast enough, so let's take your approach.
>>
>> I have now attached a patch with the above change.
>
> Applied and pushed to master. I'm closing this issue.
Great, thank you!
bug archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 01 Nov 2024 11:24:08 GMT)
Full text and
rfc822 format available.
This bug report was last modified 227 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.