Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    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
    Ville Hakulinen
    @vhakulinen
    I've been thinking about adding issue templates
    smolck
    @smolck
    @vhakulinen What do you think of #122?
    Ville Hakulinen
    @vhakulinen
    haven't had time to review it yet
    smolck
    @smolck
    :thumbsup:
    Slava
    @alexeevit
    hi there. why gnvim exits when i press - button? ubuntu 18.04, gnvim built from sources.
    smolck
    @smolck
    @alexeevit Hello! Could you give a minimal init.vim and exact steps to reproduce?
    If you don’t mind opening an issue for this, that would be great.
    Slava
    @alexeevit
    Sure, i can open an issue, but i guess the problem isn't too big for this. Anyway i want to discuss the problem here before i will open an issue
    I tried check it with empty init.vim and it didn't reproduce
    Trying find the cause
    smolck
    @smolck
    :thumbsup:
    Slava
    @alexeevit
    Found out.
    I use - button to open vinegar (https://github.com/tpope/vim-vinegar). The problem disappeared when I commented line with vinegar.vim connecting.
    smolck
    @smolck
    Can you link the exact line which causes the problem?
    Also, does the crash only happen in GNvim? Or also in terminal nvim?
    Slava
    @alexeevit
    smolck
    @smolck
    Thanks for the info. I can’t really look into it right now, but if you could open an issue for this I’ll post my findings (whether or not I can reproduce this and what I can gather while debugging if so) there once I get the chance. If/when you do open an issue, please include your Neovim version, GNvim version, minimal init.vim, and steps to reproduce the crash. (We don’t have issue templates yet, otherwise I wouldn’t mention this.) Thanks again!
    BTW if you can provide a stacktrace for the crash that would be very helpful (In case you’re unfaimiliar with Rust, doRUST_BACTRACE=full cargo run from the cloned repo and then once it crashes you’ll get the stacktrace).
    Ville Hakulinen
    @vhakulinen
    @alexeevit can you try with latest gnvim master and latest nvim master?
    sounds like #29
    smolck
    @smolck
    @vhakulinen Do you think a rewrite of the text drawing implementation could fix the pango issues? Or, maybe a better question is if you were to rewrite that portion of GNvim, what would you change?
    I'd really like to start using GNvim again, but those pango issues prevent me from doing so
    Ville Hakulinen
    @vhakulinen
    iirc the problem with pango 1.44 was (is) that we're casting values blindly from floats to integers and that causes some issues. Converting them properly (by ceiling/flooring) should fix the issues.
    smolck
    @smolck
    After just trying the branch, that mostly fixes the issues, but not fully. The right side of the statusline goes off screen, and it also sits higher than it should. Ceiling/flooring the values may fix the artifacts, but it seems to also cause other issues.
    It's strange to me though that Neovim-GTK was fixed (afaik) through rounding, but GNvim wasn't.
    I imagine the drawing's different, but it seems pretty similar. Maybe I could try porting the Neovim-GTK drawing code and see if that fixes the issues. Idk
    Ville Hakulinen
    @vhakulinen
    There probably is just couple spots where the code is doing the flooring and ceiling wrong way around
    or something with double width chars and ceiling/flooring
    but shouldn't be too hard to fix
    smolck
    @smolck
    Hmm okay. Maybe I’ll do some tinkering and see what I can come up with
    Ville Hakulinen
    @vhakulinen
    @smolck I fixed the text going offscreen issue and another related to rendering. Can you test that branch again? It fixed all the issues I could notice on my arch VM.
    smolck
    @smolck
    @vhakulinen Sure! I'll test it rn
    Interesting. It seems to work fine with Hasklig, but Iosevka still has the same issue of the statusline going off screen
    Wait, hold that thought, nvm
    Yeah it seems to work great! Awesome!
    I'm curious, what did you change?
    smolck
    @smolck
    Oh but there is this slight issue with the statusline: Screenshot from 2020-05-14 17-24-37.png
    Ville Hakulinen
    @vhakulinen
    you mean the cmdline? try calling gnvim#set_gui_colors()