Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    I can do a similar thing with Rust. The only real difference between the Rust version and the Dart one is that in Rust I can wrap everything in an enum for easier usage.
    smolck
    @smolck
    Okay, so I was actually wrong about the return values of neovim-lib's Neovim API functions; they already return a Result of the underlying type, for example Result<bool, CallError>. However, I think I can still do the above.
    (Generating the ui_event stuff)
    smolck
    @smolck
    @vhakulinen If Neovim versions >= 0.4.0 fix the crashing issues people have been seeing, for example in #92, why merge #103? To support people running versions < 0.4.0?
    Ville Hakulinen
    @vhakulinen
    Why not merge it?
    smolck
    @smolck
    Well, the crashes don’t happen on the latest Neovim version (and without the merged PR in GNvim), so is it really necessary? It makes sense if we want to support older versions as I said above, and that’s why I asked. Also, as @bfredl pointed out to me, does the fix make logical sense? If it does then that’s fine by me, I just thought it might be a patch to fix a Neovim bug in GNvim, and I figured we might want to avoid that.
    smolck
    @smolck
    @vhakulinen What do you think of adding a/some issue template(s) to GNvim? I find that a lot of times someone opens an issue, we ask them their Neovim, GNvim, and (right now at least) pango versions, and sometimes then a stacktrace, etc. If we got all that info in the first comment it would make things more striaghtforward.
    Also, there’s PR templates, but I’m not sure we got enough PR’s ATM for them, or that we would even need them.
    *get