Describe the bug
When writing a comment a text having a format //.*``.*\(.*\).*``.+, Ionide slows down and hangs in the end.
To Reproduce
Steps to reproduce the behaviour:
``()`` and keep pushing a. It will look like //``()``aaaaaaaaaaa....Expected behaviour
Nothing bad happens.
Environment (please complete the following information):
Additional context
This bug does not happen while using fsharp-language-server, so I think it is somewhat related to Ionide.
Just to confirm that this also happens if you don't comment i.e. you can omit step 2 above.
At first, I would have said that the issue is coming from the grammar.
But after checking grammar of both fsharp-language-server and Ionide they are almost the same.
fsharp-language-server is using ionide-fsgrammar too but trailling a bit behind
The only difference between both grammar is this one:

As you can see it's just adding support for static let mutable.
And if you say that fsharp-language-server doesn't have the problem. Then the grammar is probably not the source of the issue.
@MangelMaxime I tested it right now and I'm pretty sure fsharp-language-server does not have the problem. Hope this helps :pray:
I can't repro it with Ionide 4 so I think it has been fixed.
hmm, I just reproduced it with Ionide 4.0.4, .NET Core 3.0.100, VSCode 1.36, Debian buster/sid.
I also confirmed that fsharp-language-server does not have the problem (the same behavior as before).
Here is an interesting screenshot: when the problem is happening, the code process is eating up the CPUs while the dotnet process (FSAC) is not.

When I input aaaaaa..., the cpu usage of dotnet process spikes for a very short period of time and returns to normal, while code process uses considerable CPU % for much longer time.
Hope this helps!
@cannorin You may have found a new issue there.
I was running the experimental branch (apparently 0.3.5) and I was able to reproduce this still. I then uninstalled and installed the main branch (4.0.4) and the issue was gone. When I uninstalled and re-installed experimental 0.3.5, the issue is still gone... maybe try having a play with re-installing or swapping the extension out?
Edit: actually, this doesn't seem to be resolved.
The situation was improved (i.e. vscode didn't hang completely) but CPU spikes were still there. Then when I restarted vscode, the original issue was back and it hangs completely, so I'm rather confused. It appears this is reproducible i.e. a fresh install works but CPU load is high, whereas upon re-opening vscode the original issue is back and it hangs completely.
C:\Program Files\dotnet\dotnet.exe" c:\Users\user\.vscode-insiders\extensions\ionide.experimental-fsharp-0.3.5/bin_netcore/fsautocomplete.dll --mode lsp --background-service-enabledis the process that's CPU hungry for me.
@drk-mtr I can reproduce that. Reinstalling and swapping the extension temporarily solves the problem, and the fresh install don't have the problem, but it's back after restarting VSCode in both cases.
I still can repro, on latest VSCode Insider + latest Ionide
And.... I can still repro.
I did another test in order to isolate the problem, if I deactivate the F# grammar using:
{
"name": "fsharp",
"scopeName": "source.fsharp",
"fileTypes": [
"fs"
],
"foldingStartMarker": "",
"foldingStopMarker": "",
"patterns": [
],
"repository": {
}
}
The problem still exist, which confirm that the grammar is not the problem.
I'm having this issue as well. Any non-alphanumeric character while writing between backticks hangs VSCode.
I'm guessing, since this has been open for over a year, that no fix is incoming?
@clindholm I guess we sinply don't know why this happens?
@cannorin I did some testing to see if I could narrow it down a bit more. There is no problem opening files that already have extra characters in backtick functions (I don't know if they have some special name). I disabled autosuggestions which didn't resolve the issue, but it seems to me that it made it less severe. Where before, I had to force quit vscode, it now sometimes become responsive after a few seconds. It freezes when I click anywhere inside the backtick fucntion name. And then if it unfreezes, the whole name is highlighted. So maybe it has something to do with the code that decides the highlight range of a function name?
A few updates on this:
v5.2.0open Xunit
open FsUnit.Xunit
[<Fact>]
let ``hangs when changing the test name`` () =
true |> should equal true
Since this was happening to me quite often, and it seems to be a hard bug to trace, I left the F# output open while editing.
Whilst working on some tests (tests are named with backticks like ``this is my test``) it happened again!
Here are the last lines of the output before it froze:
[14:39:20.170 VRB] [Checker] Current Queue Length is 0
[14:39:20.170 INF] [Checker] TryGetRecentCheckResultsForFile - "/home/path/to/file/Test.fs"
[Error - 14:39:20] Request textDocument/hover failed.
Message: Cannot find ident for tooltip
Code: -32603
Happy to provide mode details.
Same thing is happening to me. Somehow, it will also hang other vs code instances. A way to easily trigger this is to add a ; at the end of a test like such:
let ``this is a test;`` () =
The following consistently reproduces the problem for me:
Steps
dotnet new xunit --lang F#.code .When naming the unit test do not include a comma in the nameExpected Behavior
VS Code editor does not hang.
Actual Behavior
VS Code editor hangs and a dialog appears stating, "The window is no longer responding."

Workaround
Do not include commas in the unit test names.
Environment
Most helpful comment
@cannorin I did some testing to see if I could narrow it down a bit more. There is no problem opening files that already have extra characters in backtick functions (I don't know if they have some special name). I disabled autosuggestions which didn't resolve the issue, but it seems to me that it made it less severe. Where before, I had to force quit vscode, it now sometimes become responsive after a few seconds. It freezes when I click anywhere inside the backtick fucntion name. And then if it unfreezes, the whole name is highlighted. So maybe it has something to do with the code that decides the highlight range of a function name?