Re: old/unupdated xterm entries in termcap db
Hello Alexander, others, * Alexander Leidinger alexan...@leidinger.net wrote: The practical attitude should be coordinated with ed@ (CCed), as he switched the console in 9-current to be an xterm, and AFAIR it does not support as much colors as the real xterm. Maybe there is a reason to not update it. So the idea is to make TERM=xterm use 256 colors? Even though I think having more colors would be awesome, I think many things would break. For example: - As Alexander mentioned, our console driver doesn't support more than 16 (well, 8 on the background) colors. Fortunately our implementation in HEAD smashes down the 256 colors back to 8, so it shouldn't cause any serious artifacts. Just a slight inconvenience. - I know Apple's Terminal.app for example doesn't support 256 colors and badly misinterprets the escape sequences, causing portions of the screen to blink (because the sequence to switch to one of the extended colors contains a 5, which is blink). But if someone is interested in updating the entries in the termcap file to something newer (but no 256 colors), please do! Patches welcome! I will even MFC it! Our current entry for xterm isn't entirely compatible with Apple's Terminal.app either. I've noticed that an Erase Line (EL, ^[[K) with xterm uses the terminal's selected attributes to blank the terminal, while Apple's implementation uses the default terminal attributes (i.e. black background). -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpj6FdeBfU5Y.pgp Description: PGP signature
Re: old/unupdated xterm entries in termcap db
On Thu, 10 Dec 2009 13:42:22 +0100 Ed Schouten e...@80386.nl wrote: But if someone is interested in updating the entries in the termcap file to something newer (but no 256 colors), please do! Patches welcome! I will even MFC it! Our current entry for xterm isn't entirely compatible with Apple's Terminal.app either. I've noticed that an Erase Line (EL, ^[[K) with xterm uses the terminal's selected attributes to blank the terminal, while Apple's implementation uses the default terminal attributes (i.e. black background). IIRC there was a patch in the original post which may be a good starting point. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: old/unupdated xterm entries in termcap db
* Gary Jennejohn gary.jennej...@freenet.de wrote: IIRC there was a patch in the original post which may be a good starting point. I just tried the patch, but when I run `make' in share/termcap, I get the following: | gzip -cn termcap.5 termcap.5.gz | TERM=dumb TERMCAP=dumb: ex - /store/home/ed/projects/freebsd-head/share/termcap/termcap.src /store/home/ed/projects/freebsd-head/share/termcap/reorder | script, 36: Pattern not found | script, 36: Ex command failed: pending commands discarded | *** Error code 1 | | Stop in /store/home/ed/projects/freebsd-head/share/termcap. -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgp2KFkHlrhPx.pgp Description: PGP signature
Re: old/unupdated xterm entries in termcap db
Quoting Gary Jennejohn gary.jennej...@freenet.de (from Wed, 9 Dec 2009 12:32:46 +0100): On Wed, 09 Dec 2009 12:29:21 +0100 Dag-Erling Sm__rgrav d...@des.no wrote: Gary Jennejohn gary.jennej...@freenet.de writes: Leonidas Tsampros ltsamp...@upnet.gr writes: Why aren't these entries updated in order to match the ones that ship with xterm? Am I missing something? Probably because xterm is under ports and termcap under src and it would not be easy to track changes in ports under src. The only practical way to keep termcap up to date would be for the committer updating the port to also check and update termcap under src. The problem with this is that most ports committers aren't authorized to make commits under src. That's not an issue - termcaps don't change all that often. We should just import the new definitions. That's a practical attitude, but it begs the question why it hasn't happened in the past. The practical attitude should be coordinated with ed@ (CCed), as he switched the console in 9-current to be an xterm, and AFAIR it does not support as much colors as the real xterm. Maybe there is a reason to not update it. Bye, Alexander. -- You can't depend on the man who made the mess to clean it up. -- Richard Nixon, 1952 http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: old/unupdated xterm entries in termcap db
On Thu, 10 Dec 2009 13:42:22 +0100, Ed Schouten e...@80386.nl wrote: Hello Alexander, others, * Alexander Leidinger alexan...@leidinger.net wrote: The practical attitude should be coordinated with ed@ (CCed), as he switched the console in 9-current to be an xterm, and AFAIR it does not support as much colors as the real xterm. Maybe there is a reason to not update it. So the idea is to make TERM=xterm use 256 colors? Even though I think having more colors would be awesome, I think many things would break. How about an xterm entry with 8 fg and 8 bg colors and a separate xterm-256color entry with 256 colors? I know, from our personal chat sessions, that the original drive behind Leonidas' patch to termcap was to make it possible for Emacs and vim to highlight/format code with more than 8 colors. This *is* useful for X11-based xterm windows but it may be less useful for vty terminals. pgpUoViQjf9bX.pgp Description: PGP signature
Re: old/unupdated xterm entries in termcap db
On Wed, 09 Dec 2009 01:12:04 +0200 Leonidas Tsampros ltsamp...@upnet.gr wrote: Why aren't these entries updated in order to match the ones that ship with xterm? Am I missing something? Probably because xterm is under ports and termcap under src and it would not be easy to track changes in ports under src. The only practical way to keep termcap up to date would be for the committer updating the port to also check and update termcap under src. The problem with this is that most ports committers aren't authorized to make commits under src. --- Gary Jennejohn ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: old/unupdated xterm entries in termcap db
Gary Jennejohn gary.jennej...@freenet.de writes: Dag-Erling Smørgrav d...@des.no writes: That's not an issue - termcaps don't change all that often. We should just import the new definitions. That's a practical attitude, but it begs the question why it hasn't happened in the past. Because what was there worked well enough for most people... DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
