Support configurable curses library

[avylove]

We talked in the past about leveraging something like Jinxed to provide terminal info instead of Curses. I'm not sure about wholly swapping it, but, in some cases, it would be good to be able to use Jinxed (or equivalent) even on non-Windows platforms.

My current use case is one where a library can have multiple output formats (terminal, HTML, etc), but uses terminal escapes as a common language because it was initially designed for terminals only. For HTML and the like, I don't need the local system to support all the capabilities, I just need a portable, full featured reference to xterm-256color. It's usually not an issue, but FreeBSD's old school termcap implementation is out there and I'm sure it's not the only one.

Jinxed already works on Linux, but in Blessed we use imports to determine the curses library to use. For most places it's used, the curses library could just be made an argument, using the current values as defaults. The one that seems less clean is ParameterizingString which calls tparm() I guess we could pass term to __new__ and grab it from there.

Thoughts?

[jquast]

I think it’s a good idea, to allow to install and use without curses, or, even with curses, to depend on jinxed instead, /etc/termcap or whatever isn’t maintained anymore, all of the modern terminal emulators are just adding their own new sequences without any concern for it. TERM=“screen” has a lot of issues, some workarounds in blessed for it, and it’s from the very same maintainers of termcap so it’s really hopeless that if they can’t get it right then nobody is, so many modern terminal libraries just assume xterm without checking, and nobody seems to notice anyway! I think the community has basica Lu agreed to bypass termcap especially if you want to add support for recently added sequences in kitty, iterm2, etc.

…

-- Jeff Quast ***@***.***

On Wed, Oct 5, 2022, at 5:28 PM, Avram Lubkin wrote: We talked in the past about leveraging something like Jinxed to provide terminal info instead of Curses. I'm not sure about wholly swapping it, but, in some cases, it would be good to be able to use Jinxed (or equivalent) even on non-Windows platforms. My current use case is one where a library can have multiple output formats (terminal, HTML, etc), but uses terminal escapes as a common language because it was initially designed for terminals only. For HTML and the like, I don't need the local system to support all the capabilities, I just need a portable, full featured reference to xterm-256color. It's usually not an issue, but FreeBSD's old school termcap implementation is out there and I'm sure it's not the only one. Jinxed already works on Linux, but in Blessed we use imports to determine the curses library to use. For most places it's used, the curses library could just be made an argument, using the current values as defaults. The one that seems less clean is `ParameterizingString` which calls `tparm()` I guess we could pass `term` to `__new__` and grab it from there. Thoughts? — Reply to this email directly, view it on GitHub <#243>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHNOKFVUOVT4Q3I3HCRTDLWBXXI3ANCNFSM6AAAAAAQ56EWNI>. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[avylove]

I'm torn on if jinxed should be relied on completely. You're right, most other libraries just use hardcoded xterm values and no one seems to notice, though I expect there are some users of Blessed that rely on it because we don't do that.

That said, using terminfo or the like is only useful if it's actually maintained. I think @ThomasDickey does a good job of maintaining that upstream, but not all distros do a good job of keeping it updated or even using it at all. And even if it's there, it doesn't mean Python would use it. On FreeBSD the terminfo database is installable as a separate package, but I didn't see a way to get Python to use it instead of /etc/termcap.

Here are a few things we can do:

1. Make curses optional on all platforms
   • Set curses class as Terminal parameter
     • Use existing behavior (for now) when unset
   • Modify other classes/functions to use the class specified in Terminal
2. Optionally look into adding terminfo parsing directly to Jinxed, so it could fall back to terminfo for uncommon terminals
   • This is a binary format described here
3. Potentially switch the default on non-Windows from curses to jinxed
   • The other stuff would have to be done first
   • I think this would be a major version change

Of course the big challenge here is time which is not a thing either of us have a lot of these days.

[jquast]

I'll just add that I initially started using blessed because I had a hardware terminal at the time, and used TERM=wyse325 or some such, for use in https://github.com/jquast/x84, there were strange artifacts on that terminal when using "ansi" or "xterm" sequences but it worked swimmingly when used through blessed/blessings because it used the right terminal capabilities db

[jquast]

Oh, I'd like to add, there is a way to query a terminal interactively for its terminfo database! In this way, a special termcap like xterm-kitty is compatible on a remote system that doesn't know anything about it. It is called XTGETTCAP, See https://invisible-island.net/xterm/ctlseqs/ctlseqs.html#h3-Device-Control-functions under DCS + q Pt ST

I've done some experiments with this, and naturally it isn't supported by all terminals, I don't know the numbers yet but unless its 100% it isn't really worth perusing in a core library like blessed, and that it would cause some delay for first initialization or first use of each terminal capability.

But it is interesting :)