Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    smolck
    @smolck
    @Njiall_gitlab What’s your pango version?

    My solution was to downgrade to 1.43 :sweat_smile:

    😂 Seriously. I might end up writing a python script that runs pacman -Syu to upgrade everything on my system, and then runs pacman -U <pango 1.43 tar.gz file> to downgrade pango so I don’t have to 😉

    The thing is, I don’t like telling all Arch users “use pango-ubuntu from AUR for things to work”
    smolck
    @smolck
    Interestingly, if you ceil the cell metrics’s values, GNvim looks better but the cursor gradually drifts away....
    https://github.com/vhakulinen/gnvim/issues/85#issuecomment-529232800

    Not sure whats the point of trying to abstract nvim "away" in gnvim

    For fun and to increase the use of GNvim. Also, might find ways to improve Gnvim too. Obviously you don’t have to help with such a project, just figured I’d ask since I might try doing it.

    smolck
    @smolck
    I wonder if anything will be fixed once the gtk-rs pango bindings are updated? gtk-rs/pango#165
    I sort of doubt it will magically fix everything (I hope it does), but maybe it will provide us with the ability to call functions like pango_context_set_round_glyph_positions mentioned in this Gnome blog that could help us fix the issues.
    *the pango issues we’re having
    Njiall
    @Njiall_gitlab
    @smolck I don't know, it installed with cargo I guess how do I check it?
    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?