Fix newline characters not rendering as line breaks

[alppp]

\n in chat text renders invisible text concatenates on one line instead of breaking. the font renderer just iterates characters and treats \n as an empty glyph. mojang never fixed the renderer, in 1.8+ they just made callers split text before rendering.

1.7.10 already has the splitting infra (sizeStringToWidth case 10, listFormattedStringToWidth), disconnect screen and hover tooltips use it. but the chat system and drawString/drawStringWithShadow don't this wires them through the existing splitter.

• chat: splits incoming components on \n into separate chat lines with format carryover
• drawString: splits via listFormattedStringToWidth(text, MAX_VALUE) then renders each line normally

worldedit, serverutilities, personalspace all have manual split("\n") workarounds for this. with the fix future code doesn't need that.

[DarkShadow44]

This breaks some functionality:

• Minecraft allows replacing existing text, since you split into multiple parts this doesn't work properly - only one line gets replaces
• Additional info like "hover" or "on click" breaks. Since you create new text components no hover or click event gets carried over.

I made a test patch here: 0001-test.patch
You can test with my patch and /newlinetest, see my screenshots:

• The red line should have been removed
• The pink line isn't interactive - no hover or click works.

Without your changes

With your changes

[alppp]

fixed - shadowed func_146237_a and deleteChatLine, dropped the (GuiNewChat)(Object)this cast.
also i fixed both of issues, thank you for patch to test.

[DarkShadow44]

Didn't test it yet, but I assume it works for now. Not really a fan of the self recursion in func_146237_a but it should work. the text splitting I didn't really understand, and I'm not sure copying the style is really enough, seeing how the interface could be implemented by different classes.

[alppp]

Didn't test it yet, but I assume it works for now. Not really a fan of the self recursion in func_146237_a but it should work. the text splitting I didn't really understand, and I'm not sure copying the style is really enough, seeing how the interface could be implemented by different classes.

I have revamped the idea a bit, it didnt not work on full gtnh client only runClient, so i tried my best to be it clear and simple, it does work as intended

[DarkShadow44]

I don't see any further issues - it does look good to me now - but I'm not confident I understand it enough to sign off on it.

[Glease]

I'm fine with the chat gui fix but skeptical towards the FontRenderer change. Previously the caller would assume the draw would only ever occupy one line of y space (12~18px depending on UI style), now it can silently overdraw to next lines as well. this is highly unexpected and can corrupt UI in annoying ways, which is exactly why mojang on 1.8+ need caller to do this. IMO we should fix callers instead of trying to have fontrenderer babysit every drawString call

[DarkShadow44]

I'm fine with the chat gui fix but skeptical towards the FontRenderer change. Previously the caller would assume the draw would only ever occupy one line of y space (12~18px depending on UI style), now it can silently overdraw to next lines as well. this is highly unexpected and can corrupt UI in annoying ways, which is exactly why mojang on 1.8+ need caller to do this.

Wouldn't this only happen if people added a newline character into the text? In that case it would render as LF which is a weird symbol to have rendered as text, so I'd assume people dealt with that.

[Nikolay-Sitnikov]

I'm fine with the chat gui fix but skeptical towards the FontRenderer change. Previously the caller would assume the draw would only ever occupy one line of y space (12~18px depending on UI style), now it can silently overdraw to next lines as well. this is highly unexpected and can corrupt UI in annoying ways, which is exactly why mojang on 1.8+ need caller to do this.

Wouldn't this only happen if people added a newline character into the text? In that case it would render as LF which is a weird symbol to have rendered as text, so I'd assume people dealt with that.

Why yes! In fact, there are several places where one could insert user-provided text - text boxes, NBT, and the like. Rendering the symbol as LF made sure that the mistake was visible & didn't cause weird overflows inside GUIs.

In other words: Rendering a misplaced line break as LF is better than rendering text where it shouldn't get rendered.