strager

The "buffer randomly disappearing" bug happens in Vim too! I used Vim version 8.2.0823 for a while and never saw the bug. I upgraded to Vim version 9.0.0001 and saw...

When the bug happens, `getbufinfo` claims that the quickfix buffer is hidden: > [{'lnum': 1, 'bufnr': 38, 'variables': {'did_ftplugin': 1, 'undo_ftplugin': 'set stl

^ the above comment was failing to *close*, not failing to open. For failing to open, I think there's another bug (my fault): 1. open a tab 2. :copen 3....

I don't plan to work on this patch. Feel free to take it over. 👍

> [...] I don't necessarily agree with that site that faster is better in that case. > > When typing the code, it is very often invalid until the user...

On top of parsing being slow, *layout* is slow (~53 ms) even for small changes (single character additions within a line).

On [this program](https://pastebin.com/raw/N6MJZ6H8), linting 12 times took 1115.6 milliseconds in Edge on my 5950X on Linux. 382.2 milliseconds were in wasm. 468.8 milliseconds were in "Layout". john_hillington_ reported slowness on...

Each change, the demo currently creates one giant text node, then splits it up. This is expensive. Ideally, we'd reuse text nodes from the previous run. Short of that, we...

Another approach is querying the location of the marks using Range#getClientRects. This prototype seems to roughly work: ```js let range = window.document.createRange(); range.setStart(editor.childNodes[0], 50); range.setEnd(editor.childNodes[0], 53); let rects = range.getClientRects();...

In Edge, getClientRects is relatively slow (~2 ms per call; 15 ms on a jQuery example with a few marks). Synchronizing the shadow code input is the real beast though...