vscode-markdown: Non-keyboard IME doesn't work correctly (Alfred, aText, AutoHotkey, Beeftext, Breevy, EVKey, Keyboard Maestro, UniKey, etc.)

The same thing that this extension and Vim extension both do is listening to some certain key pressing and then do some text editing.

This extension override these keys (enter, tab, backspace etc.)

https://github.com/neilsustc/vscode-markdown/blob/cdbe30420f1d2740c9232a2e249628ffa31d9935/src/listEditing.ts#L8-L20

It does nothing with ASCII characters, so it is wired why this issue happens

So disabling the keyboard shortcut markdown.extension.onBackspaceKey does the job for me. It looks like the only place this is used is when backspacing on list markers which I don’t mind not having.

I have the same problem with AutoHotKey and Markdown All in One. It recently started to be an issue. In non .md files, my text expand correctly. However, it does not in .md files. Maybe this is caused by an update of VS Code, Markdown all in One, or AutoHotKey?

Yes, I have the same issue. markdown all in one is a great ext. But it doesn’t let me expand my AHK snippets. Using it on windows 10 and autohotkey.com. For example, this snippet:

::dxt::DevExtreme

So when I type “dxt”, it’ll expand to “DevExtreme”. However, I get this with the extension enabled:

“dxDevExtrem”

aText was not mentioned here but it’s another text expanding tool that has this issue when Markdown All in One is enabled.

Ok, for AutoHotkey Hotstrings, this works:

:SE, K1:dx::DevExpress

One millisecond delay but it does the job.

From here: https://autohotkey.com/board/topic/63377-delay-in-hotstring/

I have a lot of hotstrings so I likely may not use it since I can live w/o MarkDownAllInOne Ext. But hopefully it helps others.

@yzhang-gh One of my colleagues suggested a workaround for macOS users who encounter this sort of issue with Alfred.app. They suggested adjusted the text expansion speed in the app, starting with this option in the Snippets section in Alfred Preferences:

Next, adjust the Simulated key event speed to Average or Slow, here:

I had this set to Fastest. When I adjusted the speed to Average, I didn’t see the text expansion issue in VS Code with the Markdown All in One extension enabled. I still want to do some more testing, but this adjustment in the Alfred.app settings seems to do the trick.

Tested on:

• Alfred v4.0.9
• macOS 10.15.5
• VS Code 1.45.1
• Markdown All in One v3.0.0

Copied from VSCodeVim/Vim#2845

Workaround

I have also experienced this issue, and was successfully able to work around it by opening Alfred Preferences > Snippets > Auto Expansion Options > Tweaking and setting Simulated key event speed to 4/5 (the level below Faster). Still, would be nice if this was fixed!

For AutoHotKey users, you can try if there is any similar “speed” option.

I just tested text expansion using TextExpander (another text expansion app for macOS and Windows), and I don’t see the same issue with that app. It looks like there may be something about how Alfred interacts with VS Code, and Markdown All in One, that causes the issue I reported.

I’ve asked for some insights into how Alfred interacts with editors over at the Alfred forum, in case the team there has any they can share: Text expansion issue when working in VS Code - Discussion & Help - Alfred App Community Forum.

Thank you for this really detailed bug report.

Could you please describe how Alfred.app works? Expanding on tab key? (I’m not a Mac user so not familiar with those tools)

The same thing that this extension and Vim extension both do is listening to some certain key pressing and then do some text editing. This extension override these keys (enter, tab, backspace etc.) neilsustc/vscode-markdown@cdbe304/src/listEditing.ts#L8-L20 It does nothing with ASCII characters, so it is wired why this issue happens

So disabling the keyboard shortcut markdown.extension.onBackspaceKey does the job for me. It looks like the only place this is used is when backspacing on list markers which I don’t mind not having.

In case anyone find useful, I’m using https://github.com/espanso/espanso with the trigger :det for:

<details>
<summary>
$|$
</summary>
</details>

and it wasn’t working until I disabled markdown.extension.onEnterKey as well (disabling markdown.extension.onBackspaceKey was not enough).

Before:

After:

To disable, on keybindings.json:

[
	...
    {
        "key": "enter",
        "command": "-markdown.extension.onEnterKey",
        "when": "editorTextFocus && !editorHasMultipleSelections && !editorReadonly && !suggestWidgetVisible && editorLangId == 'markdown' && vim.mode != 'CommandlineInProgress' && vim.mode != 'EasyMotionInputMode' && vim.mode != 'EasyMotionMode' && vim.mode != 'Normal' && vim.mode != 'Replace' && vim.mode != 'SearchInProgressMode' && vim.mode != 'SurroundInputMode' && vim.mode != 'Visual' && vim.mode != 'VisualBlock' && vim.mode != 'VisualLine'"
    },	
	...
]

I can confirm that the exact same issue is also present on Windows 8.1 with the Breevy text expander and the Beeftext text expander.

I couldn’t get Beeftext to work with Markdown All in One, but there’s a workaround for Breevy:

Set “Output Method” to “Clipboard” in the preferences. (The default is “Key press simulation”.) Now it takes noticeably longer to expand the snippets, though, so I might not use Markdown All in One (I just started using VS Code).

A permanent fix would be wonderful.

Thanks. Looks like the same solution as #200 (comment)?

Ah, right! Sorry! I finally caught up with you there.

Another Authotkey user here! 😃

On my machine, Mehul’s solution with the 1ms delay takes noticeably longer to actually insert some text. I found the following solution which inserts it in a less “chunky” manner. Adjust the 1ms till it works for your setup 😃

; This worked
::dx::{Sleep 1}DevExpress

; For longer hotstrings, I needed more
::azerty::{Sleep 60}DevExpress

With 250ms pretty much any length of hotstring expanded correctly. I answered this Stackoverflow question with details from this issue.

The same bug might have been present in an earlier version of VSCode: https://github.com/microsoft/vscode/issues/1934

They make mention of this commit fixing it. Unfortunately it’s a rather large commit 😦 https://github.com/microsoft/vscode/commit/a1bd50f63fd8185a13495ff3d4c67396109e4e71 Commit msg: “Fixes #1168: Read synchronously from textarea”

The problem has to do with the backspace remapping.

Take the following autohotkey hotstring:

::tada::🎉

This will make typing “tada” followed by one of the “EndingChars” (space, tab, comma, dot, …) expand to the 🎉 emoji.

What you see visually happening on the screen is that Autohotkey does this by first sending a backspace to the editor 4 times (length of hotstring “tada”) and then inserts the replacement text (🎉)

What happens when this (pretty fantastic) extension is active is that the first x characters get deleted then the replacement text gets inserted and then the remaining (hotstring length - x) characters get deleted. But because the cursor is now at the end of the replacement text… which gets chewed on 😃

I’ll have to learn how to debug the IDE itself or always add a {Sleep 250} to my hotstrings…

Thanks for checking.

Just checked VSCode and VSCodeVim repo and Alfred forum but none of them has any update. It is hard to tell what is the root cause.

I’ve created a bug in the Vim plugin for anyone that wants to follow it: https://github.com/VSCodeVim/Vim/issues/2845