Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Njiall
    @Njiall_gitlab
    And this might be the issue as unicode chars are not properly displayed
    smolck
    @smolck

    @smolck I don't know, it installed with cargo I guess how do I check it?

    I mean the system-wide version of pango. What OS are you using? (So I can then look around for how to check the pango version, I honestly don’t know how atm, but it probably varies from OS to OS)

    For Ubuntu (and Ubuntu-based?), maybe dpkg -s pango?
    For Arch (and arch-based probably), try pacman -Qi pango
    Njiall
    @Njiall_gitlab
    I'm using osx mojave, but I don't have superuse rights, so every program I install is in user space
    And I don't think I installed pango with brew
    ah sorry my bad, it is installed, 1.14.6 btw
    so I roll back to 1.43 I guess
    welp I guess I can't :( brew won't let me use a specific version so I'm basically screwed
    smolck
    @smolck
    Unfortunately, if that’s the case, then yes. Right now it’s a bit of a waiting game for when the new pango rust bindings release. That’ll probably make finding a solution easier (and the update might fix the issues, but I don’t know). Sorry I can’t help 😢
    Njiall
    @Njiall_gitlab
    Well it's ok, in the mean time I'll stay in my terminal ^^
    smolck
    @smolck
    @vhakulinen Do you think anything could be gained by upgrading GNvim to use the async/.await pattern once that hits stable rust in November? (async/.await is set to arrive with rust 1.39 in early November ATM)
    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?
    bfredl
    @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
    bfredl
    @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?

    bfredl
    @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?
    bfredl
    @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
    bfredl
    @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)
    bfredl
    @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?
    smolck
    @smolck
    The API ones, defined in https://github.com/daa84/neovim-lib/blob/master/src/neovim_api.rs like https://github.com/daa84/neovim-lib/blob/master/src/neovim_api.rs#L30
    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