Windows IME issues with Chinese full-width characters

From @AndyL report:

Common means I can reproduce the issues on both Windows 10 21H1 and Windows 10 1909.

Issue 1.1 - Cursor in the wrong place when inserting between symbols and texts

To reproduce:

  1. Type some bold texts and then type some regular texts (such as: **Bold**Regular Texts)
  2. Place the cursor after the last * and before the first regular text(R)
  3. Press and hold (please use Chinese IME)

IME Issue 1-1

You can see that the cursor is in the wrong place.

For Issue 1.1, if you use source mode, then it will be solved.

Issue 1.2 - Cursor in the wrong place when editing headers

To reproduce:

  1. Turn on the Editor setting - Collapse Heading
  2. Type a markdown header (such as: #### Header) and make sure there should be some texts below the heading
  3. Select the #### (with space) part
  4. Type (please use Chinese IME)

IME Issue 1-2

You can see that the cursor is in the wrong place (again).

For Issue 1.2, if you turn off Collapse Heading, then it will be solved.

Issue 1.3 - Punctuation gets selected

To reproduce:

  1. Type some bold texts (such as**Bold**) and add a line below it
  2. Place the cursor after the last * and press (please use Chinese IME) for several
    times

IME Issue 1-3

You can see that the second is selected.

For Issue 1.3, if you use source mode, then it will be solved.

1 Like

Setting aside the issue with the older version of win, it seems if there is a problem is only with the char ?

In my demo I only showed but actually every Chinese punctuation like 。、?! behaves the same like .

I can confirm not only full-width punctuations like ,。!? but also other full-width characters like abcdefg(not half-widthabcdefg) have all these problems on Windows 11 21H2 with Obsidian: 0.13.30.

You can use Shift + Space to toggle full-width/half-width.

True and so it is with Windows Emoji like this:
Windows Emoji
(The second :joy: was selected)
Maybe another upstream bug?

I can’t repro the emoji problem.

I have checked the emoji issue and it can be reproduced on both my Windows 10 21H1 and Windows 10 1909. (But anyway, I rarely type two emojis consecutively in practice😂.)

I can reproduce the emoji problem randomly…

Ok, now I can reproduce sometimes.

For the users who use Windows 10 with Windows default Chinese IME(Microsoft Pinyin), I have developed a small tool using AHK(Auto Hotkey), which can improve the type experience a lot (at least from my side). Here is the link and you can read the instruction then download it as a mitigation solution. Then we can wait for the official patch together😊.

Hi Developers,

I have seen that you have mentioned the IME bugs in Discord. I know you have spent time and are bothered with these bugs a lot. I just feel the same way with you. Here is some other information I’d like to share with you.


Let’s start a note with:

**Bold**
123

image


Next, let’s add a :joy: after the **bold** part (Let’s call it Stage 1):

**Bold**😂
123

image


Then, let’s add another :joy: after the first :joy::

**Bold**😂😂
123

You can see that the second :joy: is selected:
image


Let’s delete the second :joy: (Let’s call it Stage 2, which looks the same as stage 1):

**Bold**😂
123

image


Then, let’s add another :joy: after the first :joy:(again):

**Bold**😂😂
123

Now it behaves normally(no unexpected selection).
image


What I want to say is that, Stage 1 looks exactly the same as Stage 2, but they have different behaviors. Sadly I have no idea what’s going on in the background. Maybe you can have some investigation about the difference between these two stages.
(But again maybe you have already known this then please ignore this post…:zipper_mouth_face:)

Thanks again!

Hey, me and sorry to bother (again…).
A new finding: the issue happens also with half-width characters (or say, English characters).
Please see the demo:
Half width characters issues

It’s similar to the Issue 1.3, I started with an inline code block (instead of bold) and then typed a space.
Next, press Win+. for Emoji Keyboard and then select a half width character (in my demo, @).
In this case, the first character after the code block part is space and the second character is @. And you can see that the @ is wrongly selected. (You can change the @ to any other character or even several characters)
(To reproduce the issue, you may try for two or three times since it’s roughly 50% chance for success.)

In a word, it seems that the issue is not related to the character is full-width or half-width, Chinese or English, but related to how the character is inputted (directly by typing on the keyboard or by using some IME conversion). That’s all, thanks!

1 Like

I have a fix coming in 0.14.3.

2 Likes

Amazing!

Hope 0.14.3 could be a public release, these IME-related problems are very inconvenient.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.