Repository navigation
[BUG]: the width of multi-line cells is the sum of the width of all lines in a cell #101
Description
Hello,
As the title explains, in multi-line cells (where lines are separated by a '\n' character) the width of the cell seems to be calculated as if all lines were actually collapsed on a single long line. In contrast, I think one would expect the '\n' characters to be recognized as line breaks so that the cell width would be as large as the longest line in the cell.
Kind regards
EDIT: I stand corrected, the width of the cell is not exactly the sum of all lines, but there is a significant margin that tends to grow with the number of lines in the cell, though wasn't able to find an consistent relationship. It's worth mentioning that when manually editing the CSV within the extension, the issue is only visible after the file has been saved
Activity
Make multiline and manual column widths predictable (#87, #98, #101)
jonaraphael commentedon Oct 17, 2026
Your clarification about the width changing after saving was helpful—thank you for coming back to add it. #112 proposes sizing these cells around their longest line. I appreciate the careful report, and I’m sorry it’s taken a while to follow up.
jonaraphael commentedon Oct 18, 2026
@sideprojectslab, thank you for the careful report. CSV 1.4.2 now calculates multiline widths from the longest individual line. I’m sorry for the delay in addressing it. Please let me know if the update still produces surprising widths. If you have a spare moment, I’d also appreciate an honest review.