When displaying files with long non-ascii filenames (locally or remotely), termscp panics. Presumably this is due to incorrect line-wrap / ellipsis handling?
Especially, if PWD contains files with long non-ascii filename, then termscp immediately panics on startup.
Steps to reproduce
$ mkdir -p /tmp/termscp-test
$ cd /tmp/termscp-test
$ echo > 喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵
# With a narrow terminal
$ termscp
thread 'main' panicked at 'byte index 23 is not a char boundary; it is inside '喵' (bytes 21..24) of `喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵`', /root/.cargo/registry/src/mirrors.tuna.tsinghua.edu.cn-df7c3c540f42cdbd/termscp-0.8.1/src/explorer/formatter.rs:308:37
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
On second thought, encoded width in UTF-8 doesn't always correspond to a glyph's displayed width. If precise handling of Unicode is expected, additional crates may be needed (e.g. unicode_width).
Description
When displaying files with long non-ascii filenames (locally or remotely), termscp panics. Presumably this is due to incorrect line-wrap / ellipsis handling?
Especially, if PWD contains files with long non-ascii filename, then termscp immediately panics on startup.
Steps to reproduce
Expected behaviour
Should not panic when display any filename.
Environment
Log
(I tested in /root/tmp)
2022-03-29T16:32:05+0000 [INFO] Reading directory /root/tmp 2022-03-29T16:32:05+0000 [INFO] Stating file /root/tmp/喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵喵