godot: TextEdit: wrap is not implemented

Another quick update: I’ve managed to get the text to display in the proper position on subsequent lines (no longer writes ON TOP of previous wrapped lines, but moves down to accommodate them). I’ve also disabled the horizontal scrollbar when wrap is enabled. Currently working on getting the viewport adjustment and vertical scrollbar to respond appropriately to wrapped lines so that they don’t start getting drawn off the edge of the TextEdit.

If you came here because wrap_enabled or set_wrap_enabled is still not working in 2022: make sure you set the text property after you set wrap_enabled, otherwise it will silently fail.

@blurymind @Supergeek there is already a PR for this ready to go. It’s scheduled for the 3.1 release.

Ok, I’m going to go ahead and try to tackle this (first real bug fix challenge). Specifically because I have about 3 different tool concepts I wanna work on for Godot and ALL of them would require textedit wrapping to have the right feel, haha.

Symptoms I’ve noticed (in summary):

• set_wrap is not effective.
• set_max_chars is not effective.
• If you hold down shift and highlight the content of the TextEdit, the section will be highlighted, but then the remaining contents of the TextEdit will begin flashing grey/white so long as you aren’t holding down shift anymore.

Edit: seems that the last bug just triggers automatically so long as you are in block mode and the cursor is not at the end of a line. Everything from the curser to the end of the file will start blinking in inverted colors.

I’ll try to work on these. I also plan to implement a max_line_chars variable so that you can specify a max length per line.

@pwab turns out I was using an old alpha version. Downloaded the latest and there is no issue!

@stubbsy345 Hey, sorry, I saw this in an email notification, and then forgot to respond.

Unfortunately, I don’t think I’ll be able to get it in for the 3.0 release. I MIGHT be able to isolate the max_chars fixes / features I mentioned if I can isolate them out of my branch, but I’ve been having really weird problems in getting my version of godot to build correctly as of late.

I was working on a different project for the last month - something I could do without having to compile the engine from source, cause I was starting to get burnt out / frustrated. I wanna try re-tackling my engine compilation issues though, so hopefully I can resume work on this.

Update: I have implemented the following bug fixes / features:

1. block_caret altering subsequent font color change (bug fix)
2. max_chars not working properly (bug fix)
3. Adding a max_line_chars (and associated getter/setter methods)
4. Adding signals for both max_chars and max_line_chars (max_chars_reached and max_line_chars_reached, respectively) notifying the user when an attempt is made to insert beyond the limitation and which line.

I am now moving on to the actual wrap implementation (already have an initial implementation caching the appropriate string indexes during insertion for later wrapping).

Probably the best is to use, for each line, a sub-line array (starting positions of sub-lines, like, Vector<int> that is cached and re-computed on screen resize (width) or line modification.

On Fri, Jul 28, 2017 at 11:41 AM, Will Nations notifications@github.com wrote:

TextEdit is storing its underlying data as a mutable Vector (one String for each line). Does anyone have any suggestions on how best to tackle the cascading repositioning of strings as you resize the window / insert text? My first thought would just be to move things to lines below/above as the window contracts/expands; however, doing that would essentially be pretending that \n exists where it doesn’t (it would reflect in an increased/decreased count for line numbers which I would want to avoid).

Place of interest is /scene/gui/text_edit.cpp, line 2776, method _base_insert_text

It seems like the most appropriate way to handle it is to write an algorithm that…

1. Connects preinsert_text to the next text on the insertion line.
2. Checks the current line and detects the starting position of the first word to go beyond the visible width.
3. Adds a new line to the editor WITHOUT adding a new line (best way to handle that?) and write the remaining text on the current line.
4. Repeats steps 1 and 2 for each new line created until no more text goes beyond the visible width.
5. Reconnects the postinsert_text.
6. Repeats step 4.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/3985#issuecomment-318670086, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z27ait6OeQEnqMbVPk_OkZraubqg1ks5sSfMLgaJpZM4HrzjV .

Color regions can span multiple lines for comments, line constants, etc.

On Jul 23, 2017 9:05 PM, “Will Nations” notifications@github.com wrote:

@reduz https://github.com/reduz Is there a reason you know of why text_edit.cpp::_update_line_cache runs through the lines checking for color regions two completely separate times (lines 151-208)? It seems like it would just end up adding two separate color region info objects for each actual color region…

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/3985#issuecomment-317292136, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z29iR1R-WTRqYXgT6wQm-XB5IuiSuks5sQ9-ugaJpZM4HrzjV .