[GH-ISSUE #92] Badly wrapped under terminal with short width #37

New Issue

2026-06-08T11:25:25+03:00

zhus commented

2026-06-08 11:25:25 +03:00

Originally created by @pickfire on GitHub (May 31, 2020).
Original GitHub issue: https://github.com/bootandy/dust/issues/92

It does not take $COLUMNS into account and stuff gets wrapped being hardly readable under terminal less than 100 width. I have no issue with dust shortening the file name if the terminal is short.

1005M   │ ┌─┴ iams-dev-environment

 3.1G   ├─┴ hlai

 616M   │ ┌── student

 994M   │ │ ┌── node_modules

 1.4G   │ ├─┴ apspace

 608M   │ │   ┌── objects

 691M   │ │ ┌─┴ .git

 2.1G   │ │ │   ┌── Components

 2.3G   │ │ │ ┌─┴ stage

 2.3G   │ │ ├─┴ database

 3.6G   │ ├─┴ attendix

 6.7G   ├─┴ apu

I think at the very least, it should support terminal with 80 widths with a fallback even if stuff does not display well, without the terminal wrapped stuff up, it will still look pretty neat.

Originally created by @pickfire on GitHub (May 31, 2020). Original GitHub issue: https://github.com/bootandy/dust/issues/92 It does not take `$COLUMNS` into account and stuff gets wrapped being hardly readable under terminal less than 100 width. I have no issue with `dust` shortening the file name if the terminal is short. ``` 1005M │ ┌─┴ iams-dev-environment 3.1G ├─┴ hlai 616M │ ┌── student 994M │ │ ┌── node_modules 1.4G │ ├─┴ apspace 608M │ │ ┌── objects 691M │ │ ┌─┴ .git 2.1G │ │ │ ┌── Components 2.3G │ │ │ ┌─┴ stage 2.3G │ │ ├─┴ database 3.6G │ ├─┴ attendix 6.7G ├─┴ apu ``` I think at the very least, it should support terminal with 80 widths with a fallback even if stuff does not display well, without the terminal wrapped stuff up, it will still look pretty neat.

zhus closed this issue

2026-06-08 11:25:25 +03:00

zhus commented

2026-06-08 11:25:25 +03:00

@bootandy commented on GitHub (May 31, 2020):

I'm relying on terminal size to tell me how wide the terminal is I don't know if that reads $COLUMNS variable
https://github.com/eminence/terminal-size

It should support terminals of 80 chars or more (I thought it already did, I may be wrong).

If the terminal is less than 80 characters wide it will still assume the terminal is 80 chars wide. I didn't consider a case where a terminal was less than 80 chars wide, but it should be easy to fix.

@bootandy commented on GitHub (May 31, 2020): I'm relying on terminal size to tell me how wide the terminal is I don't know if that reads $COLUMNS variable https://github.com/eminence/terminal-size It should support terminals of 80 chars or more (I thought it already did, I may be wrong). If the terminal is less than 80 characters wide it will still assume the terminal is 80 chars wide. I didn't consider a case where a terminal was less than 80 chars wide, but it should be easy to fix.

zhus commented

2026-06-08 11:25:25 +03:00

@pickfire commented on GitHub (Jun 1, 2020):

Maybe because some of the file names are too long (longer than the terminal), does dust handle those by truncating the file names?

@pickfire commented on GitHub (Jun 1, 2020): Maybe because some of the file names are too long (longer than the terminal), does dust handle those by truncating the file names?

zhus commented

2026-06-08 11:25:25 +03:00

@bootandy commented on GitHub (Jun 1, 2020):

No, that would confuse it, if the length of the filename + the size and ASCII graph is longer than the length of the terminal that would cause wrapping.
You can also see this if you use the '-p' flag to print entire directories.

I think the fix here would be to trim the file name.

I remembered why I enforced a minimum width of 80 - its because the test runners have a default width less than 80 and it confused the tests.

@bootandy commented on GitHub (Jun 1, 2020): No, that would confuse it, if the length of the filename + the size and ASCII graph is longer than the length of the terminal that would cause wrapping. You can also see this if you use the '-p' flag to print entire directories. I think the fix here would be to trim the file name. I remembered why I enforced a minimum width of 80 - its because the test runners have a default width less than 80 and it confused the tests.

zhus commented

2026-06-08 11:25:25 +03:00

@pickfire commented on GitHub (Jun 1, 2020):

Yes, I mean trim the file name. At that moment I have some file names more than 80 widths while my terminal have just around 90 widths.

But yes, if anyone would to work on this, I would suggest testing against double width characters such as CJK characters (e.g. 《芒种》音阙诗听-赵方婧官方高画质 Official HD MV丨Grain in Ear丨Mang Chủng.mp4) if it cut halfway through the characters or have it counted wrongly, it which had a regression fixed last time I checked.

@pickfire commented on GitHub (Jun 1, 2020): Yes, I mean trim the file name. At that moment I have some file names more than 80 widths while my terminal have just around 90 widths. But yes, if anyone would to work on this, I would suggest testing against double width characters such as CJK characters (e.g. `《芒种》音阙诗听-赵方婧官方高画质 Official HD MV丨Grain in Ear丨Mang Chủng.mp4`) if it cut halfway through the characters or have it counted wrongly, it which had a regression fixed last time I checked.

zhus commented

2026-06-08 11:25:25 +03:00

@bootandy commented on GitHub (Jun 2, 2020):

I have tests to check the display length for asian characters, but I can't read them and can't test them easily.

I'll look at trimming the file names.

@bootandy commented on GitHub (Jun 2, 2020): I have tests to check the display length for asian characters, but I can't read them and can't test them easily. I'll look at trimming the file names.

zhus commented

2026-06-08 11:25:25 +03:00

@pickfire commented on GitHub (Jun 2, 2020):

I can help you to check. I can also teach you, if you have the fonts installed, you should be able to see some square items below.

音阙诗听
音阙诗听
音阙诗听
音阙诗听

It is a 4x4 characters block (for illustration), you could copy and paste those as long length, as long as you see them in that shape means they are okay, if you see some other weird unreadable characters means it is off.

Here is a simpler one which contains 4 characters in chinese: one, two, three and four.

一二三四

Just make them long enough on your terminal. As long as you see the same character means it is safe.

Just in case, spaces are rarely seen in chinese, even rarer in japanese, not sure about korean. But sometimes there may be space in between. But still, space is not valid in chinese writings as what I am taught, same goes for a few non CJK language such as thailand but their writings are quite different from us with curves rather than strokes.

@pickfire commented on GitHub (Jun 2, 2020): I can help you to check. I can also teach you, if you have the fonts installed, you should be able to see some square items below. ``` 音阙诗听音阙诗听音阙诗听音阙诗听 ``` It is a 4x4 characters block (for illustration), you could copy and paste those as long length, as long as you see them in that shape means they are okay, if you see some other weird unreadable characters means it is off. Here is a simpler one which contains 4 characters in chinese: one, two, three and four. ``` 一二三四 ``` Just make them long enough on your terminal. As long as you see the same character means it is safe. Just in case, spaces are rarely seen in chinese, even rarer in japanese, not sure about korean. But sometimes there may be space in between. But still, space is not valid in chinese writings as what I am taught, same goes for a few non CJK language such as thailand but their writings are quite different from us with curves rather than strokes.

zhus commented

2026-06-08 11:25:25 +03:00

@bootandy commented on GitHub (Jun 2, 2020):

This issue is compounded by this one:

https://github.com/bootandy/dust/issues/89

Currently all 'short' entries will have spaces added to them so they are the same length as the 'long' entry.

With the fix for the above applied the spaces will not be added and this issue should be less of a problem.

@bootandy commented on GitHub (Jun 2, 2020): This issue is compounded by this one: https://github.com/bootandy/dust/issues/89 Currently all 'short' entries will have spaces added to them so they are the same length as the 'long' entry. With the fix for the above applied the spaces will not be added and this issue should be less of a problem.

zhus commented

2026-06-08 11:25:25 +03:00

@bootandy commented on GitHub (Jun 2, 2020):

Thanks for the characters. I have tried creating a file with the name: 音阙诗听 and it is displayed correctly in the dust tree so I think that should be fine.

@bootandy commented on GitHub (Jun 2, 2020): Thanks for the characters. I have tried creating a file with the name: 音阙诗听 and it is displayed correctly in the dust tree so I think that should be fine.

zhus commented

2026-06-08 11:25:25 +03:00

@pickfire commented on GitHub (Jun 3, 2020):

I think you got my idea wrongly, it displays correctly when it is short, right now it also displayed correctly when it was long.

But if the filename have a bunch of those like 音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听.mp4 and your terminal is not long enough (wrapped by terminal), it looks bad. So I think the solution to it is to truncate the filename, by that I think it would be easily to mistakenly truncate to the wrong position, that is the reason I gave the example, for truncation. Right now it works perfectly when the terminal is long enough to display them.

Yes, we should truncate latin characters too if they were too long. I just mentioned the chinese characters case as an edge case, which most likely would be wrongly truncated unlike the english characters.

@pickfire commented on GitHub (Jun 3, 2020): I think you got my idea wrongly, it displays correctly when it is short, right now it also displayed correctly when it was long. But if the filename have a bunch of those like `音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听音阙诗听.mp4` and your terminal is not long enough (wrapped by terminal), it looks bad. So I think the solution to it is to truncate the filename, by that I think it would be easily to mistakenly truncate to the wrong position, that is the reason I gave the example, for truncation. Right now it works perfectly when the terminal is long enough to display them. Yes, we should truncate latin characters too if they were too long. I just mentioned the chinese characters case as an edge case, which most likely would be wrongly truncated unlike the english characters.

zhus commented

2026-06-08 11:25:25 +03:00

@bootandy commented on GitHub (Aug 2, 2020):

I think I understand now.

If the file names are too long they wrap and it looks bad. The solution would be to truncate filenames.

Either latin or chinese characters.

I can reproduce this with a very long filename locally.

I'll look at fixing it.

@bootandy commented on GitHub (Aug 2, 2020): I think I understand now. If the file names are too long they wrap and it looks bad. The solution would be to truncate filenames. Either latin or chinese characters. I can reproduce this with a very long filename locally. I'll look at fixing it.

zhus commented

2026-06-08 11:25:25 +03:00

@bootandy commented on GitHub (Aug 19, 2020):

Fixed with above commit.

@bootandy commented on GitHub (Aug 19, 2020): Fixed with above commit.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: bootandy/archived-dust#37