Panic when unwrap on None

[ocehugo]

Similar to #88 I think. triggered while typing/completion python code with 3 splits (one terminal buffer). Second time this happens, so turning on the backtrace to try to catch more info in the meantime.

NVIM 0.4.4 gnvim v0.1.6-55-g284c373 webkit-gtk 2.26.4

backtrace:

thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/nvim_bridge/mod.rs:443:24
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.46/src/backtrace/mod.rs:66
   2: std::sys_common::backtrace::_print_fmt
             at src/libstd/sys_common/backtrace.rs:78
   3: <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt
             at src/libstd/sys_common/backtrace.rs:59
   4: core::fmt::write
             at src/libcore/fmt/mod.rs:1076
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1537
   6: std::sys_common::backtrace::_print
             at src/libstd/sys_common/backtrace.rs:62
   7: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:49
   8: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:198
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:218
  10: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:486
  11: rust_begin_unwind
             at src/libstd/panicking.rs:388
  12: core::panicking::panic_fmt
             at src/libcore/panicking.rs:101
  13: core::panicking::panic
             at src/libcore/panicking.rs:56
  14: <gnvim::nvim_bridge::GridLineSegment as core::convert::From<rmpv::Value>>::from
  15: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
  16: gnvim::nvim_bridge::parse_single_redraw_event
  17: <core::iter::adapters::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
  18: gnvim::nvim_bridge::parse_notify
  19: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  21: glib::main_context::<impl glib::auto::main_context::MainContext>::with_thread_default
  22: glib::main_context_futures::TaskSource::dispatch
  23: g_main_context_dispatch
  24: <unknown>
  25: g_main_context_iteration
  26: g_application_run
  27: <O as gio::application::ApplicationExtManual>::run
  28: gnvim::main
  29: std::rt::lang_start::{{closure}}
  30: std::rt::lang_start_internal::{{closure}}
             at src/libstd/rt.rs:52
  31: std::panicking::try::do_call
             at src/libstd/panicking.rs:297
  32: std::panicking::try
             at src/libstd/panicking.rs:274
  33: std::panic::catch_unwind
             at src/libstd/panic.rs:394
  34: std::rt::lang_start_internal
             at src/libstd/rt.rs:51
  35: main
  36: __libc_start_main
  37: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[vhakulinen]

Hmmmmm. You might need neovim's nightly release. I'm not completely sure and I've failed to follow which neovim features gnvim uses and from which version each feature comes from. Can you try with neovim's nightly?

[vhakulinen]

Gnvim was rewritten from ground up for gtk4. If the problem persists, feel free to reopen this issue.