Adds the bind `add_selection_for_next_occurrence` to TextEdit, with CTRL+D as the default shortcut.
When the bind is performed, ff a selection is currently active with the last caret in text fields, searches for the next occurrence of the selection, adds a caret and selects the next occurrence.
If no selection is currently active with the last caret in text fields, selects the word currently under the caret.
The action can be performed sequentially for all occurrences of the selection of the last caret and for all existing carets. The viewport is adjusted to the latest newly added caret.
The bind and the behaviour is similar to VS Code's "Add Selection to Next Find Match" and JetBrains' "Add Selection for Next Occurrence". It takes advantage of the multi-caret API.
The default shortcut for `select_word_under_caret` has been changed to ALT+G, in order to give priority to CTRL+D for `add_selection_for_next_occurrence` to better align with popular IDEs and editors.
Removes separate `Command` key (use `Meta` instead).
Adds an event flag to automatically remap `Command` <-> `Control` (cannot be set alongside `Control` or `Meta`).
Update TextEdit gutters subcase, gutter add and remove to ensure gutter total width is correct
Fix test_code_edit symbol lookup test case to include padding (+2)
Also fix:
- Geometry3D::get_closest_distance_between_segments() returning
incorrect values.
- Test for Geometry3D::get_closest_distance_between_segments() testing for
an incorrect value.
This reverts commit 4b817a565c.
Fixes#64988.
Fixes#64997.
This caused several regressions (#64988, #64997,
https://github.com/godotengine/godot/issues/64997#issuecomment-1229970605)
which point at a flaw in the current logic:
- `Control::NOTIFICATION_ENTER_TREE` triggers a *deferred* notification with
`NOTIFCATION_THEME_CHANGED` as introduced in #62845.
- Some classes use their `THEME_CHANGED` to cache theme items in
member variables (e.g. `style_normal`, etc.), and use those member
variables in `ENTER_TREE`, `READY`, `DRAW`, etc. Since the `THEME_CHANGE`
notification is now deferred, they end up accessing invalid state and this
can lead to not applying theme properly (e.g. for EditorHelp) or crashing
(e.g. for EditorLog or CodeEdit).
So we need to go back to the drawing board and see if `THEME_CHANGED` can be
called earlier so that the previous logic still works?
Or can we refactor all engine code to make sure that:
- `ENTER_TREE` and similar do not depend on theme properties cached in member
variables.
- Or `THEME_CHANGE` does trigger a general UI update to make sure that any
bad theme handling in `ENTER_TREE` and co. gets fixed when `THEME_CHANGE`
does arrive for the first time. But that means having a temporary invalid
(and possibly still crashing) state, and doing some computations twice
which might be heavy (e.g. `EditorHelp::_update_doc()`).
- Test constructors and quaternion product.
- Add test case for Axis-Angle construction about Y-axis.
- Add test case for xform of i-, j-, & k-unit vectors.
- Add test case for construction from Basis.
- Add test case for xform of arbitrary vector.
- Add stress test case: many Quaternions xform many vectors.
- Make comments consistent with style guide.
Implements the standard Unix double dash (--) commandline argument:
* Arguments after a double dash (--) are ignored by Godot and stored for the user.
* User can access them via `OS.get_cmdline_user_args()`
Example:
`godot.exe scene_to_run.tscn --fullscreen -- --start-level 2`
This was removed in #63481, and we confirmed that it's better like this,
but we add back the possibility to strip CR as an option, to optionally
restore the previous behavior.
For performance this is done directly in `String::parse_utf8`.
Also fixes Android `FileAccess::get_line()` as this one _should_ strip CR.
Supersedes #63717.
- RPC configurations are now dictionaries.
- Script.get_rpc_methods renamed to Script.get_rpc_config.
- Node.rpc[_id] and Callable.rpc now return an Error.
- Refactor MultiplayerAPI to allow extension.
- New MultiplayerAPI.rpc method with Array argument (for scripts).
- Move the default MultiplayerAPI implementation to a module.
This PR implements a worked thread pool. It uses a fixed amount of threads in a pool and allows scheduling tasks
that can be run on threads (and then waited for). It satisfies the following use cases:
* HTML5 thread count is fixed (and similar restrictions are known in consoles) so we need to reuse threads.
* Thread spawning is slow in general, so reusing threads is faster anyway.
* This implementation supports recursive waiting for tasks, making it less prone to deadlocks if threads from the pool also run tasks.
After this is approved and merged, subsequent PRs will be needed to replace the ThreadWorkPool usage by this class.
