old/unupdated xterm entries in termcap db
Leonidas Tsampros
Recently, I tried to enable/configure 256 color support under xterm
(and/or other terminal emulators). The application for which I wanted
256 color support is emacs (although this does not matter). Normally,
all I'd have to do to get this done is:
export TERM=xterm-256color
Of course, this didn't work because the termcap file installed had the
following entry:
xterm-256color|xterm alias 3:tc=xterm-xfree86:
which points to xterm-xfree86, which in turn points to xterm-basic. This
last entry (if you look at the termcap file) has 8 colors defined. (I
think the parameter in question is 'Co' but I guess other parameters are
needed as well). The above stands true about xterm-16color and
xterm-88color too.
After searching a bit, I noticed that xterm entries in FreeBSD's termcap
file were copied directly from the termcap file that ships with xterm
(but most probably from a very old xterm version). So, I removed all the
related entries (lines 2932 to 3090) and I inserted at their place an
exact copy of the contents of the termcap that ships with xterm-251.
This seems to work correctly for me, and I managed to get 256 color
support. However, I have not done any extensive testing for the other
changed/updated entries that this change brought.
Attached you can find a patch for share/termcap/termcap.src.
Why aren't these entries updated in order to match the
ones that ship with xterm? Am I missing something?
Regards
Leonidas
Gary Jennejohn
Leonidas Tsampros <ltsa...@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...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"
Dag-Erling Smørgrav
> Leonidas Tsampros <ltsa...@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.
DES
--
Dag-Erling Smørgrav - d...@des.no
Gary Jennejohn
Dag-Erling Sm__rgrav <d...@des.no> wrote:
> Gary Jennejohn <gary.je...@freenet.de> writes:
> > Leonidas Tsampros <ltsa...@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.
---
Gary Jennejohn
Dag-Erling Smørgrav
> 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
Ed Schouten
* Alexander Leidinger <Alex...@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/
Ed Schouten
> 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
> 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.
The attached patch should bring the entries up-to-date. Unfortunately it
still seems the issue with Apple's Terminal.app is present, but that's
just Apple's fault. Because of that, I don't see a reason (yet) to MFC
this.
Any testers, before I commit this patch to HEAD?
Alexander Leidinger
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.je...@freenet.de> writes:
>> > Leonidas Tsampros <ltsa...@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.net Alexander @ Leidinger.net: PGP ID = B0063FE7
http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137
Gary Jennejohn
I tried it with a "real" xterm and mrxvt and see no regressions. However,
I didn't try it with a VT as xterm.
---
Gary Jennejohn
Ed Schouten
> Ed Schouten <e...@80386.nl> wrote:
> > Any testers, before I commit this patch to HEAD?
> >
>
> I tried it with a "real" xterm and mrxvt and see no regressions. However,
> I didn't try it with a VT as xterm.
I couldn't find any regressions either, so I just committed it to HEAD.
It turns out it did improve the situation for Terminal.app a little, so
I am going to MFC it after all.
Thanks for {testing,reporting,etc}!
Giorgos Keramidas
> Hello Alexander, others,
>
> * Alexander Leidinger <Alex...@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.