Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Björn Linse
    @bfredl
    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
    it was just matter of modifying the existing error instead of creating a new one
    ....and for some reason github isn't detecting that it was merged
    smolck
    @smolck
    Ah, didn’t think of that. 👏
    Yeah, I noticed that..... just merged 😂
    Sort of....
    Anyway, another issue fixed! I’d like to figure out #85 before next release of GNvim, but I’m not sure that’s gonna happen. Part of me wonders if I’m looking in the wrong place and it isn’t a CellMetrics problem, but idk
    smolck
    @smolck

    yea - one down side with that tho' is that when the events change, you need to regenerate everything and backwards compatibility might suffer

    This wouldn’t matter all that much if events are only ever added, since the other fields in the structs wouldn’t change. Whoever was using the changed struct(s) would just need to add support for the new fields (if s/he so desired).

    smolck
    @smolck
    Just committed that, uses jinja2 template to generate the lib/src/ui_events.dart file