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

Open
#572 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Stale
Tech stack
rust
Domain
cli

Research direction

No source file or test is identified in the report. Start by reproducing the path-completion case in reedline with variable-width characters and a narrow terminal, then trace the autocomplete rendering and terminal-size calculations. Done means paths wrap according to their visual width without blank-space pollution or duplicated completion output.

Written by the indexing model from the issue text.

Description

A-Display bug
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

image

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:

image

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:

image

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:

image

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.

image

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

Dominant language
Rust
Stars
818
Forks
249
Avg merge
4d 14h
Merged PRs (30d)
30

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from nushell/reedline

All issues in nushell/reedline

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.