bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Severity: wishlist

It'd be great if imenu supported displaying its alist of entries in a
separate buffer.  This is particularly useful when the list of entries
has many levels (for example, it is the table of contents of a PDF,
supported in Emacs 29), because you could search for an entry very
easily.  Right now, pressing C-s in the minibuffer only searches for
first-level imenu entries.

I suggest the new buffer would be configured in outline-mode, which is
suited for this kind of hierarchical content.

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Severity: wishlist
>
> It'd be great if imenu supported displaying its alist of entries in a
> separate buffer.  This is particularly useful when the list of entries

Something like imenu-list in MELPA?  That should be in Emacs core.

> has many levels (for example, it is the table of contents of a PDF,
> supported in Emacs 29), because you could search for an entry very

Really?  I'm on Emacs 29, and in DocView Mode I get the following error:
imenu unavailable: "This buffer cannot use
‘imenu-default-create-index-function’".

> easily.  Right now, pressing C-s in the minibuffer only searches for
> first-level imenu entries.
>
> I suggest the new buffer would be configured in outline-mode, which is
> suited for this kind of hierarchical content.
>
>
>

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social, and on Codeberg (user
"akib").

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 1145 bytes --]

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

> Severity: wishlist
>
> It'd be great if imenu supported displaying its alist of entries in a
> separate buffer.  This is particularly useful when the list of entries

Something like imenu-list in MELPA?  That should be in Emacs core.

> has many levels (for example, it is the table of contents of a PDF,
> supported in Emacs 29), because you could search for an entry very

Really?  I'm on Emacs 29, and in DocView Mode I get the following error:
imenu unavailable: "This buffer cannot use
‘imenu-default-create-index-function’".

> easily.  Right now, pressing C-s in the minibuffer only searches for
> first-level imenu entries.
>
> I suggest the new buffer would be configured in outline-mode, which is
> suited for this kind of hierarchical content.
>
>
>

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social, and on Codeberg (user
"akib").

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Akib Azmain Turja <akib@disroot.org> writes:

>> Severity: wishlist
>>
>> It'd be great if imenu supported displaying its alist of entries in a
>> separate buffer.  This is particularly useful when the list of entries
>
> Something like imenu-list in MELPA?  That should be in Emacs core.
>

Yes, it'd be great to have something like that (perhaps simpler and less
opinionated) as an extension to imenu.  Or the feature can live as a
ELPA/Non-GNU ELPA package, I don't know.

>> has many levels (for example, it is the table of contents of a PDF,
>> supported in Emacs 29), because you could search for an entry very
>
> Really?  I'm on Emacs 29, and in DocView Mode I get the following error:
> imenu unavailable: "This buffer cannot use
> ‘imenu-default-create-index-function’".
>

Do you have mupdf/mutool installed?  It is a prerequisite for the PDF
outline feature to work.  If you have that CLI installed, then please
report it as a separate bug so we can investigate it.

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Akib Azmain Turja via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 882 bytes --]

Daniel Martín via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@gnu.org> writes:

>> Really?  I'm on Emacs 29, and in DocView Mode I get the following error:
>> imenu unavailable: "This buffer cannot use
>> ‘imenu-default-create-index-function’".
>>
>
> Do you have mupdf/mutool installed?  It is a prerequisite for the PDF
> outline feature to work.  If you have that CLI installed, then please
> report it as a separate bug so we can investigate it.

I have that install now.  But still no imenu.  Isearch in doc-view.el
finds no match.  When was the feature added?  Within last two months?

-- 
Akib Azmain Turja

Find me on Mastodon at @akib@hostux.social, and on Codeberg (user
"akib").

This message is signed by me with my GnuPG key.  Its fingerprint is:

    7001 8CE5 819F 17A3 BBA6  66AF E74F 0EFA 922A E7F5

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Akib Azmain Turja via "Bug reports for GNU Emacs, the Swiss army knife
of text editors" <bug-gnu-emacs@gnu.org> writes:

>
> I have that install now.  But still no imenu.  Isearch in doc-view.el
> finds no match.  When was the feature added?  Within last two months?

Yes, the feature is less than a month old.  Here's the commit that
introduced it:

commit b1c1ff9ee110a9fe739dc4407468f3e9b819484c
Author: Jose A. Ortega Ruiz <jao@gnu.org>
Date:   Tue Sep 27 13:53:24 2022 +0200

    docview: imenu access to table of contents

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Juri Linkov]

> It'd be great if imenu supported displaying its alist of entries in a
> separate buffer.  This is particularly useful when the list of entries
> has many levels (for example, it is the table of contents of a PDF,

Unfortunately, mupdf/mutool doesn't support Unicode characters:
https://bugs.ghostscript.com/show_bug.cgi?id=702358
Maybe doc-view--pdf-outline could post-process the output
to replace hex-encoded numbers with their character equivalents?

> supported in Emacs 29), because you could search for an entry very
> easily.  Right now, pressing C-s in the minibuffer only searches for
> first-level imenu entries.
>
> I suggest the new buffer would be configured in outline-mode, which is
> suited for this kind of hierarchical content.

The problem is that imenu-submenus-on-top is t by default,
but such order is incompatible with the outline-mode trees.
For example, all functions belong to the Variables outline:

* Types
  imenu
  imenu-unavailable
* Variables
  imenu-after-jump-hook
  imenu-auto-rescan
  imenu-auto-rescan-maxout
  ...
imenu
imenu--cleanup
imenu--completion-buffer
imenu--create-keymap
...

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Jose A. Ortega Ruiz]

On Wed, Oct 19 2022, Juri Linkov wrote:

>> It'd be great if imenu supported displaying its alist of entries in a
>> separate buffer.  This is particularly useful when the list of entries
>> has many levels (for example, it is the table of contents of a PDF,
>
> Unfortunately, mupdf/mutool doesn't support Unicode characters:
> https://bugs.ghostscript.com/show_bug.cgi?id=702358
> Maybe doc-view--pdf-outline could post-process the output
> to replace hex-encoded numbers with their character equivalents?

i wasn't aware of this mutool limitation when i wrote that function; if
the encoding is good enough, yes, we could do that: i'll send a patch,
unless someone already did.  hmmm, do somebody have a good example of a
PDF with lots of unicode in its section titles?

>
>> supported in Emacs 29), because you could search for an entry very
>> easily.  Right now, pressing C-s in the minibuffer only searches for
>> first-level imenu entries.
>>
>> I suggest the new buffer would be configured in outline-mode, which is
>> suited for this kind of hierarchical content.
>
> The problem is that imenu-submenus-on-top is t by default,

that seems minor... one could always regenerate the index with
imenu-submenus-on-top set to nil when the export is requested?

jao
-- 
There are two hard things in computer science: cache invalidation,
naming things, and off-by-one errors.

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Stephen Berman]

On Wed, 19 Oct 2022 22:35:19 +0100 "Jose A. Ortega Ruiz" <jao@gnu.org> wrote:

> On Wed, Oct 19 2022, Juri Linkov wrote:
>
>>> It'd be great if imenu supported displaying its alist of entries in a
>>> separate buffer.  This is particularly useful when the list of entries
>>> has many levels (for example, it is the table of contents of a PDF,
>>
>> Unfortunately, mupdf/mutool doesn't support Unicode characters:
>> https://bugs.ghostscript.com/show_bug.cgi?id=702358
>> Maybe doc-view--pdf-outline could post-process the output
>> to replace hex-encoded numbers with their character equivalents?
>
> i wasn't aware of this mutool limitation when i wrote that function; if
> the encoding is good enough, yes, we could do that: i'll send a patch,
> unless someone already did.  hmmm, do somebody have a good example of a
> PDF with lots of unicode in its section titles?

That bug is marked as fixed since 2020-05-07.  And indeed, using
mupdf-1.19.0, when I execute the recipe given in the bug report
non-ASCII UTF-8 encoded characters are correctly displayed.

Steve Berman

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Daniel Martín via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Juri Linkov <juri@linkov.net> writes:

>
> Unfortunately, mupdf/mutool doesn't support Unicode characters:
> https://bugs.ghostscript.com/show_bug.cgi?id=702358
> Maybe doc-view--pdf-outline could post-process the output
> to replace hex-encoded numbers with their character equivalents?
>

Do you mean for old versions of mupdf?  IIUC, recent versions of mupdf
already do the right thing: They decode the runes (Unicode codepoints)
from the byte string and encode them in UTF-8, verbatim.  Only control
characters are hex-encoded.  I've opened in Emacs the PDF attached to
the mupdf bug report and it displays the outline correctly (mutool
version 1.19.0).

>
> The problem is that imenu-submenus-on-top is t by default,
> but such order is incompatible with the outline-mode trees.
> For example, all functions belong to the Variables outline:
>
> * Types
>   imenu
>   imenu-unavailable
> * Variables
>   imenu-after-jump-hook
>   imenu-auto-rescan
>   imenu-auto-rescan-maxout
>   ...
> imenu
> imenu--cleanup
> imenu--completion-buffer
> imenu--create-keymap
> ...

That's a good point.  Perhaps we need to create a special mode to
display the imenu hierarchy.

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Jose A. Ortega Ruiz]

On Wed, Oct 19 2022, Jose A. Ortega Ruiz wrote:

[...]

>> The problem is that imenu-submenus-on-top is t by default,
>
> that seems minor... one could always regenerate the index with
> imenu-submenus-on-top set to nil when the export is requested?

and forgot to add: in doc-view-mode we set already its local buffer
value to nil (otherwise the generated outline makes no sense), so at
least in one of the use cases that's never a problem.

cheers,
jao
-- 
The rightness of a thing isn't determined by the amount of courage
it takes. -Mary Renault, novelist (1905-1983)

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Juri Linkov]

>>> Unfortunately, mupdf/mutool doesn't support Unicode characters:
>>> https://bugs.ghostscript.com/show_bug.cgi?id=702358
>>> Maybe doc-view--pdf-outline could post-process the output
>>> to replace hex-encoded numbers with their character equivalents?
>>
>> i wasn't aware of this mutool limitation when i wrote that function; if
>> the encoding is good enough, yes, we could do that: i'll send a patch,
>> unless someone already did.  hmmm, do somebody have a good example of a
>> PDF with lots of unicode in its section titles?
>
> That bug is marked as fixed since 2020-05-07.  And indeed, using
> mupdf-1.19.0, when I execute the recipe given in the bug report
> non-ASCII UTF-8 encoded characters are correctly displayed.

Good news!  I'm still using mupdf-1.16, but since it's fixed in mupdf-1.19
then maybe a special handling in doc-view is not needed.

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Juri Linkov]

>>> The problem is that imenu-submenus-on-top is t by default,
>>
>> that seems minor... one could always regenerate the index with
>> imenu-submenus-on-top set to nil when the export is requested?
>
> and forgot to add: in doc-view-mode we set already its local buffer
> value to nil (otherwise the generated outline makes no sense), so at
> least in one of the use cases that's never a problem.

Indeed, setting it locally to nil will solve this problem.

bug#58532: 29.0.50; Support displaying imenu entries in a separate buffer

[Juri Linkov]

>> The problem is that imenu-submenus-on-top is t by default,
>> but such order is incompatible with the outline-mode trees.
>> For example, all functions belong to the Variables outline:
>>
>> * Types
>>   imenu
>>   imenu-unavailable
>> * Variables
>>   imenu-after-jump-hook
>>   imenu-auto-rescan
>>   imenu-auto-rescan-maxout
>>   ...
>> imenu
>> imenu--cleanup
>> imenu--completion-buffer
>> imenu--create-keymap
>> ...
>
> That's a good point.  Perhaps we need to create a special mode to
> display the imenu hierarchy.

This problem occurs only when MENU-TITLE is nil in imenu-generic-expression.
We could invent a fictitious outline heading for such empty titles, e.g.
"All" or "Other".  Then it will have own outline:

* Types
  imenu
  imenu-unavailable
* Variables
  imenu-after-jump-hook
  imenu-auto-rescan
  imenu-auto-rescan-maxout
  ...
* Other
  imenu
  imenu--cleanup
  imenu--completion-buffer
  imenu--create-keymap
  ...