line wrapping setting ignored

[garretwilson]

This is related to #5, but distinct. Bug #5 says that an LF is being added, whether or not line wrapping is turned on. This bug says that even if you turn off line wrapping, certain elements are still wrapped, such as in the following paragraph:

<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 wrapped to:

<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>

Turning off line wrapping should be a way to work around bug #5, but this bug prevents that.

(No doubt the bugs stem from the same code, so if you fix this bug it will undoubtedly fix #5 as well.)

In short, the core problem with both this and #5 seems to be that something is adding LFs, completely independent from the BlueGriffon main line-wrapping logic (wherever that is). This is causing no small amount of pain, and requires a fix-up with external editors --- something that will not be realistic when I had our content over to our translators.

[garretwilson]

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

[garretwilson]

@therealglazou , I'm so happy you're looking at bugs today. Could you please, please, please address this bug, and the related Bug #5?

This is causing me endless pain. I will even pay for you to fix these two bugs --- just give me your PayPal email address and let me know a reasonable price. Please.

[garretwilson]

I've opened a USD$200 Bountysource funding for this bug:

https://www.bountysource.com/issues/29803090-line-wrapping-setting-ignored

[gbts]

@garretwilson, the issue seems to go away when Auto-indent is disabled (just above the line wrap setting).

Note that disabling Auto-indent will get rid of the issue without actually changing the behaviour of the editor, which will still indent HTML properly as you type (this is an unrelated feature of CodeMirror called smart indent). Strangely, BlueGriffon's Auto-indent is actually using Gecko's nsiDocumentEncoder::OutputFormatted which doesn't seem to be that useful for editing source code.

Can you try disabling the setting and let me know if that fixes the issue?

[garretwilson]

@gbts , are you talking about the Wysiwyg view or the source view?

The setting(s) you are referring to is for the source view; that's how the document will be serialized when saved as an (X)HTML file.

Its good to know that turning off "Auto-indent" will prevent the addition of line breaks. But I want the source code indented. I just don't want long lines wrapped. That's why I turn on "Auto-indent" and turn off "Wrap long lines". But it still wraps long lines. That is the bug you are trying to fix. Turning off "Auto-indent", even if it prevents line breaks, would be a workaround---it would not fix the bug.

I will try this later to see what the behavior is, but the bounty is for fixing the bug, not for using a workaround that turns off another feature. Thanks.

[gbts]

@garretwilson right, I was referring to the source view where CodeMirror could handle the auto-indent, but unfortunately this won't help you with the WYSIWYG editor. Not bounty-worthy, but just in case you find it helpful an overall workaround would be to disable auto-indent & line wrapping, return to the source view before the final save, do a CTRL-A to select everything and a SHIFT-TAB to auto-indent the file with CodeMirror.

After looking a bit into this it seems that it's a Gecko bug (or a bug in the patched Gecko of BlueGriffon). It seems that something in nsXHTMLContentSerializer.cpp or nsXMLContentSerializer.cpp is forcing a wrap inside the tags (normal text seems unaffected) even when the flag is not set. Both are not maintained (and a bit of a mess really) so unfortunately I don't have the time to investigate this any further. It might make more sense at this point to just avoid nsDocumentEncoder's formatting altogether and just pass the document through something like jsbeautifier before saving, but that would probably be up to the maintainer @therealglazou to decide.

I'm just leaving the info here for anyone who might want to take a shot at this in the future.

[garretwilson]

After looking a bit into this it seems that it's a Gecko bug …

Yes, @therealglazou has mentioned this in the past.

So can you fix it? How much will it cost?

… that would probably be up to the maintainer @therealglazou to decide.

@therealglazou has abandoned this bug. I'm trying to pay someone to get it fixed, since the maintainer doesn't plan on doing anything about it.

I'm just leaving the info here for anyone who might want to take a shot at this in the future.

Thanks for taking the time, but I'm really wanting this fixed. You don't want to try any more, either?

[gbts]

I raised the goal to something that's closer to the amount of time I assume a solution will take. Not trying to extort a higher price here, it just seems that realistically it will take a few workdays to go through Gecko's spaghetti just to find the bug, and the fix will likely involve a partial rewrite of the serializers.

[gbts]

(and of course, any other bounty hunters that want to work on this in parallel are welcome to start a solution)

[garretwilson]

Eep! 😬 Do you have any experience on how likely (and quickly) Mozilla would be to integrate the solution into a new release?

@therealglazou , if we get a fix into the Gecko codebase, how soon could you do another release that incorporated the Gecko changes?

(I'm trying to take all these things into consideration before I invest much more. If I paid thousands, yet it never got integrated, it wouldn't help me much...)

[gbts]

Assuming it's a simple bugfix that won't be changing existing behavior, then it wouldn't take long. But I think there's no need to push the fix upstream for BlueGriffon since it's already using a patched version of Gecko, so any changes could just be integrated into the patch. Obviously @therealglazou has the final say on when/if those changes will make it to the next release.

[garretwilson]

Note that disabling Auto-indent will get rid of the issue without actually changing the behaviour of the editor …

@gbts but this introduces another problem: blank lines are arbitrarily added throughout the document. With auto-indent turned on, for example, my HTML header looks like this:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html><html lang="en-US" xmlns="http://www.w3.org/1999/xhtml">
  <head>
    <meta charset="UTF-8" />
    <meta name="author" content="Garret Wilson" />

But if I turn auto-indent off, look what happens:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html><html lang="en-US" xmlns="http://www.w3.org/1999/xhtml">
  <head>
<meta charset="UTF-8" />
    
    <meta name="author" content="Garret Wilson" />

Not only are some things still indented, it introduced a blank line between my <meta> elements. Why? Why?

You see, I have a post-editing beautifier I use to reformat the code even better and try to work around BlueGriffon's bugs. But that beautifier won't remove these arbitrary blank lines if I turn off auto-indent. And if I turn auto-indent on, BlueGriffon will arbitrarily break lines as we know (#7), but there is a bug in the beautifier (beautifier/js-beautify#1033) that refuses to join lines for certain elements. 🤦‍

See, everybody's code is full of bugs; one tool's bugs keeps it from working around the bugs of another tool. That's why this is so frustrating, which is why I'm trying to pay somebody to fix some of them. (And @therealglazou still hasn't responded to say if he will accept a fix if I pay for somebody to do it.) 😦