search

adamdruppe / arsd

This is a collection of modules that I've released over the years. Most of them stand alone, or have just one or two dependencies in here, so you don't have to download this whole repo.
http://arsd-official.dpldocs.info/arsd.html
531 stars 128 forks source link

terminal.d support for TERM=screen.* #231

Closed quickfur closed 4 years ago

quickfur commented 4 years ago

I use GNU screen a lot, and I've been finding that terminal.d doesn't interact well with it, because it sets TERM to something like screen.xterm-256color or something similar, which terminal.d doesn't recognize. So for my terminal.d apps to work properly I have to manually set TERM before running the program, which works, but is an annoyance.

I'm wondering if terminal.d could possibly detect a TERM setting that starts with screen. and treats it as though it was the same as whatever string follows the screen. prefix? Like screen.xterm-256color would be treated as if it were xterm-256color. Would be really nice.

adamdruppe commented 4 years ago

yeah, that should be a fairly easy code change.

Though it is possible you are actually hitting a hacky workaround for the broken Mac OSX terminal in older versions.

Also possible the built-in termcap doesn't have an entry for that, and adding one may be easy. Maybe just put screen in there along with xterm.

What specific problem are you finding?

On Wed, Nov 27, 2019 at 10:34:37AM -0800, H. S. Teoh wrote:

I use GNU screen a lot, and I've been finding that terminal.d doesn't interact well with it, because it sets TERM to something like screen.xterm-256color or something similar. So for my terminal.d apps to work properly I have to manually set TERM before running the program, which works, but is an annoyance.

I'm wondering if terminal.d could possibly detect a TERM setting that starts with screen. and treats it as though it was the same as whatever string follows the screen. prefix? Like screen.xterm-256color would be treated as if it were xterm-256color. Would be really nice.

-- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/adamdruppe/arsd/issues/231

quickfur commented 4 years ago

The specific problem is that terminal.d apparently doesn't recognize the TERM string, and reverts to whatever default it has, with the end result that .clear and .moveTo have no effect, and all output just appears as a blob of characters at the bottom of the terminal.

My specific TERM string is screen.xterm-256color.

(There may be some issues here outside the scope of terminal.d, since my actual terminal is rxvt-unicode, but this is over an SSH connection so somewhere along the line something must have gotten munged. TERM strings are nice when they work, but when they don't you get inscrutable discrepancies of this sort along with their associated problems.)

But in any case, manually forcing TERM to xterm-256color or rxvt-256color or even just xterm is enough to make terminal.d work properly. So it would appear that things ought to Just Work(tm) if terminal.d would just treat screen.xterm-256color as if it were xterm-256color, or even just xterm at worst.

adamdruppe commented 4 years ago

yeah those functions depend on the termcap thing. I just pushed something to ~master, can you test that? you can see in the commit diff it is a pretty trivial little hack so if my gut is lucky we should be good

quickfur commented 4 years ago

Whoa, that fixed it! Now I don't need to manually override TERM anymore. Cool stuff! Thanks!!