Organizing clone-find results

[Edward K. Ream]

Yesterday I discovered/invented a simple, important, way of organizing the results of clone-find searches.  The pattern is:

- --- name of search (an organizer node) (--- highlights the organizer node)
  - (clone) The node defining a method.
  - The result of the clone-find command, renamed NN calls to (the method)

For example:

- --- c.getBodyLines (helper: body.getSelectionLines)
  - (clone) c.getBodyLines
  - 10 Calls to getBodyLines

 The last node contains clones of all calls to c.getBodyLines.

The following tree helped me to understand that most of Leo's body-changing command eventually funneled through u.setUndoTypingParams:

- ----- Simplify body logic
  - --- c.getBodyLines (helper: body.getSelectionLines)
  - --- c.updateBodyPane (calls onBodyChanged)
  - --- LeoBody.onBodyChanged (calls setUndoTypingParams)
  - --- u.setUndoTypingParams (called by qtm.onTextChanged)

Each of the "---" organizer node contains children as shown above.

What's the big deal, you ask?

The "extra" level of organizer nodes (the --- nodes) allow for summarizing data in the headlines without changing any of the actual code nodes. Sure, body text of the --- nodes could contain more summary info, but being able to see the overall structure in just the outlines was important. With the big picture always visible, I could expand any --- node to see the method and the calls to it.

Summary

The pattern shown above revealed that many of Leo's body-changing commands eventually call u.setUndoTypingParams. It also shows that u.setUndoTypingParams is actually a callback for onTextChanged Qt events.

Without this pattern I struggled to understand the relationships between the various methods. With this method, everything suddenly became clearer.

HTH.

Edward

P.S. Today's post re undo convinces me that I won't attempt to remove kwargs from c.getBodyLines, c.updateBodyPane, LeoBody.onBodyChanged or u.setUndoTypingParams.

You could say that all of these methods are deprecated in favor of the upcoming u.before/afterChangeBody methods. Leo would not be greatly improved by eliminating the deprecated methods. There are many more important projects to do!

As a result, I have have added "(won't do)" to the node "----- Simplify body logic" :-) The only remaining task is to create and document u.before/afterChangeBody.

EKR