Truncate the starts of file paths instead of the ends in picker

[Omnikar]

Fixes #945.

[pickfire]

I think we can do better than collecting iterating over this twice and having a separate allocation.

I think probably can just get the index and display the rest. Didn't look closely.

Good idea but I think for files it might be better to truncate the directories, like single character for each directory in path. How fish truncate the directory may be a better idea. But that would probably require separate allocation.

This is a good start and should be fine for now.

[Omnikar]

Since individual graphemes can have different widths, I'm not sure how to do this without iterating over it in reverse and checking the total width.

single character for each directory in path

Ah, that's a good idea.

[archseer]

You should be able to just calculate the total width using unicode_width::UnicodeWidthStr, no need to segment it into graphemes:

helix/helix-core/src/graphemes.rs

Line 30 in e505bf2

UnicodeWidthStr::width(g).max(1)

We re-export the library as helix_core::unicode::width

[archseer]

Ah yeah, it's the same method you're already using (.width()). Should be enough to call string.width(), then if it's larger than width we iterate graphemes from reverse, rendering them into content (without using the end vector)

[archseer]

I pushed a rewrite with ^ but it's untested. Probably needs more work.

[Omnikar]

And it panics when the paths are long enough to actually need to be truncated. Or rather, panics when compiling in debug mode, since it's a subtract overflow panic, which just rolls over in release mode.

[Omnikar]

Ah, addressing this fixes the panic.

[archseer]

Ah, I guess that codepath always gets called even if the string is shorter.

[archseer]

We'd preferably use the original code under !truncate_start if the width is shorter

[Omnikar]

I think I've figured out what to do.

[Omnikar]

Wait a minute, it stopped working before I pushed it? I tested it and it worked before I deleted let mut x_offset = max_offset; because it was no longer being used. But after I deleted it, it started subtract overflowing? I am very confused.

[Omnikar]

Ohhhh, it was because x_offset shadowed another x_offset variable… which means that the compiler was wrong in warning me that the new x_offset is unused? 🤔

[Omnikar]

Oh… it wasn't a compiler bug. x_offset is actually just never read.

[Omnikar]

OK, now it should work.