Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Ville Hakulinen
    @vhakulinen
    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
    smolck
    @smolck
    @vhakulinen Would you mind giving #101 a look over? It’s basically ready for merge, just a slight problem with having two of the error: message at the start
    Ville Hakulinen
    @vhakulinen
    right, I'll do that next
    I started to work at a new place lately so its been a bit hectic - maybe I can manage to find more time for gnvim soon again
    smolck
    @smolck
    Okay, sounds good! I hope so ;)
    #61 is also basically finished, except for issue mentioned here: https://github.com/vhakulinen/gnvim/pull/61#issuecomment-536211499
    Ville Hakulinen
    @vhakulinen
    merged #101 and managed to fix the double error: in the error message too