<div dir="ltr">Hey Chandler,<div><br></div><div>Apologies if I've come across strong (it was late when I wrote my last reply), but I don't understand why you feel it necessary to remove the old code as a fallback codepath in the case where curses is not compiled in.</div>
<div><br></div><div>I come from the perspective that there needs to be a really good reason for adding an extra mandatory dependency. If it's an optional dependency, i.e. "things work better if you have this", I don't have a problem at all. With this patch you're ripping out core functionality unless this extra dependency is around (and also, while everyone has curses.so not every builder has libncurses-dev installed for the headers...). I just don't see why this is necessary. But I'm repeating myself.</div>
<div><br></div><div><span style="font-family:arial,sans-serif;font-size:13px">> The old algorithm wasn't flaky and didn't have "a" false positive. It assumed that all terminals except for one supported colors. This is pretty obviously false to me, and we have users that are specifically complaining about that assumption so I assume it is false in practice.</span><br>
</div><div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">It doesn't seem that bad of a heuristic to me, and if it's a problem then just compile against curses.</span></div>
<div><span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div><span style="font-family:arial,sans-serif;font-size:13px">To repeat: I'm not objecting to the part of your patch that queries curses to check for color support. Not at all. I'm just objecting to the removal of the old algorithm if curses isn't available.</span></div>
<div><br></div><div><font face="arial, sans-serif">James</font></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 8 August 2013 01:01, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>You seem to feel very strongly about this, and I'd like to understand the context in addition to the specifics of our argument. Is this a problem in practice for you or anyone else you know of? Do you have a concrete example where Clang now does the wrong thing on a particular system?</div>
<div class="im">

<div><br></div>On Wed, Aug 7, 2013 at 2:42 PM, James Molloy <span dir="ltr"><<a href="mailto:james@jamesmolloy.co.uk" target="_blank">james@jamesmolloy.co.uk</a>></span> wrote:<br></div><div class="gmail_extra">

<div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">The difference between zlib and curses is that the dependency on zlib was added to support a *new feature*. Without it, you don't get the new feature. Fair enough.</div>


</blockquote><div><br></div></div><div>This may be a new feature to Clang, but it was not really new. This was absolutely necessary for compatibility with GCC and other things.</div><div class="im"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<div dir="ltr"><div>I think it's unreasonable to gate an already existing feature of the user interface on a new dependency when there's no clear reason. OK, the old algorithm was flaky and had a false positive. So if I, a user or packager, care about that I can just now link against libcurses. Sorted.<br>


</div>
<div><br></div><div>So why remove the old fallback algorithm when those who care about the false positive have a clear and obvious new workaround?</div></div></blockquote><div><br></div></div><div>The old algorithm wasn't flaky and didn't have "a" false positive. It assumed that all terminals except for one supported colors. This is pretty obviously false to me, and we have users that are specifically complaining about that assumption so I assume it is false in practice.</div>

<div><br></div><div>I don't have any objection to adding fallback special cases for terminals we know do or don't support colors. (Hence my question about practical cases that we should handle here) I do have an objection to assuming colors in the absence of any evidence to indicate that assumption is safe. That objection is based on the fact that showing colors when they are not valid causes significantly more harm to the user experience than failing to show colors when they are valid.</div>

</div></div></div>
</blockquote></div><br></div>