This repository has been archived by the owner on Aug 31, 2021. It is now read-only.
[[ Bug 19543 ]] Dictionary improperly parses hard wrapped lines #6164
Conversation
This file contains 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
… word is followed by colon When a paragraph ends with a colon and the last word falls on a new line then that word is parsed as a new element. Due to the way the regex is parsed, something inside parenthesis before the colon could also trigger this bug. The proposed fix: Unless there is a preceding blank line, assume that this term is part of the existing content. If there is no content, then assume it is indeed a new element. An exception is if the element contains the content on the same line, in that case a new element can start on the next line. Some LCB documentation has "Description:" immediately following another multi-line element without a blank line (i.e. examples). Added a check that can be extended if other elements are found that need to be treated as an exception. I ran a diff on the built_api.js from before my change and after. There are 584 lines of changes. Not all of them are evident in the dictionary viewer. (Only the first 128 lines are for ~32 actual changes, the rest were due to reordering of svgpath and svgspinner in the JSON.) Some entries fixed by the change: - open printing - open printing to pdf - switch
|
This looks good. I have one suggestion, which is to replace and with a suitably named constant, eg Also, is the empty string deliberately included in the items? I believe it can't be empty anyway because of the regex, but I just want to make sure. |
|
Empty string would not get used due to the regex so it isn’t needed (was copying a form I saw elsewhere). |
Use a constant for the list of elements that are always recognized as such. Currently just one item.
|
@livecode-vulcan review ok 349a29a |
|
💙 review by @livecodeali ok 349a29a |
livecode-vulcan
added a commit
that referenced
this pull request
Dec 7, 2017
[[ Bug 19543 ]] Dictionary improperly parses hard wrapped lines When a paragraph ends with a colon and the last word falls on a new line then that word is parsed as a new element. Due to the way the regex is parsed, something inside parenthesis before the colon could also trigger this bug. The proposed fix: Unless there is a preceding blank line, assume that this term is part of the existing content. If there is no content, then assume it is indeed a new element. An exception is if the element contains the content on the same line, in that case a new element can start on the next line. Some LCB documentation has "Description:" immediately following another multi-line element without a blank line (i.e. examples). Added a check that can be extended if other elements are found that need to be treated as an exception. I ran a diff on the built_api.js from before my change and after. There are 584 lines of changes. Not all of them are evident in the dictionary viewer. (Only the first 128 lines are for ~32 actual changes, the rest were due to reordering of svgpath and svgspinner in the JSON.) Some entries fixed by the change: - open printing - open printing to pdf - switch
|
😎 test success 349a29a
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
When a paragraph ends with a colon and the last word falls on a new line then that word is parsed as a new element. Due to the way the regex is parsed, something inside parenthesis before the colon could also trigger this bug.
The proposed fix: Unless there is a preceding blank line, assume that this term is part of the existing content. If there is no content, then assume it is indeed a new element. An exception is if the element contains the content on the same line, in that case a new element can start on the next line. Some LCB documentation has "Description:" immediately following another multi-line element without a blank line (i.e. examples). Added a check that can be extended if other elements are found that need to be treated as an exception.
I ran a diff on the built_api.js from before my change and after. There are 584 lines of changes. Not all of them are evident in the dictionary viewer. (Only the first 128 lines are for ~32 actual changes, the rest were due to reordering of svgpath and svgspinner in the JSON.)
Some entries fixed by the change: