Hi,
llvm recently switched to using terminfo for detecting if terminals support
escape codes. There's some discussion about this after the commit happened
here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20130805/183590.html
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.
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:
https://github.com/git/git/blob/21ff9151e811059f5576ca906c519ee5bb5b925e/color.c#L183
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?
(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?)
Thanks,
Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20130908/2c5bbfc5/attachment.html>
On Sun, Sep 08, 2013 at 05:09:57PM -0700, Nico Weber wrote:> 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:Tools in the GNU/Linux environment have a long history of hard coding escape sequences. GNU ls is a good example. That doesn't mean it is the correct thing to do. So far, I haven't heard a valid (or even any argument at all) from you to change that. The Windows case is somewhat different due to the cruft of the Windows console API... Joerg
On 9 September 2013 01:09, Nico Weber <thakis at chromium.org> wrote:> I think depending on curses is gross, >I totally agree, but I also don't have a better way of doing this. I agree with Joerg that hard-coding escape sequences is not the way forward. Even though curses is available on pretty much every OS, there are hacks you have to do to port across OSs, especially old Unices. 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? >(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?) >If this is *just* for fancy make output, I'd say be gone with it. But Clang could also depend on it for fancy error reporting (does it?), which is a different matter. I don't really mind fancy output either way. cheers, --renato -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130909/63329248/attachment.html>
On Mon, Sep 9, 2013 at 12:24 AM, Renato Golin <renato.golin at linaro.org>wrote:> On 9 September 2013 01:09, Nico Weber <thakis at chromium.org> wrote: > >> I think depending on curses is gross, >> > > I totally agree, but I also don't have a better way of doing this. I agree > with Joerg that hard-coding escape sequences is not the way forward. >llvm is still hard-coding escape sequences (see Process::OutputBold() etc). As far as I understood, there wasn't a plan to change that. curses is only used to detect if the terminal supports escape codes. It sounds like nobody else minds llmv depending on additional libraries, so I'll drop this. Even though curses is available on pretty much every OS, there are hacks> you have to do to port across OSs, especially old Unices. >Given that things worked fine so far, I guess most people are not using old Unices.> 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? >> >I'd still like to do this part. Let me know if you object to it.> (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?) >> > > If this is *just* for fancy make output, I'd say be gone with it. But > Clang could also depend on it for fancy error reporting (does it?), >which is a different matter. I don't really mind fancy output either way.> > cheers, > --renato > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20130912/ae9166c3/attachment.html>