Repository navigation
Conversation
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Sep 29, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Sep 30, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Sep 30, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 1, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 2, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 2, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 3, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 3, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 3, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 4, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 5, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 5, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 5, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 5, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 6, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 6, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
trancong12102
added a commit
to aislopware/gpui-kit
that referenced
this pull request
Oct 6, 2026
… IME Finishes longbridge#3297 and takes longbridge#3255. An input method asks where its marked text is (firstRectForCharacterRange) as soon as it marks it, before a paint has laid the text out. bounds_for_range answered from the layout of the text before the edit: an offset past the end of the caret's line matched the start of the next visible line, so the candidate window's rectangle ran from the caret back to the left edge (a negative width, -124.8 px in the test), and an offset the layout did not reach fell to the input's corner. longbridge#3297 falls back to the caret only when no line matches, which a multi-line input never reaches. - The layout records the text revision it shows. While it is behind, the asked-for range is held to the caret it was painted with: the text before it has not moved, and a composition starts there. - The paint that lays marked text out, or moves it, tells the platform to ask again (Window::invalidate_character_coordinates; on macOS NSTextInputContext invalidateCharacterCoordinates), so the candidates follow the composition instead of keeping the first, approximate answer. - An unresolved end keeps to the start rather than (0, 0). From longbridge#3255: InputState::is_composing() for hosts with their own Enter binding, and Enter while an input method holds marked text is left to it: no newline, no menu pick, no PressEnter to read as send. Tests: test_ime_bounds_before_a_paint_hold_to_the_caret (fails before with the -124.8 px rectangle), test_enter_confirms_composition_without_inserting_newline.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Validation
CARGO_TARGET_DIR=/private/tmp/allsum-wayfinder-496/target cargo test -p gpui-base test_enter_confirms_composition_without_inserting_newline --offline -- --nocapturecargo +nightly fmt --all -- --checkPart of the AllSum send-key setting tracked in longbridge/allsum-desktop#496. This PR is the first dependency for the ai-chat Composer change.