Atelier-Mirai
commented
8 months ago Open Atelier-Mirai opened 8 months ago
Atelier-Mirai
commented
8 months ago 
savetheclocktower
commented
8 months ago The next time you see this, can you open up the developer tools and look for that same message in the console? Then scroll up a bit and see if there's a warning that begins with
Warning: parser wants to call function…
and if so, show me what it says.
Meanwhile, I'll see if I can reproduce this on my own. Thanks for the report!
savetheclocktower
commented
8 months ago Also, if you can discover a situation in which this error happens every time, please update this issue with specific instructions. That situation may or may not exist, but it'd be amazing if it did.
Atelier-Mirai
commented
8 months ago Thank you for your guidance. I looked at the developer tools and found a large number of errors and warnings.
There was also a Warning: parser wants to call function. It seems to be happening in tree-sitter.js. The log is attached. We hope this will be of some help.
savetheclocktower
commented
8 months ago Thanks, that's helpful.
Also, you don't need to revert to 1.112; you can insert the following at the end of your config.cson file:
".gfm.source":
core:
useTreeSitterParsers: falseThat will disable the Tree-sitter parser for Markdown, but retain all others. When this issue is closed, that'll be a sign that the next release will fix this bug and you'll be able to remove those lines from your config.cson.
Atelier-Mirai
commented
8 months ago Thank you for your support.
We have added a note to config.cson, but the problem continues to occur.
I am not sure how to reproduce the problem exactly since it occurs occasionally, but I have also taken the error log and am attaching it herewith.
savetheclocktower
commented
8 months ago So I'll try to summarize the problem for anyone who might be reading. If @Atelier-Mirai's description gives you ideas on how to reproduce this, please share them.
The tree-sitter-markdown parser we use relies heavily on an external C scanner. Emscripten is the tool that turns Tree-sitter parsers into .wasm files, and it typically knows how to deal with scanners that rely on functions defined in C.
But tree-sitter-markdown makes heavy use of assert — which isn't a standard library function as such, but rather a macro that performs basic sanity checks. When you write assert(foo), you're generally saying that if foo is true, then something very strange has happened, and the program should exit. I've been researching it, but I can't find evidence of Emscripten being able to handle assert. (The ASSERTIONS flag that the message describes appears to be a separate thing.)
The parser has an “avoid crash” mode where, instead of using asserts, it throws exceptions that are then caught at the top-level scan function, which then tries to recover despite the violated assumptions. Except that Emscripten doesn't support exceptions by default; you can enable it, but it is described as having “relatively high overhead.” It sounds like a thrown exception has to cross the bridge from WASM back out into JavaScript. I'd love to avoid that if I could. That page also mentions a native WebAssembly exceptions proposal that is probably implemented in Chrome by now, and could probably be an option once we upgrade Electron, but not on the version we're on right now.
It would help if I could reproduce an example of the parser failing one of these sanity checks, but ultimately I've got to figure out how the parser should behave in these scenarios if we can't use assert or C++ exceptions. It's frustrating that lots of Tree-sitter parsers — including some first-party parsers! — don't seem to routinely test themselves in the web-tree-sitter bindings.
There is another tree-sitter-markdown parser that is actively maintained, and I'd love to use it, but there are some show-stopping bugs I can't seem to get around. I spent several hours last night revisiting this parser to see if any of them were fixed, but this issue I filed last March is still present in Pulsar. (It's always possible that this is an intractable web-tree-sitter bug, or that I'm just making a simple error, but this issue filed in nvim-treesitter is reassuring because it means this is probably a subtle parser bug.)
Ultimately the answer might be to fork one of these parsers — I hate it, but I have to at least consider the idea — and change how it behaves. Tree-sitter was meant to be used for editors, and a parser that fails the first time its assumptions are broken is not something that works in an editor environment where a document may expect to vacillate between validity and invalidity whenever the user types.
savetheclocktower
commented
8 months ago We have added a note to config.cson, but the problem continues to occur.
Make sure that the config entry is on its own line in your config.cson and that you don't have any other top-level keys equal to ".gfm.source". Once you've made the change in your config.cson, save it, close your markdown file, and re-open it. It ought to reopen using the older TextMate grammar.
It should look like this at the end of your config.cson:
If you already have other custom settings for ".gfm.source", you can instead merge the sections, like this:
".gfm.source":
editor:
softWrapHangingIndent: 0
core:
useTreeSitterParsers: falseThank you for the guidance. I tried to see if a slightly newer version would change things.
1.113.2024011715 arm64However, I still had to quit the editor due to occasional errors at Japanese input timings. (I wish I could specify the keystrokes that would cause this, but I haven't been able to identify them.)
I am trying to do the config.cson as you suggested.
"*":
core:
automaticallyUpdate: true
destroyEmptyPanes: false
themes: [
"one-dark-ui"
"monokai"
]
useExperimentalModernTreeSitter: true
editor:
defaultFontSize: 17
fontFamily: "HackGen, Menlo, Consolas, DejaVu Sans Mono, monospace"
fontSize: 17
softWrap: true
"exception-reporting":
userId: "6******1-6**b-4**4-b**e-d**********5"
"linter-ui-default": {}
"tree-view": {}
welcome:
lastViewedChangeLog: "1.102.2023021605"
showChangeLog: false
showOnStartup: false
wordcount:
alwaysOn: true
showwords: false
".gfm.source":
core:
useTreeSitterParsers: false
".review.source":
editor:
autoIndentOnPaste: falseI don't know much about tree-sitter, assert, and WASM. I hope it will be resolved.
Thanks in advance for your bug report!
What happened?
Deleting a character causes the editor to freeze.
Specifically, it seems to occur occasionally (about once an hour) when deleting Japanese characters (non-ASCII, double-byte characters) while editing a markdown file (extension .md) by deleting lines with Ctrl + K or Delete / Backspace.
The character encoding is UTF-8.
Pulsar version
1.113.0 arm64
Which OS does this happen on?
🍎 macOS
OS details
macOS Sonoma 14.2.1(23C71)
Which CPU architecture are you running this on?
Apple M1/M2
What steps are needed to reproduce this?
Input Japanese (non-ASCII double-byte characters). Approximately 3,000 characters.
Then use Ctrl + K or Delete / Backspace to delete characters.
Then it seems to occur occasionally (about once an hour).
Maybe there is a timing between entering and deleting characters, but I don't know the details.
If you type in Japanese and try to correct a typing error by pressing Backspace or other keyboard shortcuts during the Kanji/Kana conversion process, the Hiragana characters remain as you typed them in.
It seems that invisible characters are inserted after the finalized characters. By deleting the invisible characters along with the characters before and after the correctly entered characters, you can continue with the editing process.
I upgraded to 1.113 yesterday and have been using 1.113 since today. Since this did not occur with 1.112, I am going to revert back to 1.112 for now, but I would like to report this in the hope that it will help in the development process.
Additional Information:
Prerequisites
Description
Steps to Reproduce
Expected behavior:
Actual behavior:
Versions
Pulsar: 1.113.0 arm64 Electron: 12.2.3 OS: macOS 14.2.1 Thrown From: Pulsar Core
Stack Trace
Uncaught RuntimeError: Aborted(). Build with -sASSERTIONS for more info.
Commands
Non-Core Packages
Additional Information