mirror of
https://github.com/bootandy/dust.git
synced 2026-06-08 11:29:05 +03:00
[GH-ISSUE #270] Play nicer with Screen Readers #117
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @trypsynth on GitHub (Oct 20, 2022).
Original GitHub issue: https://github.com/bootandy/dust/issues/270
Hi,
I'm a screen reader user, and when running this tool, a lot of unicode symbols trip up my screen reader. Take this line:
291G ├─┴ Dropbox │ ████████████████████████████████████ │ 67%
Results in me hearing:
291G plus? Dropbox symbol
symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol symbol │ 67%
Is there a reason these particular characters are used? If there is, could a flag for screen readers be added?
Thanks!
@bootandy commented on GitHub (Oct 22, 2022):
You could try 'dust -b' which will not print the unicode symbols after 'Dropbox' in your example, however it will remove the 67% too.
The unicode symbols are there to provide a visual description of the directory. If you are a screen reader user they won't be much use.
I'll leave this open as I can add a flag to make it better for screen readers users. For instance there's no reason it can't say:
291G 67% Dropbox
@bootandy commented on GitHub (Jan 27, 2023):
@TheQuinbox Is this a sensible sample output for a screen-reader mode?
Does it make sense?
Do you think it is upside down ?
$ dust -R tests/test_dir
12K 100% 0 test_dir
8.0K 67% 1 many
4.0K 33% 2 hello_file
0B 0% 2 a_file
@trypsynth commented on GitHub (Jan 27, 2023):
Hey there, and thanks for your work on this!
I'd say it's upside down, yes. I use a terminal screen reader called TDSR, and when I run this command, I want to be able to M-u and m-o (m = meta key) through the output. The way you have it currently certainly works, but it's more efficient to have it the other way around. We can't skim lines, so it would turn "find test/ and see how big it is", into "Okay, this takes up 12 KB, okay that's 100 percent, ah that's test." I like the order actually, aside from the name (that should go first I think).
Thanks!
@bootandy commented on GitHub (Jan 27, 2023):
Hey @TheQuinbox
Can you tell me which of these 2 options is better for you? The first shows the full path, the second doesn't. Also the second column what is meant to be 'path depth' - is that useful or would you rather it was not there? I imagine it's useful if you like option2 but not for option1.
$ target/debug/dust -Rp tests/test_dir
tests/test_dir/many/a_file 2 0B 0%
tests/test_dir/many/hello_file 2 4.0K 33%
tests/test_dir/many 1 8.0K 67%
tests/test_dir 0 12K 100%
$ target/debug/dust -R tests/test_dir
a_file 2 0B 0%
hello_file 2 4.0K 33%
many 1 8.0K 67%
test_dir 0 12K 100%
@trypsynth commented on GitHub (Jan 28, 2023):
I'd have to go with the second one, although I see advantages to the first. The second would allow for quicker skimming with linear speech, so I'd say that.
@bootandy commented on GitHub (Jan 29, 2023):
Added in version 0.8.4:
dust -R
(dust -Rp for full paths)