Repository navigation
Remove group's chain re-ask after its own merges, which no longer changes a reading #638
Closed as not planned
Description
Activity
Closing: the premise is wrong. #635's fix-commit review found the re-ask live. Removing it moves 400 parses of #623's given-part grid on master and on the branch alike: a title-particle head, then a particle run, then a dotted acronym. For example,
Smith, Freiherr van Berg X.Y.Z.reads given 'van Berg X.Y.Z.' (as 1.4.0 and 2.3.0 read it); without the re-ask it reads given 'van Berg', suffix 'X.Y.Z.'. The first review's grid had no such shape. #635 adds the parity rowthe_chain_runs_again_where_its_merges_free_the_acronym, so the re-ask is now held by a test.
On a segment where S2's run isn't read once ahead of the chain, group's chain stops at
trailing_start. After merging, it re-asks the peel, and reruns the chain without the stop if the peel no longer takes what it stopped before (theleft < tailblock in_group_segment). The documented case wasFreiherr von Berg Ma, and that has taken #614's read-once path since #614.#623's review replaced the re-ask with a no-op. Nothing changed: no test failed on master or on #623's branch, and 0 of 226,776 generated parses moved. 31 case rows reach the block and 3 fire it (
Smith, John PhD Jr. de la,Berg, Jan de vd,Doe, John van DO), and those three read the same without it.Proposal: find an input where the re-ask decides something, or delete it along with its snapshot and comment. The bound at that site still matters: reverting it alone to
trailing_startfails 9 tests, because the re-ask then seesleft = 0.