Word Frequency fails to position cursor #628
Comments
|
@okrick, What was the expected result? |
|
I expected that |
Ah, I see. I had to turn off "whole word only" in the search form, but when I cmd+left-clicked on it in WF, the search window came up and find all found it. I wonder if WF is confused by the prefix; I didn't see anything in the log. |
|
Yet, 001.png etc. are selectable. The only one on the list not selectable is 000.jpg. |
000.jpg is also the only one that has a prefix that would cause the assumption that it's not a "full word". The "whole word" checkbox appears to be checked by default when a search form is brought up using the cmd/ctrl+left click, presumably to omit partial matches). I can cmd-left-click on Now, the question is -- should WF be grabbing the whole illustration name, i.e. |
|
Yes. Either the |
Because regexes include underscore in their idea of word characters, an occurrence preceded by underscore of a word found by WF would not be found by "whole word" search. So, the word would be listed in WF, but when the user clicked it, the word would not be found. Fixed by changing search's "whole word" to wrap the search string with a more complex regex, rather than `\b...\b` Also changed WF's idea of a word to include embedded underscores (in the same way as embedded periods are included), e.g. "i_001.jpg", but to strip leading or trailing underscores, which signify italics, e.g. "_dog_". Fixes DistributedProofreaders#628
|
All the above comments from @okrick & @srjfoo are completely fair: there was a problem with word boundaries and underscores. Because the origins of regexes are computing-based, the characters that count as part of a word include the underscore character. So, when you do a "whole word" search, and it tries to find However, certainly as far as WF is concerned, we don't want a leading or trailing underscore to be included in a "word", mostly because we use them to mark italics, e.g. I have implemented a solution which tackles this issue - see #634 for details. |
Because regexes include underscore in their idea of word characters, an occurrence preceded by underscore of a word found by WF would not be found by "whole word" search. So, the word would be listed in WF, but when the user clicked it, the word would not be found. Fixed by changing search's "whole word" to wrap the search string with a more complex regex, rather than `\b...\b` Also changed WF's idea of a word to include embedded underscores (in the same way as embedded periods are included), e.g. "i_001.jpg", but to strip leading or trailing underscores, which signify italics, e.g. "_dog_". Fixes #628
Ran the Alpha/Num check. Except for
000.jpg, selecting any item on the list automatically positions the cursor at the beginning of the item in the document.travels.zip
The text was updated successfully, but these errors were encountered: