search

therealglazou / bluegriffon

BlueGriffon, the Web editor
Mozilla Public License 2.0
295 stars 71 forks source link

inappropriate addition of LF line wrapping on Windows machines #5

Open garretwilson opened 8 years ago

garretwilson commented 8 years ago

BlueGriffon 1.8 will force lines to be wrapped, and will incorrectly use LF instead of CRLF on Windows machines.

For example take the following XHTML5 source code:

<p>For well over a decade, the most popular text format for storing arbitrarily structured information has been the <a href="http://www.w3.org/XML/">Extensible Markup Language</a> (<abbr>XML</abbr>). Recently more and more Internet applications are switching to a newer format named <a href="http://www.json.org/">JavaScript Object Notation</a> (<abbr>JSON</abbr>).</p>

On Windows 10 Pro 64-bit, BlueGriffon will force lines to be wrapped and incorrectly use LF instead of CRLF on WIndows, resulting in the following:

<p>For well over a decade, the most popular text format for storing arbitrarily structured information has been the <a

     href="http://www.w3.org/XML/">Extensible Markup Language</a> (<abbr>XML</abbr>). Recently more and more Internet applications are switching to a newer format named <a

     href="http://www.json.org/">JavaScript Object Notation</a> (<abbr>JSON</abbr>).</p>

This is not only hugely irritating, it also corrupts our files.

Note that this occurs even if we turn off line wrapping!! It appears that there is a separate line-wrapping algorithm being invoked to wrap <a> element. This separate line-wrapping logic is ignoring the platform EOL settings and forcing LF. Not only that, this separate line-wrapping logic seems oblivious to BlueGriffon's line-wrapping enabled/disabled setting.

Thus this bug corrupts our files in two ways:

You can imagine that this causes chaos with Git, diff, and other tools.

This is a huge stumbling block, forcing us to tidy up files in other editors before committing. Requiring our authors to do this second-editor tidy-up is a real pain and hard to consistently enforce.

Please address this.

garretwilson commented 8 years ago

Note that this bug is still present in bluegriffon-2.0b2.win32.

garretwilson commented 8 years ago

Any update on this? This is the single-most serious problem with BlueGriffon right now for us, and adds quite a bit of work to our workflow fixing this up. Is there any way a third-party could hook into BlueGriffon to at least provide a workaround?