It should be possible to tell there are unsaved changes to the buffer, even with long file paths.

[nestor-custodio]

If the file path for the current buffer is longer than will fit on the allotted space in the status line, it is truncated to fit. This makes perfect sense. However, the " [+]" that indicates the current buffer has unsaved changes is also lost in this truncation, making it impossible to tell whether the buffer requires saving until you try to close it or fully quit out.

This is particularly problematic for users who tend to open new tmux windows/panes for editing and exit out by simply killing said window/pane, in which case you don't see there are unsaved changes and Helix doesn't get a chance to warn you about the unsaved buffer at all.

The status line string truncation should take into account whether a " [+]" (or any other status indicator) is present, and truncate the buffer name alone, allowing space for the indicator to still be shown on-screen.

What I'm seeing:

• no changes:
  NOR a_very_long_directory_name/some_other_directory/my_file_with_a_very_long_ 13:14 ruby
• with changes:
  NOR a_very_long_directory_name/some_other_directory/my_file_with_a_very_long_ 13:14 ruby

What I would expect:

• no changes:
  NOR a_very_long_directory_name/some_other_directory/my_file_with_a_very_long_ 13:14 ruby
• with changes:
  NOR a_very_long_directory_name/some_other_directory/my_file_with_a_very_l [+] 13:14 ruby

Additionally, it would be nice if truncation was indicated with a … as opposed to the buffer name simply terminating weirdly, though I realize that's more of a nitpick than the legitimate issue above.

---

helix: 22.08.1

(Wasn't quite sure if this should be reported as a bug or as an enhancement. Please do categorize accordingly if this should've been a bug report instead.)

[cbclemmer]

I want to try fixing this

[kirawi]

It might help to look at the code introduced by #2434.

[cbclemmer]

@kirawi After looking at the code it seems that the text isn't simply substringed to fit in the middle space but is put on a buffer and appended. When there isn't any more space on the line it just doesn't show. This is probably needed so that the editor can append as many elements on the line as needed without worrying about spacing. You can test this by adding multiple file name elements in the configuration and with a long enough file name it just doesn't show all of the elements. My suggestion to fix the original concern would be to either prepend the [+] portion to the file name instead of appending it so that it always appears or moving the [+] to its own element so that its location can be customized.

Some fun config options that works to illustrate my point better:

[editor.statusline]
left = ["mode", "spinner"]
center = ["file-name", "file-name","file-name","file-name","file-name"]
right = ["diagnostics", "selections", "position", "file-encoding", "file-type"]

[cbclemmer]

I added a PR #4731 that adds a new "file-dirty" element.
@nestor-custodio If this merges you can add the "file-dirty" element before the "file-name" element in the config file to have that always be visible. From what I can tell there isn't really a way to truncate the file name perfectly because other elements may expect to be displayed after the file name (see above comment).