Closed DavidHaslam closed 6 years ago
I agree, it needs some care when removing them.
38 of the 63 hits match the regexp & \D
being those that are followed by a book abbreviation
23 of the 63 hits match the regexp & \d+\.\d+.
being those that are followed by a bookless reference
2 of the 63 hits match the exact pattern &.
being those with an anomalous full-stop
41 of the 63 hits match the exact pattern . &
where the preceding reference ends with a full-stop
20 of the 63 hits match the regexp \d+ &
where the preceding reference is not terminated
2 of the 63 hits match the exact patterm , &
where the preceding reference ends with a comma
The 20 hits where the preceding reference is not terminated are the harder to deal with. It would be wrong to terminate the preceding reference with a full-stop where the succeeding reference is to the same book and which is not the current book location. Terminating the preceding reference with a semicolon should be suitable for these cases.
The xrefs containing an ampersand have been updated by means of a further bespoke TextPipe filter. The PCRE replace list covered 5 distinct patterns to ensure that each case was correctly handled.
This issue is now fixed in the most recent commit to the Editing branch of my fork.
Here are the search results for counted xrefs that contain
&
: (63 hits over 68 locations)It seems to me that many of these
&
provide no added value to the xrefs. However, merely removing all of them willy-nilly may lead to a few ambiguities. e.g. ChangingZaga 27.19 & 28.5.
toZaga 27.19. 28.5.
would make the28.5.
refer to a verse in thecurrent book
rather than one in Proverbs. Assuming the semicolon properly delimits a further reference in the same book, this one should be:Zaga 27.19; 28.5.