[Question] not all cap names are extracted from terminfo database?

[ericwq]

When I browse the dynamic.go. I notice only three boolean cap names are extracted from terminfo database. Which is Tc, RGB and npc.

Could you tell me why?

[gdamore]

I only extract the ones that I am going to use. There are a ton of capabilities in terminfo that we don't use at all and there is no point bloating the database to keep them.

[ericwq]

OK, can u make terminfo a separate go module, so anyone can update it?

[gdamore]

I'd rather not. You can just use the terminfo package directly and it does have a parser for terminfo databases, which you can make use of.

My own local database (which is pre-extracted) is for tcell's own use. It isn't really intended to support other applications per se.

Out of curiosity, is there a specific capability that you're wanting?

[ericwq]

bce, ech, and smcup, rmcup are my concern. I am still evaluating the best way to reuse the tcell effort.

[gdamore]

So I think I get all those except ech. The concern with ech for tcell is consistent handling across implementations. Since tcell uses a cell based view of the screen it isn't necessary - we just overwrite a cell with a space to effect an erase.

But if you want to make a line editor then maybe you want something that erases and moves the content afterwards.

[gdamore]

So we use "clear" rather than "bce". If you look, bce is not well supported by common terminals. For example, the terminfo entry for xterm256-color on Darwin doesn't have an entry for it.

Conversely, "ech" is supported, but largely (IMO) redundant to echoing a space. The one advantage it offers is a little more efficiency if you have to clear many characters (for example clearing most of a row), because you send fewer characters. But you really need to be clearing at least 5 characters to obtain any gain.

I'd be open to extending the terminfo descriptions to include this, and to optimizing tcell to minimize what it sends using this escape. However, there are some caveats; for example see the "xhp" and "eo" capabilities.

There may be more useful sequences as well: "el" for clearing to the end of the line (useful for line editors, but see also "el1"), and "ed". However, most of the time these sequences are going to be useful in applications that are not full screen oriented but rather in line editing type applications, where the end and bottom of the screen from the cursor position should be cleared. If you have a full screen application with a border, or displayed elements at the bottom, then this is probably less efficient.

Btw, for line editors, there are other capabilities that are interesting as well, "dl", "dl1", "il", "il1".

I'd possibly be willing to extend the terminal database to hold these properties for use by such applications. One could imagine making a readline type library on top of those capabilities.

[ericwq]

Thanks for your time and answer.
What I am trying to do is to rewrite mosh with golang. It is here aprish. Basically, it's a terminal emulator. It needs to accept and understand the escape sequence, using them to modify the server screen and sync the screen state to the client side.

What I need is a set of low-level terminfo routines. Which I can use to initialize (likesetupterm() in c++) the terminal and query the terminfo DB with t.GetNum(), t.GetString(), t.GetBool. Then I can use TPuts(), TParm(), TGoto(), TColor() to send the screen state to client. Hope my project can explain why I need such kind of terminfo capability.

BTW, here is my infocmp output from my Mac:

qiwang@gauss /etc % infocmp -x -1 xterm-256color | grep ech
        ech=\E[%p1%dX,
qiwang@gauss /etc % infocmp -x -1 xterm-256color | grep bce
        bce,

[ericwq]

The application API provided by tecll may be used by the project. While the low level API is necessary for the project.

The original mosh project uses escape sequence directly in c++ code. I want to rewrite it with terminfo cap. Later, I may find more terminfo capability is needed by the project. That's why a separate golang module is a necessary.

BTW, in mkinfo.go file, smcup and rmcup capability is injected into Terminfo struct. I don't find any code relate to bce and ech capability.

[gdamore]

Note that for tcell v3 we have finally abandoned terminfo altogether. After a lot of research, I discovered that all modern terminals have a good common subset that they support, and they basically ignore the rest. This also helps with terminfos that are incomplete, or for terminals that have evolved but terminfo has not.

I think terminfo is an idea whose time has passed. We no longer have to support wildly incompatible terminals like DG200 or TVI925 or Wyse60.

Note that you might have to expand on what I've done, since i don't worry about all the possibilities -- tcell only needs a relatively small subset. But I suspect you can distill your needs to a common subset as well.

I'm closing this for now.