bug#73533: [PATCH] Rewrite speedbar expansion for all descendants

[Eli Zaretskii <eliz@gnu.org>]

> From: Morgan Willcock <morgan@ice9.digital>
> Cc: 73533@debbugs.gnu.org
> Date: Sat, 19 Oct 2024 18:30:13 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > There seems to be still a problem with some files, in that
> > speedbar-expand-line-descendants takes a very long time, and if I
> > interrupt it with C-g, I see nested DEFUNs, something that shouldn't
> > happen, because DEFUNs are never nested.  E.g., try this:
> >
> >  $ cd /path/to/emacs/src
> >  $ ./emacs -Q
> >  M-x speedbar RET
> >
> > At this point you should see all the files in the Emacs src directory.
> > Go to androidfns.c and type '['.  After about 10 sec type C-g.  You
> > should see nested DEFUns in the Speedbar frame.
> >
> > Could you please look into this?
> 
> This looks like an unrelated issue where the logic to modify the item
> hierarchy does not make sense under certain conditions.  It only seems
> to trigger when particular limits are met, but the limits can be lowered
> for an easier demonstration:
> 
>   (require 'speedbar)
>   (setq speedbar-tag-regroup-maximum-length 2)
>   (setq speedbar-tag-split-minimum-length 2)
> 
>   (speedbar-prefix-group-tag-hierarchy
>    '(("DEFUN" . 1)
>      ("DEFUN" . 5)
>      ("DEFUN" . 10)))
> 
>   => (("DEFUN" ("DEFUN" . 1) ("DEFUN" . 5) ("DEFUN" . 10)))
> 
> i.e. speedbar-prefix-group-tag-hierarchy (which is meant to restructure
> the Imenu data to make better use of the available space in the
> Speedbar) is generating a new parent item which contains the items that
> were meant to be inserted.
> 
> It is probably best to open a separate bug report for this because
> working out exactly how and why speedbar-prefix-group-tag-hierarchy
> applies particular sorting actions will probably take someone a while.

Done, and closing.

Thanks.