Conversation
Raised by Jason on #1135, after the merge. MoStemMsa.IsFieldRelevant withholds FromPartsOfSpeech ("Attaches to Categories") unless the owning entry has a proclitic or enclitic, and Morphology.fwlayout:39 declares that part visibility="always" -- so before the relevance gate the row composed on every stem MSA, and now it disappears for every entry without a clitic. That is the gate's most visible consequence and nothing pinned it. The test is Jason's, run and confirmed to bite: suppressing the gate fails its negative half with "Expected: False, But was: True", while the positive control -- add a proclitic allomorph, change nothing else -- keeps passing. Also corrects two comments that claimed more than the code does. The composer implements the SECOND of SliceFilter.IncludeSlice's two gates; the first looks the slice id up in the tool's filter list, and the id never reaches the composer, so that half is LT-22802. The fixture summary said it covered the remainder of the overrides, which was untrue while this test was missing, and still excludes the InflectionClass limb that withholds the row from a compound rule's left/right MSA. xWorksTests filter Avalonia 1642 passed, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Legacy SliceFilter.IncludeSlice has two gates: look the slice's authored id up in the filter list the tool's filterPath names and withhold the row when it is listed, then ask IsFieldRelevant. LT-22672 added the second. This adds the first. The id was discarded at import, so three pieces: - XmlLayoutImporter carries the slice's id onto ViewNode.SliceId, and id leaves the unhandled-attribute report. - DetailComposer.Walk withholds a node whose SliceId the tool lists, checked before the node kind is dispatched so a withheld node takes its subtree with it -- where legacy checks it, at the top of ProcessSubpartNode. - RecordEditView reads filterPath from its own configuration and parses the same file into the id set, memoized per view. A tool with no filterPath, or a file that cannot be read, filters nothing: an extra row beats a view that will not open. NOTHING VISIBLE CHANGES TODAY, and the ticket's symptom section overstates it. The only shipped filter entries that still resolve to a real slice are the five CmPossibility ids in basicPlusFilter.xml, and the only tool they reach is Exception "Features" (ProdRestrictEdit) -- which is not in the Avalonia tool catalog, so it renders legacy even under UIMode=New. The other 27 ids across the six filter files name nodes that no longer exist. Category Edit is in the catalog and carries the same filterPath, but its layout reaches none of those ids. So this is parity landed before it is needed: the day ProdRestrictEdit joins LexiconFeatureCatalog, the view already withholds what legacy withholds instead of growing five rows nobody looks for. Tested at the mechanism, not the wiring. Suppressing the composer gate fails the filter tests with the full row list -- Name, Abbreviation, Description, Status, Discussion, Confidence, Researchers, Restrictions -- and the importer tests pin the id. Reading filterPath in RecordEditView has NO test and cannot be checked in the app while the tool renders legacy; it becomes verifiable, by Jason's acceptance steps, when that tool is activated. FwAvaloniaTests 751 passed, xWorksTests filter Avalonia 1645 passed, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The filter-list read was the one part with no test, and the part that could quietly make the whole feature a no-op: every other test in this area supplies the id set by hand, so a broken read leaves them all green. Demonstrated rather than assumed. Pointing the XPath at the wrong element name fails only the new test; the three composer tests still pass. The read moves to an internal static taking the tool's configuration node, so it is reachable without a mediator or property table -- the same way the reference-vector menu entry points are tested. The property keeps only its memoization. One test drives the whole chain against a shipped filter file: the attribute name, the path resolution, the XPath and the id attribute. It asserts the ids are PRESENT rather than exhaustive, so editing that file leaves it alone while breaking any link in the chain does not. xWorksTests filter Avalonia 1650 passed, 0 failed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #1146 +/- ##
=======================================
Coverage 38.89% 38.89%
=======================================
Files 1518 1518
Lines 352262 352302 +40
Branches 40597 40603 +6
=======================================
+ Hits 137005 137045 +40
+ Misses 185976 185974 -2
- Partials 29281 29283 +2
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Teaches the Avalonia detail view to read a tool's slice filter list. Some tools attach a
small file naming fields to leave out. The WinForms view reads it; the Avalonia view was
never taught to.
Nothing visible changes today
The ticket's symptom section overstates this, so it is worth being plain: no user can
see a difference from this PR.
CmPossibilityids inbasicPlusFilter.xml.ProdRestrictEdit), which is notin
LexiconFeatureCatalog-- so it renders WinForms even under New UI.filterPath, but itsPartOfSpeechlayout reaches none of those ids.define.
So this is parity landed before it is needed: the day
ProdRestrictEditjoins thecatalog -- a one-line change -- the view already withholds what the WinForms view
withholds, instead of growing five rows nobody goes looking for.
What changed
SliceFilter.IncludeSliceapplies two gates: look the slice's authoredidup in thetool's filter list and withhold the row when listed, then ask
IsFieldRelevant. #1135added the second. This adds the first, which needed the
idto survive import.XmlLayoutImporteridontoViewNode.SliceId, andidleaves the unhandled-attribute reportDetailComposer.WalkSliceIdthe tool lists, checked before the node kind is dispatched so a withheld node takes its subtree with itRecordEditViewfilterPathfrom its own configuration and parses the same file, memoized per viewA tool with no
filterPath, or a file that cannot be read, filters nothing: a detail viewshowing an extra row beats one that will not open.
Tested at both ends
Both halves are falsified, not merely green:
Abbreviation, Description, Status, Discussion, Confidence, Researchers, Restrictions.
tests stay green, because they supply the id set by hand. That is exactly why the
reading test exists: without it the whole feature could be a silent no-op and still look
green.
The read is an
internal statictaking the tool's configuration node, so it is reachablewithout a mediator or property table -- the same approach #1133 used for the
reference-vector menu entry points. Its main test drives the whole chain against a shipped
filter file (attribute name, path resolution, XPath,
idattribute) and asserts the idsare present rather than exhaustive, so editing that file leaves the test alone while
breaking the chain does not. The property's memoization is the only untested line.
Verification
-TestFilter Avalonia: 1650 passed, 2 skipped, 0 failedbuild.ps1 -CommentHygiene -TokenHygienecleanNot manually verified, and cannot be: the ticket's acceptance steps need a tool that
renders in Avalonia. They become runnable when
ProdRestrictEditis activated.The
LexiconFirstSliceEditContextEdgeCaseTeststeardown error in the xWorks run ispre-existing and unrelated --
git blameputs it in LT-22625 (#964), and nothing heretouches that file.
Ticket corrections
Three things on LT-22802 need fixing, all found while building this:
ProdRestrictis the internal clerk name.changes.
🤖 Generated with Claude Code
This change is