Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ville Hakulinen
    @vhakulinen
    Making neovim-lib async could possibly be a huge improvement. We don't even need to wait for the async/await syntax to land before we can start the work on it - the gtk-rs even provides async runner! The catch is that you basically need to rewrite the neovim-lib's session handling.
    @Njiall_gitlab was 1.14 a typo for 1.44 or are you actually using 1.14?
    smolck
    @smolck
    Doesn’t neovim-lib already have an async version of the Session class?
    Björn Linse
    @bfredl
    it seems to use its own AsyncCall traits and callback mechanism. It would be worthwhile with a port to the standard Future trait so that it works with async/await syntax and compatible executors.
    smolck
    @smolck
    Okay, thanks for the info! Once I get the chance (hopefully later today), I’ll get to work on an update for it.
    Ville Hakulinen
    @vhakulinen
    I would preferably port the actual stdout/stdin to run on gtk-rs' runner
    and that would mean that neovim-lib should be using gdk/glib or what not
    Björn Linse
    @bfredl
    I assume this could be done through the AsyncRead/AsyncWrite traits?
    an async neovim-lib shouldn't be tied to a particular executor ideally
    smolck
    @smolck

    I would preferably port the actual stdout/stdin to run on gtk-rs' runner

    Why’s that? Would it make things easier for Gnvim development?

    Björn Linse
    @bfredl
    you would avoid using an extra thread by running everything in the same (glib) event loop
    smolck
    @smolck
    Can’t that be achieved without a library though?
    Björn Linse
    @bfredl
    you need to write code to make it work. That code could be in a library, so that others easily can reuse it.
    Ville Hakulinen
    @vhakulinen
    @bfredl AsyncRead/Write doesn't exists yet in the stdlib so you need to pull in something
    Björn Linse
    @bfredl
    but that's just the "futures" crate right?
    which one is expected to use when writing async/await code
    Ville Hakulinen
    @vhakulinen
    futures is part of stdlib, so you can use that
    and yes, asyncwrite/read will be using that (afaik)
    Björn Linse
    @bfredl
    I mean there is a crate called "futures" make by the rust team (even if it is not part of the stdlib)
    https://github.com/rust-lang-nursery/futures-rs is defining the AsyncRead etc traits
    Ville Hakulinen
    @vhakulinen
    oh, I wasn't aware of that
    smolck
    @smolck
    Currently, with neovim-lib you have to deal with getting a Value from any API function. However, I believe I’ve found a way to completely remove that and just return the underlying type (using generics). Do you think that’d be a welcome change over there? It’s somewhat of a breaking change, but it would make writing things a lot less of a headache IMHO
    @vhakulinen I think the above change could also let us remove the try_* macros
    (in Gnvim)
    Ville Hakulinen
    @vhakulinen
    you mean with serde?
    smolck
    @smolck
    No, I mean I can remove the need to return rmpv::Value in essentially every API function that neovim-lib has. So instead of getting a Value::from(i32) you'd just get i32
    Without any extra crates
    Ville Hakulinen
    @vhakulinen
    What would be such functions?
    Ville Hakulinen
    @vhakulinen
    Those are all created by code generation (in neovim-lib). If you can improve the code generator, do it by all means.
    smolck
    @smolck
    Yes, I learned about it when I was working on dart-nvim-api. There I generate the API functions using essentially the same generator as neovim-lib (taken from there), just modified for Dart. But if you look here: https://github.com/smolck/dart-nvim-api/blob/161ee15d937770f5ad66921da26773e84ba80a41/lib/src/buffer.dart#L25 , you can see that it doesn't return any sort of wrapper around the value (other than Future), just the value itself. I'd like to do this for neovim-lib, and it shouldn't be too hard.
    Ville Hakulinen
    @vhakulinen
    sure, I'm sure daa84 will appreciate such improvement
    I have no control over that repo
    smolck
    @smolck
    Yeah, I know, was just wondering what you'd think, since you use neovim-lib for GNvim and I figured this would clean up GNvim's codebase, mainly nvim_bridge/mod.rs
    Ville Hakulinen
    @vhakulinen
    did you manage to generate the ui events too?
    smolck
    @smolck
    Oh, like generate a proper class for those?
    *proper classes
    Ville Hakulinen
    @vhakulinen
    yea
    because otherwise, the benefits for gnvim would be marginal (for now atleast)
    smolck
    @smolck
    I'll look into that, but I'm not sure how hard it would be. I think Neovim represents them as a series of arrays and maps, yes? The problem is programmatically getting those data structures without calling, say, ui_attach, reading the "redraw" event that then gets sent, and then generating a class from that information.
    @bfredl Is there a good way of getting via RPC the information needed to create a class for a ui event?
    Björn Linse
    @bfredl
    yes api_info.ui_events
    smolck
    @smolck
    Perfect! That would allow me to generate classes for those events in both my dart-nvim-api and neovim-lib
    Using gen_bindings.py
    Thanks!
    @vhakulinen Generating classes for all of the UI events would cut down the size of neovim_lib/mod.rs in GNvim tremendously, right?
    Ville Hakulinen
    @vhakulinen
    yea - one down side with that tho' is that when the events change, you need to regenerate everything and backwards compatibility might suffer
    Björn Linse
    @bfredl
    Nvim might add new fields to events at the end, but should not change the type and order of existing fields
    Ville Hakulinen
    @vhakulinen
    right