Panics when using filter functionality

hasufell commented 4 years ago

$ RUST_BACKTRACE=1 hunter
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', src/listview.rs:383:9
stack backtrace:
   0: backtrace::backtrace::libunwind::trace
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/src/backtrace/libunwind.rs:86
   1: backtrace::backtrace::trace_unsynchronized
             at /cargo/registry/src/github.com-1ecc6299db9ec823/backtrace-0.3.44/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:1053
   5: std::io::Write::write_fmt
             at src/libstd/io/mod.rs:1428
   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:204
   9: std::panicking::default_hook
             at src/libstd/panicking.rs:224
  10: hunter::die_gracefully::{{closure}}
  11: std::panicking::rust_panic_with_hook
             at src/libstd/panicking.rs:474
  12: rust_begin_unwind
             at src/libstd/panicking.rs:378
  13: core::panicking::panic_fmt
             at src/libcore/panicking.rs:85
  14: core::panicking::panic
             at src/libcore/panicking.rs:52
  15: hunter::listview::ListView<hunter::files::Files>::selected_file
  16: hunter::file_browser::FileBrowser::save_tab_settings
  17: hunter::widget::Widget::handle_input
  18: hunter::main
  19: std::rt::lang_start::{{closure}}
  20: main
  21: __libc_start_main
  22: _start
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I also find the filter functionality quite confusing. If I filter for e.g. 4 files in a directory it will:

pop those 4 files at the top of the current list. It's unclear to me whether a filter is currently active and why those 4 files show up at the top
when I cycle through those files downwards the selection bar disappears, but apparently files are still cycled

rabite0 commented 4 years ago

Does that happen with current master? I'm currently reworking how files are loaded/stored (splay tree instead of vec), which almost halves loading time because there is no need to sort (atm 1M files in ~350ms on my toaster....). This selected_file function has been giving me quite a headache for a long time in various ways and I'm actually rewriting/debugging it right now... That should get rid of the crash, too.

pop those 4 files at the top of the current list. It's unclear to me whether a filter is currently active and why those 4 files show up at the top

You mean there should be some kind of indicator thing that shows when a filter is active? That would be nice, indeed. Will work on that.

when I cycle through those files downwards the selection bar disappears, but apparently files are still cycled

Huh.. I'm not sure I ever tried cycling through files with the filter. There's also that problem with the //. That might be something I overlooked. I usually use it when I'm in a large/messy directory (~/) and want to find all the pdf files in it or something like that (with filter set to "pdf").

There are a lot of these small issues here and there. Some I'm aware of, some not. When I restarted development in December I was planning on fixing those things and polish hunter up. Instead I got into this optimization rabbit hole and ended up almost exclusively working on making hunter faster and faster. After the next update I'm done with that until the competition catches up and concentrate more on those rough edges. I'm probably just procrastinating, because that stuff is more on the boring side in comparison and unless someone actually complains about it I put it off ;)

hasufell commented 4 years ago