Add String/Comment tracking, AutoComplete and hints to CodeEdit

[Paulb23]

Continuation of #31739

Builds on top of #42775 and blocked by #43663.

---

The main aim of this PR is abstracting out the auto complete system into CodeEdit, in order to do so it needed a system to track Strings.

The implementation of String tracking will also track Comments. The system closely follows that of the syntax highlighter, using the idea of regions.

It exposes add_[string|comment]_delimiter methods to register the begin and end keys for each type. Once registered CodeEdit will keep track of the region. It's possible to check regions via is_in_[string|comment] methods, if no column is provided it will return true if the entire line is a String or Comment. It is also possible to get the start and end position of regions via get_delimiter_[start|end]_position.

Regions are updated on the lines_edited_from signal, I've tried to make this somewhat fast to hopefully have minimal impact on performance.

AutoComplete is now exposed to the GDScript, items are added via add_code_completion_option. Once all items are added a call to update_code_completion_options will update the list of possible completions in the drop down. In addition to this there are three overridable methods:

• _request_code_completion -> Checks and emits request_code_completion signal.
• _filter_code_completion_candidates -> Filters the list of options.
• _confirm_code_completion -> Inserts the selected option

There are also various ways to query autocomplete getting the current selected, setting the selected item and getting the full list of options.

As part of the refactor I've attempted to remove the editor specific code and added a couple of new features. The first one allowing the user to force autocomplete. Secondly, adding a second shortcut to replace the existing text rather then inserting ontop. This is currently bound to Tab, the old behaviour is preserved by using Enter / KP Enter.

In addition to this the request_completion signal has been renamed to request_code_completion

To handle drawing, I've added two methods to TextEdit to get the caret draw position and to check if the caret is visible.

Finally CodeHint has also been moved and exposed, and callhint_offset has been removed.

---

TODO

• Remove old code from TextEdit
• Update input handling after Remove hardcoded shortcuts from /scene and instead use the input action system to allow them to be customised. #43663
• Update draw code and remove callhint_offset
• Fix initial '$' completion

---

closes #22196
closes #36833
closes #23756
closes #34168
closes #24077
closes #44000

Should solve some of #38847 and godotengine/godot-proposals/issues/1514

[KoBeWi]

So I tested if the PR really solves the linked issues and
#23756 doesn't look fixed, unless I'm misunderstunding something

#24077 isn't fixed either. Or at least it's impossible to test, because the actions don't appear at all.
#42382 same as above. Can't test print("stuff", <autocomplete here>, because print( doesn't suggest anything.

The autocompletion seems broken on master for some things, which makes testing this difficult.

EDIT:
After switching back to clean build, turns out this PR breaks autocompletion for $ operator.

[Paulb23]

@KoBeWi
Re, #23756: There are now two shortcuts for completing. Enter / Kp Enter which keeps the old behaviour and inserts it inline. Tab is the new behaviour which will replace / merge the text.

Re, #24077 #42382: Yeah not entirely sure how to test these fully on master at the moment. Though the string tracking "should" fix them.

Re, '$': '$' seems to be the same as master for me? Do you have some steps to reproduce your issue?

[KoBeWi]

There are now two shortcuts for completing. Enter / Kp Enter which keeps the old behaviour and inserts it inline. Tab is the new behaviour which will replace / merge the text.

Neat! You should probably mention it in the OP.

'$' seems to be the same as master for me? Do you have some steps to reproduce your issue?

Master:

This PR:

EDIT:
Seems like pressing Ctrl + Space fixes this. Only initial popup has wrong suggestions.

[Paulb23]

CC @bruvzg, I'm not entirely sure about this change. Was there any reason this was ran on all wrapped lines rather then where the caret is?

[qarmin]

Ci crash

CodeEdit.confirm_code_completion
Parameters [False]
ERROR: FATAL: Index p_index = 0 is out of bounds (size() = 0).
   at: get (./core/templates/cowdata.h:157)
handle_crash: Program crashed with signal 4
Dumping the backtrace. Please include this when reporting the bug on https://github.com/godotengine/godot/issues
[1] bin/godot.linuxbsd.tools.64s() [0x1e5e7d8] (/home/runner/work/godot/godot/platform/linuxbsd/crash_handler_linuxbsd.cpp:54)
[2] /lib/x86_64-linux-gnu/libc.so.6(+0x46210) [0x7f712225a210] (??:0)
[3] CowData<ScriptCodeCompletionOption>::get(int) const (/home/runner/work/godot/godot/./core/templates/cowdata.h:157 (discriminator 7))
[4] Vector<ScriptCodeCompletionOption>::operator[](int) const (/home/runner/work/godot/godot/./core/templates/vector.h:89)
[5] CodeEdit::confirm_code_completion(bool) (/home/runner/work/godot/godot/scene/gui/code_edit.cpp:954 (discriminator 1))

This code should crash with same as above message

CodeEdit.new().confirm_code_completion(false)
ClassDB.instance("CodeEdit").confirm_code_completion(false)

[KoBeWi]

Can't you just use the other enum, instead of introducing another one that needs to be the same?

[Paulb23]

That's possible, though it felt incorrect to bind a enum from /core to CodeEdit, not sure of any cases where enums aren't local to the class. Also can't bind it to ScriptCodeCompletionOption as it's a struct, because of that, if we did cross reference, the docs get confused tying to look for ScriptCodeCompletionOption.

[KoBeWi]

Ah, it's required for binding. Not sure then, either we move it to CodeEdit or maybe it's fine to have duplicates if they are commented properly.

[Paulb23]

Yeah that crossed my mind too, but as it's used in script_language, moving it would make /core dependent on /scene, which is a no go.

Not sure there is a clean way out of it as is, without duplicating. The alternative is to not use enums, or we rewrite ScriptCodeCompletionOption into a bindable class, which is a lot easier said then done.

[KoBeWi]

I went over the code and, aside from that weird double enum I mentioned above, it looks mostly ok (although it's a lot of code and I didn't take a very detailed look). Would be nice to have this rebased, so it's possible to test.

[KoBeWi]

I checked again all the linked issues and #42382 is not fixed.

But IMO it's ok if you just remove it from the OP.

There are also many new methods that need to be documented. It would be best to have them filled in this PR, even if very briefly.

[Paulb23]

Updated docs and removed #42382 from the op.

[akien-mga]

Thanks!