-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"Strip line breaks" suggestions... #32
Comments
Thanks for suggestions, I'll look into these. |
manisandro
added a commit
that referenced
this issue
Aug 23, 2015
manisandro
added a commit
that referenced
this issue
Aug 23, 2015
…rk (.?!)" and make postprocessing work accordingly (#32)
Ok this should be done. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
An exceedingly minor suggestion regarding option labeling.
The "strip line breaks..." options menu currently looks like this, in the top section:
Strip line breaks in selected text
Keep line breaks if...
I would suggest changing the label on the first to "Preceded by period", which is a better description of its function. Especially with whitespace characters being drawn as actual gray dots, when "Draw whitespace" is enabled, "dot" is a confusing way to refer to a period character.
Actually, as a separate enhancement suggestion, it might be better to change the label to "Preceded by end of sentence", and add other sentence-terminating punctuation like ? and ! to the list. Currently, a sentence ending in a period will cause the line break to be preserved, but non-period-terminated sentences at the end of lines will be combined. It seems like we'd want to leave line breaks alone equally, whether the line ends with any of
.?!
...In that same vein, whitespace characters following the period at the end of a line will trip up the combining logic, so a line that ends with ...
some words.<space><space>
will be combined with the next, even if "Keep line breaks if preceded by dot" is enabled. I wonder if the line-ending-character determination shouldn't trim off whitespace first, and consider only the last non-whitespace character?The text was updated successfully, but these errors were encountered: