Re: [pacman-dev] [PATCH 1/3] makepkg: fallback to legacy termcap capabilities
Sent this to Andres, forwarding... ----- Forwarded message from Nezmer <git@nezmer.info> ----- Date: Thu, 14 Oct 2010 20:34:15 +0300 From: Nezmer <git@nezmer.info> To: Andres Perera <andres.p@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@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. 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. ----- End forwarded message -----
On Thu, Oct 14, 2010 at 1:09 PM, Nezmer <git@nezmer.info> wrote:
Sent this to Andres, forwarding...
----- Forwarded message from Nezmer <git@nezmer.info> -----
Date: Thu, 14 Oct 2010 20:34:15 +0300 From: Nezmer <git@nezmer.info> To: Andres Perera <andres.p@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@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;conten... 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.
On Thu, Oct 14, 2010 at 02:55:54PM -0430, Andres Perera wrote:
On Thu, Oct 14, 2010 at 1:09 PM, Nezmer <git@nezmer.info> wrote:
Sent this to Andres, forwarding...
----- Forwarded message from Nezmer <git@nezmer.info> -----
Date: Thu, 14 Oct 2010 20:34:15 +0300 From: Nezmer <git@nezmer.info> To: Andres Perera <andres.p@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@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;conten... 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?
On Thu, Oct 14, 2010 at 3:42 PM, Nezmer <git@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@nezmer.info> wrote:
Sent this to Andres, forwarding...
----- Forwarded message from Nezmer <git@nezmer.info> -----
Date: Thu, 14 Oct 2010 20:34:15 +0300 From: Nezmer <git@nezmer.info> To: Andres Perera <andres.p@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@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;conten... 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
On Thu, Oct 14, 2010 at 4:15 PM, Dan McGee <dpmcgee@gmail.com> wrote:
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.
Finally someone considers this route. There's a good reason ports in *bsd (and userspace in general, really) don't even try to use color. ncurses and termcap/info is a mess best dealt by someone else.
On Thu, Oct 14, 2010 at 4:15 PM, Dan McGee <dpmcgee@gmail.com> wrote:
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.
Finally someone considers this route. There's a good reason ports in *bsd (and userspace in general, really) don't even try to use color. ncurses and termcap/info is a mess best dealt by someone else.
On Thu, Oct 14, 2010 at 4:12 PM, Nezmer <git@nezmer.info> wrote:
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?
Well, yes. Chances are your terminal can output color with those escapes. So it is not beneficial if you happen to be part of the (large) majority of users that are you using modern terminals. You're right. But the code, by admission, would be taking a condition for granted. I don't think that's a good compromise, specially for the sake of eye candy.
participants (4)
-
Andres Perera
-
Andres Perera
-
Dan McGee
-
Nezmer