Autocompletion don't take character width into account when wrapping long paths

[JonathanxD]

Describe the bug

I found this problem while trying to complete some commands while on my home folder, and by whatever reason Nushell kept adding a new line before every option as shown in the screenshot below

The reason was a character that doesn't have the same width as a regular ASCII character, so even though it does fit in the terminal, Nushell thinks it doesn't:

It seems that Nushell relies on the number of bytes instead of the character width, and this causes this kind of problem. The worse thing is that whenever I press TAB to cycle between the options, the terminal duplicates its "prompt", as shown in the screenshot below:

I also recorded a clip to show this in practice:

https://user-images.githubusercontent.com/5360060/232176827-cc683bc1-55be-43bf-82ff-aed9935c5fbc.mp4

Note: while I was writing this bug report, I was able to make nushell just duplicate the previous buffer text after every tab press:

https://user-images.githubusercontent.com/5360060/232177343-876ce903-5e36-44bd-8e19-ba78d6db05c2.mp4

Note2: The new line pollution is even worse if the terminal is very thin:

And even though it seems that Nushell is the one wrapping the text, it's not, actually it's filling every path output with empty spaces after the name, and the Terminal Emulator (kitty in this case) is wrapping those blank spaces.

Yes, no one should be using a terminal with that dimension, but this is a good way to figure out the pattern of the behavior.

How to reproduce

For the wrong wrapping of variable width characters:

1. Create some files with 2, 3 or 4-byte wide characters (4-byte wide is easier) that are visually less wide than regular ASCII characters (half-width characters for example). 1.1. The total number of bytes in the file name must be greater than the terminal columns number/width (term size) at the same time it must not fill the entire line. 1.2. You can resize the terminal emulator to reproduce it easily (with less characters as well).
2. Try to autocomplete the path, it will wrap regardless of the path not filling the entire terminal line and will also pollute the output visually with line breaks (fish handles this using ... instead of wrapping to the next line).

For the "output" duplication:

1. Create some files (at least one with a long name that doesn't fit the terminal)
2. Press enter until the terminal scrolls
3. Try to autocomplete a path, it will duplicate the output right above (if you do exactly the same way I did, it will even duplicate the previous autocompletion output)

Expected behavior

It should only wrap if the path does not fill the entire line. I've tested textwrap with those scenarios and it seems to handle all of them correctly (wrapping only when they don't visually fit the terminal). For the new line pollution, I think it should not be filling the path with blank space if it's going to wrap anyway.

As for the duplication, it should just not happen, I didn't figured out why it's doing that.

Screenshots

I've attached to the bug description, so they are all within context.

Configuration

key	value
version	0.78.0
branch
commit_hash
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.70.0-nightly (696aaad58 2023-04-09)
rust_channel	nightly-x86_64-unknown-linux-gnu
cargo_version	cargo 1.70.0-nightly (0e474cfd7 2023-03-31)
build_time	2023-04-11 10:27:56 -03:00
build_rust_channel	release
features	default, zip
installed_plugins	from parquet, hist, periodic-table, plot, regex, xyplot

I've also the build distributed in Arch Linux Official repos, it does have the exact same problem:

key	value
version	0.78.0
branch	makepkg
commit_hash	2ec20286371f1d90a77fdd5d82818c6c5851f090
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.68.2 (9eb3afe9e 2023-03-27) (Arch Linux rust 1:1.68.2-1)
cargo_version	cargo 1.68.2
build_time	2023-04-05 02:09:35 +00:00
build_rust_channel	release
features	default, zip
installed_plugins	from parquet, hist, periodic-table, plot, regex, xyplot

Additional context

No response