Terminal on a notcurses plane

[tomek-szczesny]

Hey there!
I've decided to implement a multi-server ssh client, something like clusterssh, but with TUI. I got a grasp on libssh, that's easy, but the problem of displaying a few terminals in a single terminal is far more complicated than I hoped.
As far as I know, there are only two programs on the face of Earth that catch and reinterpret escape codes of underlying processes, which are screen and tmux. Both implement terminals within themselves, as far as I can tell.

As I was reading htp-notcurses.pdf I stumbled upon a mention of ncprocess widget that was somehow meant to address this problem. Unfortunately, this widget has been mentioned only once, and even Google thinks no such thing exists.

But anyway, notcurses is a WIP, and very promising indeed - so I think it would greatly benefit from a widget that emulates a terminal. If I'm about to implement such functionality anyway, could as well be a part of a library.

One way to achieve that is using libvterm, I believe, a library that parses escape codes and calls callbacks. Anyway, I'm not sure if you consider using an external library kosher.

So, to wrap this up, I wanted to ask what is the current state of affairs. Am I missing something that would ease my task, what happened to ncprocess, is a "terminal widget" a thing you'd like to see in this library?

Thanks a lot!

[joseluis]

Hi there!

You can take a look to these issues to see what's been discussed so far:

• picture-in-a-picture by becoming a pseudoterminal #487
• write a better screen/tmux #1332

I personally think this would be a very good addition to the library...

[tomek-szczesny]

If my experiment works, it may be viable to inspire ncprocess off the libssh's pty management methods. But like I said before, I don't really think notcurses should be expected to provide ncprocess anytime soon. Might as well expect libssh to format a nice output, which sounds daft to me.

[dankamongmen]

yep, completely agreed that the current work doesn't need it. just wanted to think about it.

[tomek-szczesny]

yep, completely agreed that the current work doesn't need it. just wanted to think about it.

I like where's your head at. Thinking about stuff is my lifetime habit. Glad to meet people that do the same.

[dankamongmen]

and i'm glad to have smart Poles wielding English at the level of Józef Teodor Konrad Korzeniowski coming out of nowhere to help out on my little project! if your code is as dexterous as your angielski, you're likely to be a big help indeed =]. Mogę jeść szkło, nie boli mnie to!

[tomek-szczesny]

Wouldn't count on that, I'm just a simple electronics engineer in a lazy space industry, not a coder. ;) But I think you may hope for at least a working prototype.

[tomek-szczesny]

Time for an off topic ramble (as if most of this discussion was on topic)

So I dug into the library and successfully used it. Created an nc_plane, put text in there and all was well. It seems to drop consistent portions of repeated ssh sessions, and it appears that VT spells present in the read buffer make ncplane_putnstr() go apeshit. Also, a finite length of a buffer breaks some escape sequences, which certainly doesn't help.

That's one problem of ncplane_putvt() - it should be assumed that a user will just throw buffer contents right at it, and doing so may break escape sequences (or multi-byte characters). The way I see it, either a user will have to deal with that, or virtual terminal functionality should belong to a dedicated widget, that will store interrupted endings and concatenate them in front of subsequent inputs.
ncplane_putvt() technically could store these stubs in itself and keep track of them for all ncplanes but that's just awfully messy.

Now from the user's perspective, I'm sorry to say that but the project would surely benefit from more verbose and organized manual. There's a book, which ought to be outdated pretty soon. There are some md files in doc/, which are empty aside of the basics, that says basically the same what the book says. There is USAGE.md which is the most helpful, but very hard to navigate. And finally one Wiki page which is an interesting read but doesn't say much about usage.
I think that although you @dankamongmen said you're not a fan of example-based tutoring, this is precisely what most people want. Probably because a certain generation is severely addicted to instant rewards and can't give two shits about 100+ pages read before anything interesting appears on the screen. Or maybe some people just want a recipe from a cookbook to make stuff work before polishing it.
Once I get a good grasp of the library and deal with virtual terminal thing, I may allow myself to write a short tutorial based on my experiences.

[tomek-szczesny]

I take it back - libvterm has NO documentation whatsoever and I claim it unusable. Docs are not included in any package, and the original web location has been wiped out.
No wonder why tmux and screen have their own takes on parsing VT spam (aside from the fact these projects are much older than libvterm).

So I was thinking which approach is the best to develop a parser. Is it yacc/bison code generator, some general parsing library, or (frankly my first idea) a state machine done by hand. The latter is probably the closest to the original implementation in the physical terminal, and the closest to my actual skills. ANSI screams state machine.
Nevertheless, I promised at least a working prototype, so for now I might as well pick anything.
Parsing HTML, bbcode or markdown has been dropped from my list for now, because all of these are inherently stateless (as long as user inputs complete chunks of content). Terminals, on the other hand, have at least a few bytes of state - there are commands that store and recall cursor position, for example. This calls for VT widget rather than VT parsing function, albeit heavily based on ncplane.

Anyway I'm starting to think this will be a truly unique feature of notcurses. If you think about it, this will make notcurses a sole viable library to implement a true TUI desktop environment. This is fucking exciting.
Screw implementing a better tmux/screen alternative, go full DE! A text-based i3 clone would take the FLOSS community by storm.

[dankamongmen]

I take it back - libvterm has NO documentation whatsoever and I claim it unusable. Docs are not included in any package, and the original web location has been wiped out.

libvterm did not overwhelm with its quality when i looked into it, it is true. it dimmed my eagerness to work on this stuff.

(frankly my first idea) a state machine done by hand

i definitely don't think yacc is applicable, since this ought be a regular language and thus at the level of flex.

i don't know about you, but i find flex a bit ungainly. i am similarly inclined towards hand-consed state machines.

on the other hand, we have exactly such a state machine in src/lib/input.c, and it does not bring me great delight. i have a sinking feeling that the first CVE against this project will originate in that code.

Anyway I'm starting to think this will be a truly unique feature of notcurses. If you think about it, this will make notcurses a sole viable library to implement a true TUI desktop environment. This is fucking exciting.
Screw implementing a better tmux/screen alternative, go full DE! A text-based i3 clone would take the FLOSS community by storm.

heh there's a dude working on that (kinda): https://github.com/o-sdn-o/VTM

i'd like the interface of any such state machine to be streaming -- i.e., i can call it with 1 <= N bytes of input and it will run through them, and maintain enough context to pick up where it left off. this ought include any necessary UTF-8 character and EGC division.

the only thing that really makes sense in terms of an interface IMHO is something like:

ssize_t ncplane_putvt(struct ncplane*n, struct ncvtctx* vtctx, const char* buf, size_t s);

returning the number of bytes interpreted on success, and the negative number of bytes interpreted on failure, failing as soon as there is any kind of problem. as things are read, it is translating them into operations on the ncplane. failures can happen either due to a bad lex or a bad output operation.

maybe we need some kind of recovery. i'm unsure.

is this similar to what you were thinking?

[tomek-szczesny]

i definitely don't think yacc is applicable, since this ought be a regular language and thus at the level of flex.
i don't know about you, but i find flex a bit ungainly. i am similarly inclined towards hand-consed state machines.

Actually I learned about all these existing solutions yesterday, when I did some research. I didn't like them either, but for some reason I felt that doing stuff by hand is generally discouraged these days. I have no problem coding all that myself and definitely will give it some thought to make it look and feel clean.

on the other hand, we have exactly such a state machine in src/lib/input.c

Great, then it may be reused even internally. What is this currently used for?

heh there's a dude working on that (kinda): https://github.com/o-sdn-o/VTM

Drop-in replacements tend to get more attention. That's why maybe an i3-compatible DE would be seen as something more than yet another peculiarity. I know Sway got hugely successful because it just works with i3 config files and all - it's currently one of the better recognized Wayland compositors out there. i3 is biased towards keyboard operation by design.
But then again, that's just a thing to think about in spare time, far beyond our current capabilities.

i'd like the interface of any such state machine to be streaming -- i.e., i can call it with 1 <= N bytes of input and it will run through them, and maintain enough context to pick up where it left off. this ought include any necessary UTF-8 character and EGC division.

Same here, I'd prefer to just yank data from SSH channel and put it right into ncplane_putvt() without any further complications. There is a need to store some context data and I wasn't sure how to approach this issue, but I like your idea. That's even better, because vtctx may be optional (== NULL), if a user is confident this will never be necessary for their application (for example print the output of a command only once).

returning the number of bytes interpreted on success, and the negative number of bytes interpreted on failure, failing as soon as there is any kind of problem. as things are read, it is translating them into operations on the ncplane. failures can happen either due to a bad lex or a bad output operation.

Yes, precisely what I was planning to do - take a look at each byte one by one and feed them into the state machine. I just hope the efficiency of such approach will be acceptable - honestly no idea. If I did that with TTLs in 1975 I can tell it would be state of the art. We shall see how well it translates to machine code, I guess.

I'm not worried about error recovery for now - as far as I'm concerned, no mainstream terminals or standards defined how to handle erroneous input. The only source of errorrs for now are negative returns from underlying ncplane operation calls.

Thanks for your time - now I've got a really solid idea what I'm aiming for. I'll create a demo with a state machine sufficient to handle toilet --gay dupa and work from there. Sounds okay to you?

[dankamongmen]

Actually I learned about all these existing solutions yesterday, when I did some research. I didn't like them either, but for some reason I felt that doing stuff by hand is generally discouraged these days. I have no problem coding all that myself and definitely will give it some thought to make it look and feel clean.

there are no beautiful alternatives here.

i concur that the tightness of the VT language makes it pretty amenable to hand-coded FSA.

on the other hand, we have exactly such a state machine in src/lib/input.c
Great, then it may be reused even internally. What is this currently used for?

nooo. it processes replies to our initial burst of query strings. it's the other direction from where you want to be.

everything else sounds good!

the one thing i'd maybe recommend is that you have your different states be different functions, and not different cases in a switch like mine in input.c, so that we can check that all possible paths have a sensible destination (though this is basically equivalent to error recovery). but don't take that as a hard requirement. gigantic state machines are definitely difficult to review IMHO but that's probably independent of scope fracture [shrug].

one thing is that i think we'll need a terminfo database corresponding to this, and it should be built up alongside the lexer. it ought not be cribbed from an existing definition. i was reminded of this thinking about how we're going to test this. which, we'll need to have unit tests around this for sure. take a look at src/tests and notcurses-tester.

ummmm bonus points if you wrap a fuzzer around it.

hack on!

[tomek-szczesny]

Good, you're slowly getting the idea of my capabilities. That's a bunch of tips I needed, thanks.
I haven't thought of making function-based state machine but the idea is sound to me. Should be much easier to manage errors, and especially sudden end of string.

gigantic state machines are definitely difficult to review IMHO

This is why I want to start up small, handle a few color codes and cursor moshing around the pty. As I said, I'll try to manage toilet's colorful output first, but later I shall be challenged with htop's ncurses-invoked cursor movement.

I'll try to keep an up-to-date list of supported spells, so it's easier to update terminfo entry. Gotta learn how to do it though, I assume you have no prior experience with that either, but it shouldn't be that hard, I reckon.

I have no idea about software tests, but I'll take a look at that later on. Fuzz test should be easy - just input random data and see if it crashes, right?