It covers additional selections of different words, as well manually adding a cursor in between and selecting the next occurrence. The previous test also was outdated in regards of not testing the implicit call to `select_word_under_caret` made by `add_selection_for_next_occurrence` in case there's no selection.
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.
* Map is unnecessary and inefficient in almost every case.
* Replaced by the new HashMap.
* Renamed Map to RBMap and Set to RBSet for cases that still make sense
(order matters) but use is discouraged.
There were very few cases where replacing by HashMap was undesired because
keeping the key order was intended.
I tried to keep those (as RBMap) as much as possible, but might have missed
some. Review appreciated!
Adds a new, cleaned up, HashMap implementation.
* Uses Robin Hood Hashing (https://en.wikipedia.org/wiki/Hash_table#Robin_Hood_hashing).
* Keeps elements in a double linked list for simpler, ordered, iteration.
* Allows keeping iterators for later use in removal (Unlike Map<>, it does not do much
for performance vs keeping the key, but helps replace old code).
* Uses a more modern C++ iterator API, deprecates the old one.
* Supports custom allocator (in case there is a wish to use a paged one).
This class aims to unify all the associative template usage and replace it by this one:
* Map<> (whereas key order does not matter, which is 99% of cases)
* HashMap<>
* OrderedHashMap<>
* OAHashMap<>
These typedefs don't save much typing compared to the full `Ref<Resource>`
and `Ref<RefCounted>`, yet they sometimes introduce confusion among
new contributors.
They haven't been updated for years and still use the old MainLoop
basic framework instead of the new doctest one.
They're of dubious quality and best redone from scratch using the
new framework.
* API kept the same (Although functions could be renamed to set_metadata/get_metadata in a later PR), so not much should change.
* Metadata now exposed as individual properties.
* Properties are editable in inspector (unless metadata name begins with _) under the metadata/ namespace.
* Added the ability to Add/Remove metadata properties to the inspector.
This is a functionality that was requested very often, that makes metadata work a bit more similar to custom properties in Blender.