Summary

LineEdit did not emit text_changed when text was inserted via Unicode code-point input and the “Insert Control Character” menu. This would break UI logic that depends on text_changed.

Reproduction

Minimal scene with a single LineEdit element and the following attached script:

extends LineEdit
func _ready():
    text_changed.connect(func(new_text):
        print("text_changed:", new_text))

Pressing ctrl + shift + u and typing 2020 then pressing enter inserts the dagger character (†) but does not trigger text_changed i.e. no print statement is written to the console.

Right click + Insert Control Character (pick any) also inserts but does not trigger text_changed.

Fix

After performing the two aforementioned insertions, defer _text_changed() and set the text_changed_dirty guard (exact same process used in paste_text() ). Regular typing and paste behavior remains unaffected. set_text() is unchanged and still does not emit, as per the documentation. This is a small, localized fix in scene/gui/line_edit.cpp

Testing

Verified fix on a Windows dev build, code-point submission and control character insertion now print once to the console and update any bound UI elements. Regular typing, paste, and deletions have been verified to still emit exactly once.

Formatting: clang-format 17

Fixes #110809

Note: There is an overlapping PR #110988 that instead moves the text_changed emission logic to the core function insert_text_at_caret() while removing text.length() != prev_len checks to determine whether to emit text_changed or not. Let me know if this more general change to a core function is preferred, as the changes in my PR attempt to fix two specific bugs without altering core functions while aligning with the existing architecture. A previous PR #84382 also attempted to alter insert_text_at_caret() directly which resulted in duplicate signals.