Summary: | eterm-0.9.3-r4 + screen-4.0.2-r4 + curses app rendering issues | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Horst Schirmeier <gentoo> |
Component: | Current packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED TEST-REQUEST | ||
Severity: | normal | CC: | amynka, dickey, mgorny, swegener |
Priority: | High | ||
Version: | 2006.0 | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
screenshot before detaching
screenshot after reattaching emerge info |
Description
Horst Schirmeier
2006-03-03 16:40:07 UTC
Created attachment 81247 [details]
screenshot before detaching
Created attachment 81248 [details]
screenshot after reattaching
Created attachment 81249 [details]
emerge info
I doubt this is relevant in this case, but I'll add this just for the records.
Another note: The TERM=xterm workaround has additional side effects for curses applications within screen; for example, the END key doesn't jump to the line end in vim anymore. Any suggestions how to resolve that? For the title update, Eterm needs to advertise hardstatus support in its terminfo file, else screen won't update it. We can tell screen that Eterm has support for hardstatus without changing the terminfo file via our global screenrc. I'm currently looking at the display weirdness with Eterm and screen. i dont really know much (of anything) about the lower terminal settings ... can you be more specific about what needs to happen to the Eterm file ? i can get this fixed upstream pretty easily ... hs, tsl=\E]0;, fsl=\007, dsl=\E]0;\007 this are the needed terminfo settings for hardstatus support hs = has extra status line tsl = move to status line, column #1 fsl = return from status line dsl = disable status line xterm doesn't advertise the capabilities too, we override them in our system screenrc. It seems that terminal developers don't consider the X window title equivalent to a hardstatus line. And the display weirdness comes from how screen and Eterm interact while switching to alternate character set. termcapinfo Eterm ae=\E(B:as=\E(0 in screenrc will emulate for Eterm how xterm does it. gnome-terminal uses the same way as Eterm and doesn't suffer from this problem. Eterm also behaves different when used in the POSIX and de_DE.UTF-8 locale. eterm doesnt support unicode so dont try ;) Thomas: any idea on getting changes made to ncurses now that Eterm terminfo is in there ? I don't recall noticing this bug - it's possible to accommodate screen in a couple of different ways (maing a screen.Eterm, or just modifying Eterm). any suggestions on the "correct" way to go about things ? i can bug the Eterm maintainer if you think that the better route ... well - just looking at the thread, there are two different types of terminal capabilities mentioned. The status line stuff is partly bogus, because (like anything else that uses xterm title strings), it doesn't provide a correct "tsl" capability (because there's no parameter for the column). I like to stay away from those, since there's little value-added. The other is the alternate-character switching stuff. This has to be limited to make "screen" work, since screen uses a subset of the _termcap_ interpretation of the capability. Adding a screen.Eterm entry is a way to do this (see ncurses' terminfo.src). But a pitfall here is that when screen is asked to do this, it diverges slightly from its interpretation of the "termcap", so it's often necessary to add other capabilities to make the entry work correctly. You can see a handful of examples in ncurses where I've done this. See ftp://invisible-island.net/ncurses/terminfo.src.gz I added a "screen.Eterm" entry to ncurses' terminfo in last night's (20090110) patch. Is this fixed? Thank you It would be fixed if Eterm sets its TERM variable to Eterm. You can verify that. |