Re: Alignment bug in ls with UTF-8 filenames under Mac OS X

[Jim Meyering]

Bruno Haible <address@hidden> 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?