<div dir="ltr">Hi,<br><br>llvm recently switched to using terminfo for detecting if terminals support escape codes. There's some discussion about this after the commit happened here:<br><br><a href="http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130805/183590.html">http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130805/183590.html</a><br>
<br>After the discussion, it looks like the approach was switched from depending on curses on just terminfo. From what I gather (the changelog didn't say), the motivation for this is that depending on curses is better than printing escape codes in terminals that don't support them.<br>
<br>I think depending on curses is gross, and there haven't been many complaints about clang printing escape codes during the years it has existed so far. Other projectsget by with isatty() && !strcmp(getenv("TERM"), "dumb") too, for example git:<br>
<br><a href="https://github.com/git/git/blob/21ff9151e811059f5576ca906c519ee5bb5b925e/color.c#L183">https://github.com/git/git/blob/21ff9151e811059f5576ca906c519ee5bb5b925e/color.c#L183</a><br><br><br>If folks think that bringing in the decades of cruft in curses is a good idea, I'd ask that the --enable-curses=no --enable-terminfo=no path at least keeps the old logic. Are there any objections to that? <br>
<br>(And since there are probably fewer shells on OS X, would anyone mind if --enable-curses=no --enable-terminfo=no was the default on OS X? And since even git can get away with it, maybe on Linux too?)<br><br>Thanks,<br>
Nico<br></div>