GNU bug report logs - #73533
[PATCH] Rewrite speedbar expansion for all descendants

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#73533: closed ([PATCH] Rewrite speedbar expansion for all
 descendants)
Date: Sat, 19 Oct 2024 17:43:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sat, 19 Oct 2024 20:41:37 +0300
with message-id <86msj0j8ha.fsf <at> gnu.org>
and subject line Re: bug#73533: [PATCH] Rewrite speedbar expansion for all descendants
has caused the debbugs.gnu.org bug report #73533,
regarding [PATCH] Rewrite speedbar expansion for all descendants
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
73533: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=73533
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Morgan Willcock <morgan <at> ice9.digital>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] Rewrite speedbar expansion for all descendants
Date: Sat, 28 Sep 2024 20:05:26 +0100

[Message part 3 (text/plain, inline)]

Tags: patch

Attached is a patch which rewrites 'speedbar-expand-line-descendants'.

The previous version could get into an infinite loop by reaching the
maximum recursion depth, although in practice the slow speed meant that
most people would probably abort the operation before reaching that
point.

The majority of the slowdown was because the motion commands being used
were the variants which looked up information for every entry, displayed
the information as a message, and adjusted the cursor position.  The
messages were not readable because of being continually overwritten.

Here is a way to demonstrate that stack depth was increasing for items
at the same level, that the messages were not readable, and how slow the
whole process was:

  rm -rf /tmp/project
  mkdir /tmp/project
  for i in $(seq 1 50); do echo "(defun fun-$i ())" >> /tmp/project/file1.el; done
  for i in $(seq 1 50); do echo "(defun fun-$i ())" >> /tmp/project/file2.el; done
  emacs -Q \
        --eval="(find-file \"/tmp/project/file1.el\")" \
        --eval "(speedbar-get-focus)" \
        --eval "(profiler-start 'cpu)" \
        --eval "(speedbar-expand-line-descendants)" \
        --eval "(profiler-stop)" \
        --eval "(profiler-report)"

...that should expand every entry in file1.el and not touch the entries
in file2.el.

The replacement function is significantly faster.  Messages are only
used to indicate that the function is running and when it is finished -
the result is similar to manually clicking every node open.

Thanks,
Morgan


In GNU Emacs 30.0.91 (build 2, x86_64-pc-linux-gnu, X toolkit, cairo
 version 1.16.0, Xaw3d scroll bars) of 2024-09-12 built on inspiron
Windowing system distributor 'The X.Org Foundation', version 11.0.12101007
System Description: Debian GNU/Linux 12 (bookworm)

Configured using:
 'configure --with-native-compilation=aot --with-xml2
 --with-x-toolkit=lucid'

[0001-Rewrite-speedbar-expansion-for-all-descendants.patch (text/patch, attachment)]

[Message part 5 (message/rfc822, inline)]

From: Eli Zaretskii <eliz <at> gnu.org>
To: Morgan Willcock <morgan <at> ice9.digital>
Cc: 73533-done <at> debbugs.gnu.org
Subject: Re: bug#73533: [PATCH] Rewrite speedbar expansion for all descendants
Date: Sat, 19 Oct 2024 20:41:37 +0300

> From: Morgan Willcock <morgan <at> ice9.digital>
> Cc: 73533 <at> debbugs.gnu.org
> Date: Sat, 19 Oct 2024 18:30:13 +0100
> 
> Eli Zaretskii <eliz <at> 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.

Previous Next

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