You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Today I opened up a markdown notebook that I had been using for awhile and when I added a new code cell and tried to execute it nothing happened.
Here's a screenshot.
To be more precise, I entered the command "ls -la" and when I executed it it just echo'd the command rather than printing it.
I was stumped and tried a bunch of things (e.g. reloading the window, reinstalling the extension,...) before realizing that in the lower right corner of the code cell it was showing "INI" and the icons looked a bit different. It looks like "ini" is indicating the language of the code cell. When I changed that to "sh" it started working again.
Here's what I think happened. I created a markdown cell and inside that markdown cell I nested a code block. I often use nested code blocks inside markdown to provide preformatted output such as errors.
RunMe doesn't preserve the nesting when the file is serialized (discord thread). So when I reopened the file, the nested code block was no longer nested and was turned into a code cell. The inferred language was then "INI". This then seems to cause subsequent newly added code cells to have a default language of "INI".
Is this behavior determined by RunMe or VSCode?
I wanted to log this in GitHub in case someone else encounters similar behavior and wonders how to fix it.
One possible AI might be to create a troubleshooting section in the docs and a description of the problem and resolution to it.
The text was updated successfully, but these errors were encountered:
RunMe doesn't preserve the nesting when the file is serialized (discord thread). So when I reopened the file, the nested code block was no longer nested and was turned into a code cell. The inferred language was then "INI". This then seems to cause subsequent newly added code cells to have a default language of "INI".
Is this behavior determined by RunMe or VSCode?
The VS Code extension is using a neutral net called guesslang as part of https://www.npmjs.com/package/@vscode/vscode-languagedetection to infer a newly inserted (likely due to unnesting you're describing) cell's languageID. While guesslang is pretty decent it performs poorly on short test, e.g. ls -la.
We've lowered the minimum threshold from the recommended 20 characters in the past. However, I'm wondering if we should ignore results like ini (already doing some tricks to bias the inference results). Ini is just so irrelevant to what Runme does.
Today I opened up a markdown notebook that I had been using for awhile and when I added a new code cell and tried to execute it nothing happened.
Here's a screenshot.
To be more precise, I entered the command "ls -la" and when I executed it it just echo'd the command rather than printing it.
I was stumped and tried a bunch of things (e.g. reloading the window, reinstalling the extension,...) before realizing that in the lower right corner of the code cell it was showing "INI" and the icons looked a bit different. It looks like "ini" is indicating the language of the code cell. When I changed that to "sh" it started working again.
Here's what I think happened. I created a markdown cell and inside that markdown cell I nested a code block. I often use nested code blocks inside markdown to provide preformatted output such as errors.
RunMe doesn't preserve the nesting when the file is serialized (discord thread). So when I reopened the file, the nested code block was no longer nested and was turned into a code cell. The inferred language was then "INI". This then seems to cause subsequent newly added code cells to have a default language of "INI".
Is this behavior determined by RunMe or VSCode?
I wanted to log this in GitHub in case someone else encounters similar behavior and wonders how to fix it.
One possible AI might be to create a troubleshooting section in the docs and a description of the problem and resolution to it.
The text was updated successfully, but these errors were encountered: