UsfmToolsSharp 2

[rbnswartz]

This pull request introduces a new hierarchy model for USFM markers, centered around the new HierarchyNode and HierarchyDefinition classes. It also removes the AllowedContents property and related logic from individual marker classes, consolidating hierarchy and type-checking responsibilities. Several marker classes are updated to use the new hierarchy model for child marker queries.

Key changes:

Hierarchy Model Introduction

• Added a new HierarchyNode class to represent nodes in the USFM marker hierarchy, including methods for traversing, searching, and manipulating the hierarchy tree. (USFMToolsSharp/Models/HierachyNode.cs)
• Introduced a HierarchyDefinition class to define allowed child types and insertion logic for hierarchy nodes. (USFMToolsSharp/Models/HierarchyDefinition.cs)

Marker Class Refactoring

• Removed the AllowedContents property and related static HashSet<Type> definitions from all marker classes, centralizing allowed child type logic in the new hierarchy model. [1] [2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14]

Marker Child Query Updates

• Updated marker methods (e.g., in CMarker) to use the new DefaultHierarchyNode.GetChildMarkers<T>() and As<T>() for child marker queries and type casting, replacing previous direct methods. (USFMToolsSharp/Models/Markers/CMarker.cs) [1] [2]

Codebase Cleanup

• Removed unused using directives and simplified class implementations in marker files. (USFMToolsSharp/Models/Markers/FTMarker.cs)

---

These changes collectively modernize and centralize the marker hierarchy logic, making the codebase easier to maintain and extend.

[Copilot]

Pull request overview

This pull request introduces a major architectural change to USFMToolsSharp by implementing a new hierarchy model for USFM markers. The changes centralize marker hierarchy management through new HierarchyNode and HierarchyDefinition classes, removing distributed AllowedContents properties from individual marker classes. The PR also updates the target framework and package versions, adds support for nested markers with '+' prefix and escaped backslashes, and refactors the marker selection logic from a switch statement to a dictionary-based approach.

Changes:

• Introduced new hierarchy model with HierarchyNode, HierarchyDefinition, and DefaultHierarchies classes to centralize marker structure management
• Removed AllowedContents property and TryInsert methods from all marker classes, relocating this logic to the hierarchy system
• Updated parser to support multiple hierarchies (Default, Presentation, Structure), nested markers with '+' prefix, and escaped backslashes

Reviewed changes

Copilot reviewed 90 out of 90 changed files in this pull request and generated 10 comments.

Show a summary per file

File	Description
USFMToolsSharp.csproj	Updated target framework to net10.0 and version to 2.0.0, enabled nullable reference types
USFMToolsSharpTest.csproj	Updated target framework and test package versions
USFMParser.cs	Refactored marker selection to dictionary, added hierarchy definitions support, implemented nested marker and escaped backslash handling
HierachyNode.cs	New class providing hierarchy tree operations including child marker search, path finding, and traversal
HierarchyDefinition.cs	New class defining allowed children and custom insertion logic for hierarchy nodes
DefaultHierarchies.cs	New static class containing three predefined hierarchies (Default, Presentation, Structure)
USFMDocument.cs	Refactored to support multiple hierarchies with new Insert method, added backwards compatibility property
Marker.cs	Removed Contents list and hierarchy methods, added DefaultHierarchyNode property
Various Marker classes	Removed AllowedContents and TryInsert overrides, simplified implementations
CMarker.cs, VMarker.cs	Updated to use DefaultHierarchyNode for child marker queries
USFMParserTest.cs	Updated tests to use new hierarchy model, added comprehensive hierarchy tests

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rbnswartz]

There is the possibility that we could use a state object here instead of tracking inContent, inMarker, start, end etc. Would be interested of what you think @PurpleGuitar. It would be potentially slower, but probably more maintainable.