Lukas Wirth

Another use case for this is the `expect-test` crate which has problems in some set ups without this env var: https://github.com/rust-analyzer/expect-test/issues/33

I currently have no time nor motivation to work on this in the near future unfortunately.

I am also in favor for the first approach, tying controllers to models, since this should be less error prone due to mistakenly mixing things. Regarding the problem of limiting...

I wouldn't see a problem in having the option to pause single controllers and re-enable them. And yes the good part about having controllers tied to models is that on...

I have been playing around a bit with this and currently got the following structure for controllers and expressions each: - A `Vec` that holds the controllers/expressions where the order...

I've implemented expression handling support for the `UserModel` now with the assumption that at most only one expression will be used(cause it doesnt make sense to me to have more...

I did a quick check and the only things that seem to have changed in the include header are the addition of a new non-dynamic flag and the calling convention...

My plan was to reimplement the framework in rust, since the cubism-core already is a somewhat more rustic wrapper ffi interop would prove difficult. The idea for the crates is...

I've made an extra issue #8 regarding serialization and implemented the model3 files partially myself as to give an idea how I'd think the definitions should be.

Panic location is here https://github.com/rust-lang/rust-analyzer/blob/84a6fac37ad61ff512993ee64b47deff9a52c560/crates/rust-analyzer/src/lsp_utils.rs#L169 Meaning we crashed on an invalid range in the `lsp_types::notification::DidChangeTextDocument` handler ... So the client send us a faulty range (unlikely) or our line index...