[TextEdit] Expose all auto-wrap modes.

[bruvzg]

Fixes #74256
Fixes #74812

[YuriSizov]

This looks like a good feature change, but it does break compatibility. So we need to make sure existing projects won't be broken when opened in 4.1.

[Paulb23]

I think there are two types of wrapping here, the text server for how to wrap, and TextEdit when to wrap. For example if adding a new wrap mode at the guidelines rather then the control boundary. Shouldn't we separate these into two properties?

[YuriSizov]

I think that would just affect the width parameter somewhere. So it's not necessary to introduce some special wrapping mode for it, just a flag?

[Paulb23]

No it needs to be wrapped, as there could be an option to allow mixed i.e fix column or viewport whichever is smallest, that cannot be conveyed with a width parameter (See VSCode). That was the intended purpose of this property.

[YuriSizov]

fix column or viewport whichever is smallest, that cannot be conveyed with a width parameter

That still sounds like something that is conveyed with a width.

So we have two things to handle here:

• What's the bounding box for the text (i.e. where to wrap),
• And how to handle text wrapping (i.e. how to wrap).

The control can decide on the bounding box whichever way it wants. It can use its own rect, it can add extra constraints like the guide line, etc. From what I'm seeing, the enum that has been removed in this PR, LineWrappingMode, does not implement any of that yet. Instead if provides options similar to the TextServer::AutowrapMode enum, but more limited.

If the intend for the existing enum is to be extended to support options that you describe, then we can keep it. But then the new enum should still be added and exposed to the TextEdit API to allow defining the wrapping behavior itself.

But then the existing enum remains with a conflicting option, LINE_WRAPPING_NONE, which duplicates the text server behavior option. If we remove LINE_WRAPPING_NONE, then the LineWrappingMode enum is left with a single option for defining boundaries, and that means it doesn't do anything at this point. So IMO we should just replace the enum like this PR does, and then reintroduce it in some way later, as you implement those extended wrapping boundary options.

[Paulb23]

Yes the intent was to prevent breaking compatibility during 4.0, leaving room for the functionality to be extended.

I think I like the idea of moving this to a separate API an leaving the current enum with one option, as I don't think TextEdit has a way to override the TextServer enum. That way we can add set_autowrap_mode methods which would align this functionality with the other control nodes i.e Label, Label3D and RichTextLabel.

[bruvzg]

I do see any logic in these calculations, so I have only adjusted values to match real ones. Default TextEdit wrapping behavior should not be change, and the only reason this test was passing - set_line_wrapping_mode was not calling queue_redraw(); and updating wrapping until something else triggered redraw.

[bruvzg]

Updated to use separate property.

Changes done.

[akien-mga]

Thanks!