sebastiansturm

edit: I just noticed that debouncing should already be there via the consult-async settings, so I'm not quite sure why I've seen those performance problems, given my large `consult-async-input-debounce` value...

could it be that `param->done` sometimes starts out as true? AFAICS, the json rpc state is only malloc'ed without any explicit initialization of the `done` field, and `param->done` is checked...

likewise, I'm sometimes seeing calls to `ssp_recv` with insane values of `sz2` (18446744071878777500 in the log I'm currently looking at), which might be caused by `error_buffer_read` not being initialized on...

sure, let's say I have a module named `Test`, where `Test.mli` contains the following: `type t = private A of int | B (* not declared abstract as that would...

that would be awesome :)

thanks for the bug report, I'll have a look this evening or on the weekend. Not sure if it's just missing face definitions or if tokens are really applied incorrectly;...

I haven't tried the Java server myself, as I'm not sure what code base you're using it on. @ericdallo is probably right though, our default set of faces may not...

FWIW, it seems that the issue can be fixed by adding the following lines to the `(evil-visual-state-p)` branch of `evil-execute-in-god-state`: ``` (remove-hook 'activate-mark-hook 'evil-visual-activate-hook t) (add-hook 'post-command-hook #'(lambda () (add-hook...