you must own exactly twenty (20) well-kept rats (lol)
tell us why you want to maintain a crate that attempted to rewrite hexchat in rust (see "mock" dir/module in the src tree), only to be stopped by rust's lack of support for defining C vararg functions (as used by e.g. the plugin host).
promise not to use serde or syn (concerns about extended compile-time)
(side note: it's "unsafe" because we never figured out how to defeat the rust std and disable std::thread and other such global-state stuff)
well it makes sense to rewrite hexchat in rust so you can maintain a modern version of hexchat written in rust complete with selfref-based GUI system
like, yes, hexchat is unmaintained. this crate began to rewrite hexchat in rust. the plugin API seemed like a good place to start, is all, but otherwise it's basically a way to start maintaining hexchat again.
a lot of the mock system code is roughly ported from C, thanks to the power of selfref, which is what makes this viable.
besides, hexchat forks exist, and they usually keep the plugin API. we'll keep maintaining our fork in C, but we would love to see someone finish this rust rewrite, even if we would not use it ourselves. forks and rewrites are ultimately how free software lives on.