bug#55900: [PATCH] Hierarchy – Defer the Computation of Children

[Jaft]

Hmm; I tried to attach the patch with Gnus but it doesn't look like it actually 
added it…. Sending again, via the browser this time.






 On Sunday, June 12, 2022, 04:01:29 AM CDT, Wamm K. D. <jaft.r@outlook.com> 
wrote: 
> On Sat. (Jun 11, 2022) at 04:21:59 AM -04, Eli Zaretskii <eliz@gnu.org> wrote:
>>> From: "Wamm K. D." <jaft.r@outlook.com>
>>> Date: Sat, 11 Jun 2022 01:52:13 -0500
>>> 
>>> Pretty much as the subject describes; this should allow for users to
>>> lazily load hierarchy branches when loading everything at once would
>>> otherwise be too consuming, up-front (or if dealing with an infinite
>>> tree).
>>
>> Thanks.
>>
>>> * lisp/emacs-lisp/hierarchy.el (hierarchy-add-tree) (hierarchy-add-trees):
>>> Add parameter 'delay-children-p'.
>>
>> Please use our style of commit log messages.  The above should be
>>
>> * lisp/emacs-lisp/hierarchy.el (hierarchy-add-tree)
>> (hierarchy-add-trees): Add parameter 'delay-children-p'.
>
> Mmm; gotcha. This hadn't been clear, to me; I thought the example given
> in the CONTRIBUTE file was that way because the line was long and the
> main point of its demonstration was what to do with a case of more than
> one function. I've adjusted the commit message appropriately, now.
>
>>> +(defun hierarchy--create-delayed-tree-widget (elem labelfn indent fn)
>>> +  "Return a list of tree-widgets for a hierarchy created from the 
>>> childrenfn.
>>
>> The first line of the doc string should ideally mention the
>> arguments.  This one doesn't, and it also seems to misname one
>> argument: it's FN, not childrenfn, right?
>
> Yeah; I was referencing the fact that this function is called childrenfn
> in a bunch of other functions but, for whatever reason, I didn't call it
> that here so that's why it isn't all-capitalized (while the reference to
> it, at the end, is and says FN). But that's weird; I don't know why I
> went with that name when I could've just…used the same name as every
> other function. I've corrected that, standardized.
>
>> Can you add some tests of this new functionality?
>
> I've added some; I didn't created tests for children functionality since
> the delayed computation means there aren't children (until someone
> activates the tree-widget and the children are computed with the
> provided function) but I create some tests to check that the root and
> parent elements were still functioning as expected, when using delayed
> children.
>
>> Also, I think this warrants a NEWS entry to describe the new feature.
>
> I've added that, as well.

0001-Allow-Hierarchy-to-delay-computing-children.patch
Description: Text Data