Vscode-markdown: Text snippets don't expand correctly when using text expansion (Alfred, AutoHotKey)

[pauljacobson]

Introduction

I use Alfred.app for text expansion. I noticed that when I try to expand text snippets in VS Code with Markdown All in One enabled, the text snippets fail to expand completely.

Expected behavior

When using Alfred.app to expand text snippets, the text snippets should expand fully. For example, I've configured Alfred.app to expand ,ymd into the current date, using this format: 2018-06-08.

Another example is lipsum1 that expands into the following:

Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

Actual behavior

Instead of expanding these simple snippets correctly, the snippets expand partially, leaving the first character of two of the snippet in place. Here is a demonstration of text expansion with Markdown All in One _disabled_, and _enabled_):

Steps to reproduce behavior

1. I started VS Code with all extensions disabled. My text snippets expanded correctly, so this isn't an issue with VS Code.
2. I restarted VS Code normally, and tested my snippets again. I was able to reproduce the issue.
3. I disabled Markdown All in One, attempted the snippets again. This time, the snippets expanded correctly.
4. I re-enabled Markdown All in One again, the issue returned.

I captured the following error logs using VS Code's Developer Tools while testing with the Markdown All in One extension _enabled_:

https://gist.github.com/pauljacobson/e726698e68d7be5deeb727079fa8cf78

When I tested with Markdown All in One _disabled_, there were no errors in the Developer Tools console.

System information

OS: macOS 10.13.4
RAM: 16GB 2133 MHz
Model: MacBook Pro (15-inch, 2017)
VS Code version: 1.24.0 (this issue manifested with previous versions of VS Code)

[yzhang-gh]

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)

[pauljacobson]

@neilsustc I'm not sure about the mechanics of the app, I'm afraid. What I can tell you is the process from my perspective:

1. I create a snippet in Alfred. I'll specify three aspects:
   
   
   
   1. The snippet name (more so I can find it)
   
   
   2. The snippet trigger (for example ,ymd
   
   
   3. The text to be inserted when I activate the trigger.
   
   
2. Alfred then basically listens for the trigger when I type it inline (I can also open a small dialogue and trigger the snippet from there).
3. When I type the trigger, Alfred replaces that trigger text with the text. In this example, typing ,ymd produces this: 2018-06-09 (the current date).

It may be possible to use the TAB key as a trigger. I've just configured my app to replace the trigger with the text snippet as soon as I type it.

This is system-wide. I can use it on the command line, in browser text fields, text editors, etc. Basically wherever there is a text field on my laptop. Here is some more information about Alfred, specifically, from a user perspective: Snippets and Text Expansion - Alfred Help and Support.

[yzhang-gh]

Thanks for the information. It seems that Alfred.app listens to the typing events and does auto-replacement.

But I really have no idea about how this extension conflicts with it 😔. One suspected reason might be performance issue caused by this extension, e.g. #181. I'm not sure but let's wait to see whether this will be also resolved by #181.

[pauljacobson]

@neilsustc Thanks for the feedback, and for being so responsive!

[pauljacobson]

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.

[yzhang-gh]

Will keep an eye on it

[wayne-huang-14]

Hi there, Not sure if this will help you
https://stackoverflow.com/questions/51249651/cant-expand-alfred-3-snippets-at-integrated-terminal-within-visual-studio-cod/51271241

Try playing around with the settings in Alfred "Auto Expansion Options" in the Snippets section menu. Seems like it's quite buggy. After setting the delay shorter it "sometimes" works by expanding fully but other times the simulated keys still stay there.

[yzhang-gh]

@wayne-huang-14 Thanks. To my understanding, the original post suggests setting a longer delay, right?

[wayne-huang-14]

It doesn't work well as expected tho because if you don't hit the keys in the exact delay it won't auto expand the snippet and in the correct way. So this isn't really a good fix.
I've used the snippet feature in many apps and I found only VSCode hinders its use.

[pauljacobson]

Thanks for the input, @wayne-huang-14. I'm using Alfred text expansion in Atom and it worked just fine. It works fine in VS Code with the Markdown All in One extension disabled.

@neilsustc Is there something about how your extension loads, or watches typed text that could be clashing with the text expansion?

[wayne-huang-14]

hmmm I'm using the Vim plugin and it turns out if I disable it then the snippet expansion would work.

[yzhang-gh]

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

[wayne-huang-14]

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

[jflheureux]

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?

[pauljacobson]

@jflheureux This seems to have more to do with VS Code itself, although I have no idea how.

[Mehul]

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"

[yzhang-gh]

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.

[Mehul]

Thanks for checking.

[doggy8088]

https://stackoverflow.com/a/53635894/910074

[yzhang-gh]

_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.

[Mehul]

Thanks, I'm trying AHK's SetKeyDelay without luck but I'll dig into it some more.

[Mehul]

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.

[Laoujin]

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...

[yzhang-gh]

@Laoujin Thanks for sharing! It is really helpful. We have several workarounds now.

I guess this issue can be resolved if we make onBackspaceKey hook _fast enough_. But I doubt whether that fast can be practically achieved with current VSCode mechanism. We might need some performance profiles. (need to install a debug version v2.4.0-issue483.zip first)

[Laoujin]

The commit that fixed this issue in VSCode itself has as message: "Read synchronously from textarea"

Is it possible that backspace does some stuff asynchronously? And if we turn that into synchronous code that the issue is fixed?

[yzhang-gh]

Looks reasonable. I can have a try.

[pauljacobson]

@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

[yzhang-gh]

@pauljacobson Thanks. Looks like the same solution as https://github.com/yzhang-gh/vscode-markdown/issues/200#issuecomment-493770482?

[pauljacobson]

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

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

[peter-fb]

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.

[yzhang-gh]

Thanks for the information. Actucally, it is more of a VSCode bug as Vim extension also has this issue https://github.com/yzhang-gh/vscode-markdown/issues/200#issuecomment-405346505. So we probably cannot fix it on this side.

[peter-fb]

I see, thank you.

It seems this might be the corresponding VS Code bug: #51510
It was closed, but not resolved, though.

[chodorowicz]

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

[ssent1]

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

Like @chodorowicz, I'm also experiencing the same issue with aText.

☛ aText doesn't have any way to adjust the simulated key event speed.

[antistic]

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.