OMG: c.deletePositionsInList is way easier than we thought!

[Edward K. Ream]

PR #4567 is a milestone. Early this morning, I completed work on a different PR, PR #4566. That other work got me thinking about a topic that we all thought was inherently tricky: deleting an arbitrary list of positions from the outline.

As I write this, I see why I made the connection. The first PR uses a simple iterative loop. I wondered whether an iterative approach could simplify c.deletePositionsInList, one of Leo’s most complex script helpers.

I succeeded beyond my wildest hopes. Not only is c.deletePositionsInList way simpler than before, but it also easily supports undo! The new PR makes c.undoableDeletePositions an alias for c.deletePositionsInList.

The new code:

- Uses only high-level position methods, not low-level vnode methods.

- Deletes only valid positions without having to sort the to-be-deleted positions.

The algorithm combines, in an utterly simple and intuitive way, iterative and recursive code:

- It traverses top-level nodes iteratively in reverse order, guaranteeing that positions are valid when deleted.
- Processing each top-level node recursively continues the scan. It scans the direct children iteratively and recurses to handle grandchildren, great-grandchildren, etc.
- Aha! We just need to remove nodes from the to-be-deleted list when we delete their parent!

Summary

A straightforward algorithm replaces horrific legacy code. This algorithm ensures that no positions in the to-be-deleted list ever become invalid until after they are deleted. There is no need to pre-sort the to-be-sorted positions!

Why did I never see this trick before? Perhaps other complex code can be simplified.

Edward

P.S. To see how tricky the legacy code is, see its Theory of Operation!

EKR