Rasmus Thomsen

It'd also be nice if `LineCache::update` were async - right now I'm having problems with styling in big documents (e.g. in gxi's `edit_view.rs` with Rust syntax highlighting enabled - when...

> it would hlock the loop at each update Oh, alright, wasn't sure how much Tokio's threadpool and handle and how expensive spawning a new thread is - but it...

FWIW this was easy to implement in gxi, see https://github.com/Cogitri/gxi/commit/9315fbe25d21f73a219499e824e8cab7df3e0ecf . Thanks for the pointer :)

> For reference, here is how the cache update is done in xi-macs. I might be interesting to see if they have optimizations we don't: https://github.com/xi-editor/xi-mac/blob/d4ecbcad77928de8e60c7dd33dbb42da9a72a6f8/Sources/XiEditor/LineCache.swift#L103-L208 FWIW gxi's previous linecache...

> This is probably a very stupid question No worries, please do ask these kinds of questions, it's very nice to hear an "oursiders" questions to get different views of...

> As its not a drop in replacement, I would need to adjust a bunch of stuff, Ah, I think it's just replacing `linecache.lines.get()` with `linecache.get_line()` > Then tens of...

It appears that this only happens with documents which are larger than my view (so need scrolling) - or maybe the load on the linecache just increases at that point?

Here's the log: https://gist.github.com/1c117455b09c33e3bd8ded8ce83733b9 Everything starts going wrong at about 38:26/27. I'll look into it tomorrow too, gonna sleep now. Thanks for your help!

So, here's a log of just the linecache, which is way easier to read: https://gist.github.com/cdcc742aad2b6d9b6b42fb361b39aea3 What looks really fishy to me: ``` Line { text: "\tcd \"$builddir\"/build", cursor: [], styles:...

Maybe this is due to odd timing though? Right now I funnel all `XiEvents` through a `SyncSender` to my main thread, which then calls `LineCache::update` (which is also bad due...