Bruno Haible <[EMAIL PROTECTED]> wrote: > Jim Meyering wrote: >> As I understand the goal, you'd like to make ls act differently >> (outputting spaces, not TABs, for column alignment) on all systems >> for each line containing a non-ASCII byte. > > Yes, this is what the proposed patch does. > >> That change would contradict the documentation of -T > > The --color option also has the effect of turning tabs into spaces; yet this > is undocumented. Actually the doc states > > `ls' uses tabs where possible in the output, for efficiency. If > COLS is zero, do not use tabs at all. > > and the phrase "where possible" is vague enough. It is not possible to use > tabs with --color, and it is not possible to use tabs after non-ASCII > characters.
Um... it *is* possible to use TABs after non-ASCII bytes and get correct alignment. The only requirement is that you be using a reasonable (non-buggy) terminal emulator. >> but more >> importantly, it would make the output significantly larger when there are >> wide columns and many lines containing a non-ASCII byte, thus penalizing >> all users in order to cater to a buggy terminal emulator. > > I thought with xterm, as with most terminal emulators, the network transmit > time is negligible compared to the rendering time on the X side. Besides > that, your argument trades correctness of display against efficiency. Not at all. I merely refuse to pessimize ls output for everyone, solely to accommodate some currently buggy version of Apple Terminal. >> I would rather simply have someone who cares about Apple Terminal >> report the bug, and in the mean time, advise people to use "-T0" >> (or set TABSIZE=0 in their environment) if they care about alignment >> when using a buggy version of that particular terminal emulator. Do you really think it would be better to make everyone pay (even a tiny bit) when there is such an easy work-around? _______________________________________________ Bug-coreutils mailing list Bug-coreutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-coreutils