@vhakulinen Generating classes for all of the UI events would cut down the size of
neovim_lib/mod.rs in GNvim tremendously, right?
@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
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
#61 is also basically finished, except for issue mentioned here: https://github.com/vhakulinen/gnvim/pull/61#issuecomment-536211499
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
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
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).
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.
(Generating the ui_event stuff)
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.
@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.
This seems relevant on the topic: https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates
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
If you don’t mind opening an issue for this, that would be great.
I tried check it with empty init.vim and it didn't reproduce
Trying find the cause
Found out.
I use
I use
- button to open vinegar (https://github.com/tpope/vim-vinegar). The problem disappeared when I commented line with vinegar.vim connecting.
https://github.com/alexeevit/nvim_config/blob/master/init.vim
Here is my config file.
Here is my config file.
Also, does the crash only happen in GNvim? Or also in terminal nvim?
This line: https://github.com/alexeevit/nvim_config/blob/master/init.vim#L22
It works fine in terminal
It works fine in terminal
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, do
RUST_BACTRACE=full cargo run from the cloned repo and then once it crashes you’ll get the stacktrace).
sounds like #29