Bike IME problem: invisible placeholder after deleting unfinished codes

Bike Outliner
1

Hi Jesse,

I’ve attached a short screen recording and the log file from Logs Explorer for reference. Hope this helps you reproduce and track down the issue.

I’ve been testing Bike 2 Preview and came across a small IME-related issue that I thought I’d report. It’s not a dealbreaker, but it does affect the typing experience with Chinese input methods.

Environment

Bike version: 2.0 preview (298)

macOS: 26.5 (25F71)

Input method: System Wubi (system language set to Chinese)

This issue does not occur in Bike 1.

What happens
When using System Wubi in Bike 2, after deleting an unfinished code string (i.e. before selecting a character), the editor seems to leave behind some kind of invisible placeholder at the end of the line. Specifically:

  • Pressing Delete (backspace) takes about 3 presses to remove the last visible character.

  • Pressing the left arrow key takes about 3 presses to move the cursor one position to the left.

Steps to reproduce

  1. In Bike 2, place the cursor after some existing text (e.g. type “这个”).

  2. Switch to System Wubi and type a code string like ukjg — but do not press space to finalise the character selection.

  3. Press Delete (backspace) to remove the code string (ukjg) completely.

  4. Now try pressing Delete or the left arrow key — the delay described above can be observed.

Log analysis (from the built-in Logs Explorer)
During the “cancel marked text” phase, the Logs Explorer shows the following state changes (cursor at position 2, after “这个”)

[trace] IME: setMarkedText: "" selectedRange: 0..<0 replacementRange: NSNotFound
[trace] IME:   state after: selectedRowRange=Optional(Range(2..<2)), markedRowRange=Optional(Range(2..<2)), text=""
[trace] IME: hasMarkedText() -> true
[trace] IME: markedRange() -> 2..<2 (charRange: 2..<2)

What this seems to show:

  1. When the input method calls setMarkedText:"" (empty string) to cancel the current input, Bike 2 sets markedRowRange to Range(2..<2) — a zero-length range anchored at the cursor position.

  2. After that, hasMarkedText() returns true, and markedRange() returns 2..<2, suggesting that the system still believes there’s a “marked region” even though it’s empty.

  3. The subsequent Delete key press (insertText: "\u{08}") interacts with that empty marked range first, and the cursor position then jumps around in the logs (selectedRange flickers between 2, 3, and 1). It looks like the logical cursor offset gets out of sync with the actual text storage.

That’s everything I found from the Logs Explorer — just wanted to share the raw observations. The attached video and log file should make it easier to see the behaviour in action.

Thanks as always for your work on Bike!

ime log.txt (18.1 KB)

screen recording

1 Like
2

FWIW I can reproduce that here with the:

  • Pinyin Simplified
  • Pinyin Traditional

IMEs, though, to be honest, I have never really noticed or been distracted by it :slight_smile:

Something to do with the number of bytes per character ?

(single byte characters in the IME input string, specifying strings of multi-byte characters ?)

1 Like
3

Digging into this, thanks for the easy to reproduce instructions.

4

Please try latest release for fix: Bike 2.0 (Preview 299)

2 Likes
5

Working well here for the the simplified and traditional Pinyin IMEs

1 Like
6

That was lightning fast! Just pulled the latest update and it works like a charm. Really appreciate your time.

1 Like