You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I work with the formatter-maven-plugin and ever since 1.14.1, we have been unable to upgrade as it seriously corrupted pretty formatted html. After deep diving this, I finally found the cause. So I think the change basically breaks pretty formatting in most cases. Our example is rather simple, you cna find it here ->
We keep the hash of what the prior formatter was producing (namely 1.13.1) that is on our master now. If it changes during an upgrade, it should be some improvement. In this case its rather corrupted by lack of proper whitespace. It further doesn't line break on the header any longer (not solved on this ticket).
After reviewing all the code changes and a lot of debuging, I have gotten to the StringUtil change here. Specifically line 75 (width = Math.min(width, maxPaddingWidth);) or line 128 in your lastest master.
After looking at what formatted for us, it was clear it was 30 characters as that is set preventing proper nesting to occur. So I cloned this repo and commented out that line then ran against that. The result was more of what we expected. A few tags were shortened where possible (but note that header line break from star slash comment didn't change). This is far more acceptable to us given our user base and fact that jsoup is vulnerable I believe a couple times now.
This is clearly internal code of jsoup and not intended for external exposure based on the package naming but I feel we need this exposed with 2 options. The first option, completely disable it so it works like it did before as that is rather critical as we are formatting source code to be committed to repos. The second option would simply to allow some sizing. So I think something like -1 to mean no limit and then configurable to whatever a user might want.
I don't might writing the code to expose that out but wanted to run this full diagnostic of the issue by your team first before attempting to do so.
The text was updated successfully, but these errors were encountered:
Hi -- this sounds like a good feature to add. I'd be happy to review a PR if you want to go ahead with it. Something like adding a maxPadding parameter to Document.OutputSettings, with it defaulting to the current default, and -1 to disable.
Hi,
I work with the formatter-maven-plugin and ever since 1.14.1, we have been unable to upgrade as it seriously corrupted pretty formatted html. After deep diving this, I finally found the cause. So I think the change basically breaks pretty formatting in most cases. Our example is rather simple, you cna find it here ->
test
resource
We keep the hash of what the prior formatter was producing (namely 1.13.1) that is on our master now. If it changes during an upgrade, it should be some improvement. In this case its rather corrupted by lack of proper whitespace. It further doesn't line break on the header any longer (not solved on this ticket).
After reviewing all the code changes and a lot of debuging, I have gotten to the StringUtil change here. Specifically line 75 (width = Math.min(width, maxPaddingWidth);) or line 128 in your lastest master.
After looking at what formatted for us, it was clear it was 30 characters as that is set preventing proper nesting to occur. So I cloned this repo and commented out that line then ran against that. The result was more of what we expected. A few tags were shortened where possible (but note that header line break from star slash comment didn't change). This is far more acceptable to us given our user base and fact that jsoup is vulnerable I believe a couple times now.
This is clearly internal code of jsoup and not intended for external exposure based on the package naming but I feel we need this exposed with 2 options. The first option, completely disable it so it works like it did before as that is rather critical as we are formatting source code to be committed to repos. The second option would simply to allow some sizing. So I think something like -1 to mean no limit and then configurable to whatever a user might want.
I don't might writing the code to expose that out but wanted to run this full diagnostic of the issue by your team first before attempting to do so.
The text was updated successfully, but these errors were encountered: