Re: colorls in base

[Christos Zoulas <christos%zoulas.com@localhost>]

> On Feb 16, 2019, at 12:30 PM, Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost> wrote:
> 
> I remember you speaking up against replacing csh(1) with tcsh in base a few
> years ago. How about adding tcsh's complete facility to csh(1)? That is
> probably an order of magnitude in codesize compared to ls(1) vs.
> colo(u)rls, but I see a moral equivalent.

I mentioned back then a few reasons:
1. our csh uses stdio and does not require a custom printf etc.
2. tcsh has a built-in copy of libedit which has a complicated relationship with the shell.
3. the csh code is much cleaner and simpler.
4. tcsh has a lot of OS compatibility code that is mixed in with the code that's not needed for NetBSD

On the opposite side:
1. tcsh has many more features and the integrated editor and completion work very well together.
2. csh leaks memory on errors where the new tcsh unwind code handles memory allocation much better.


>> So will be having color in some programs in base. It will
>> be invisible unless you specifically turn it on.
> 
> I guess some of us see a slippery slope?

Yes, and this fear is causing unnecessary conservatism in this case.
You can fight changing the default later, and even claim "I told you".
Also who knows, if we build this feature well, maybe even some of
the people who oppose it will like it. BTW I personally don't currently
use any color in my screen because I am used to my way of working,
and I don't find it useful. This is a personal preference though, and I
can see that others might find it useful or even just like it.

> 
> Careful, that way lie bash and emacs, cups and ...

Yes, and sometimes we need to carefully think about the advantages and
disadvantages maintaining our own copies of everything. There are costs
and benefits either way. But those again might shift over time. For example,
in make(1) we don't have pattern rules and this has slowly eroded our ability
to use our make(1) in pkgsrc. Or autoconf using LINENO has forced that in
our shell, and autoconf again using m4 features our m4 did not support forced
us to add them.

> 
>> It is not 1980 anymore and
>> we don't need to be frugal about resources (specially when they can
>> be compiled out).
> 
> Well, we still support most of the architectures we supported in the
> mid-nineties (and even vax from the eighties). So it would be nice if base
> ran reasonably well on them.

Yes, and we still do run pretty well considering. We can't build in some of them
because of compiler bloat, but the efforts to support a leaner compiler have not
panned out. For the specific colorls example, we could consider turning the feature
off on slower/smaller archs, but I don't think this is necessary.

christos