[pacman-dev] [PATCH 1/3] makepkg: fallback to legacy termcap capabilities

[Dan McGee]

On Thu, Oct 14, 2010 at 3:42 PM, Nezmer <git at nezmer.info> wrote:
> On Thu, Oct 14, 2010 at 02:55:54PM -0430, Andres Perera wrote:
>> On Thu, Oct 14, 2010 at 1:09 PM, Nezmer <git at nezmer.info> wrote:
>> > Sent this to Andres, forwarding...
>> >
>> > ----- Forwarded message from Nezmer <git at nezmer.info> -----
>> >
>> > Date: Thu, 14 Oct 2010 20:34:15 +0300
>> > From: Nezmer <git at nezmer.info>
>> > To: Andres Perera <andres.p at zoho.com>
>> > Subject: Re: [pacman-dev] [PATCH 1/3] makepkg: fallback to legacy termcap
>> >        capabilities
>> > User-Agent: Mutt/1.5.20 (2009-06-14)
>> >
>> > On Thu, Oct 14, 2010 at 12:47:02PM -0430, Andres Perera wrote:
>> >> On Thu, Oct 14, 2010 at 12:41 PM, Nezmer <git at nezmer.info> wrote:
>> >> > If you're running FreeBSD. The default $TERM in ttyv<int> is cons25(1) and
>> >> > it can handle the colours just fine. So I don't know how the hard-coded
>> >> > list is relevant.
>> >> >
>> >> > (1) I heard this vintage default will change soon.
>> >>
>> >> There's really no stopping at that point; the default terminal in OpenBSD is
>> >> "vt220" and it can handle colors, so can Linux's "linux" terminal.
>> >>
>> >> So it's screwing some terminals up vs. replicating ncurses in Bash -- since
>> >> that's exactly what ncurses does, it looks at the TERM string and compares it
>> >> to a list. Once this "vintage" changes, I guess makepkg is supposed to be
>> >> updated, if the second option is any good.
>> >>
>> >> Are you proposing that it should check for all these terminals or just grant
>> >> these bonuses to those who link against terminfo?
>> >
>> > First of all, Don't assume I know what I'm talking about. If I say
>> > something stupid, please correct me.
>>
>> I'm not following.
>>
>> >
>> > Currently, makepkg with colours work just fine in FreeBSD's default
>> > cons25 term. The patch will assume cons25 can't handle colours and will
>> > disable them, right?
>> >
>> > So, from a user prospective. This does not improve the experience in
>> > FreeBSD.
>> >
>> > Feel free to shout at my stupidity.
>> >
>> > * PS: xterm is the new default in 9-CURRENT. Hopefully It will make it
>> > to STABLE soon If It didn't already.
>>
>> I think you're somewhat misled by the fact that freebsd was named in the commit
>> message.
>>
>> The reason I'm only replicating terms found in tmux's [1] and tcshrc's
>> [2] lists is because considering only X-based terminals narrows down the
>> list to a point where it's manageable.
>>
>> Yes, we both know that it doesn't check for cons25. What I'm getting at
>> is, would you or anybody be willing to maintain a list that includes it,
>> in addition to vt220, linux, whatever OS xyz uses? I'm not implying
>> that's bad or stupid, I just personally have no interest in doing that.
>>
>> If this is not a common ground then I guess you suggest that assuming is
>> a ok?
>>
>> 1: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/tmux/tty.c?rev=1.91;content-type=text%2Fplain
>> 2: http://tcshrc.cvs.sourceforge.net/viewvc/tcshrc/tcshrc/src/tcshrc.set?revision=1.9&view=markup
>>
>> If you check out both examples, the first thing that comes to mind is
>> that they're not querying for the purpose of using color escapes. But hc
>> (has_status) is present in a great deal of termcap entries, and the sole
>> reason it's not being checked through an ncurses function is because
>> modern terminal emulators don't bother advertising has_status.
>>
>> This relates because setaf isn't accesible through termcap.
>
> Let me ask a simple question:
> Is there a real-life example where this patch would be beneficial to me
> as user?
>
> Is there someone who would like to run the next version of pacman on
> a 10 or 15 year old term definition?
>
> cons25 is probably the worst $TERM that is actually used nowadays and
> It can handle colour escapes.
>
> I remember an Arch developer missing makepkg colours in his chroots with
> the latest pacman release. Failing back to colour escapes fixed that
> too.
>
> Is there a $TERM that can't handle colour escapes and It is actually
> used?

And in any case at all, do people actually *need* color? I'm thinking
not and that patching some of this stuff might just be adding
complexity for very little benefit.

-Dan