termbox2 as third screen library for Linux

[dataman]

​https://github.com/termbox/termbox2 is the fast, compact (one header file) and light (2676 SLOC) TUI library and no dependencies beyond libc.

Would be nice to support it in MC.

[zaytsev]

To achieve what?

[dataman]

Replying to zaytsev:

To achieve what?

As a good replacement to ncurses. I tried compile MC with ncurses and it's buggy. Maybe that's why many Linux distributions use building with slang.

[zaytsev]

I tried compile MC with ncurses and it's buggy.

Maybe you could fix the bugs and provide patches?

Maybe that's why many Linux distributions use building with slang.

No idea, slang has been historically faster at new advanced options like Unicode or colors, but in theory latest ncurses and latest slang should be on par right now. Barring some special problems with each of the libraries like shifted keys.

As a good replacement to ncurses.

So what's your problem with S-Lang?

I don't see how termbox2 is a replacement to ncurses and how it makes the situation better. ncurses are supported at all these days, because many Unix systems provide their implementation thereof, and slang first needs to be ported there. Otherwise we could have just dropped them and focused on slang. Or dropped slang and focused on ncurses, actually.

Replacing ncurses with some unknown library (no distro other than Slackware ships it) that has no track record doesn't sound like solving any problems, but creating an insane amount of work and helping no-one. There are literally dozens of random ways to spend time that are better in that they are actually achieving something for everyone, like:

• Collect extfs sample data
• Write tests
• Fix bugs
• Port low-level code to glib2
• ...

I can follow the argument of Egmont that maybe we should drop both ncurses and slang, and implement our own minimal library with only what we need, since we have so much workarounds for library-specific problems. But adding yet another library, or replacing an existing one...

Egmont, would you be so kind to comment on this?

[egmont]

I can follow the argument of Egmont that maybe we should drop both ncurses and slang [...]

You're referring to #3264. As far as I recall, this idea of mine was pretty much frowned upon. But I'd also like to reinforce my opinion which I expressed there at the beginning: having two libraries is bad, IMO the project should pick one and use that. With this in mind, offering support for three libraries is IMO even worse.

I haven't heard of termbox2, but seeing on its homepage that it's part of the suckless project gives me bad feelings about it. I truly hate suckless's approach to software development (through the example of one of their projects): absolutely minimal codebase (wrt. functionality), by design additional functionalities are available as patches that you can choose whether to apply or not (there goes packageability by distros), lack of bugtracker, also bugreports without patches aren't welcome, once I reported one I got a truly hostile response from one of their devs (but at least others stood up for me on the mailing list).

These experiences are by no means necessarily representative, and also termbox2 might do things somewhat differently (for starter, it does have a bugtracker), but still, even if it's prejudice only, I'd be cautious with anything related to suckless. They're not my cup of tea, to say the least.

If anything, I guess notcurses might be more interesting to take a look at (I've just updated the last comment of 3264 to mention it). At least, I've come across that project's name quite a few times during the last few years, i.e. it might have a bigger traction / wider adoptation (it's packaged by Debian unstable / Ubuntu / Fedora / Arch at least), plus at least there's nothing bad prejudice I could say about it. But then again, I have no experience whatsoever with that project either.

[zaytsev]

You're referring to #3264. As far as I recall, this idea of mine was pretty much frowned upon.

Well, if you mean Andrew, he is a perfectly reasonable man who can be convinced with rational arguments, and I can completely understand his knee-jerk reaction of "are you insane?". We have enough problems maintaining two tty layers, and then someone comes along and suggests solving the problem by reinventing yet another TUI library... Of course, the initial reaction probably won't be unbridled joy.

My stance on this is that if someone can produce...

• a minimal layer that only does what we need
• has a comparable amount of code to our 2 tty layers
• has tests (unlike our tty stuff :-( )
• solves hacks / problems with keys and mouse
• removes dependencies on slang and curses

... it would definitely be worth a shot.

Bonus points if it opens the door to writing enough terminal emulation to properly embed subshell in mc instead of the atrocity of crazy hackery we have now.

The problem is, I don't have nearly enough exposure to the terminal stuff to tackle something like that and be done before the turn of the century. So it seems like the limited amount of time I have is better spent doing infrastructure stuff that no one wants to do and the lack of which really jeopardizes the project in the mid/long term.

Sounds like a perfect project for you though ;-) Don't tell me you have another child :-)

Having two libraries is bad, IMO the project should pick one and use that

I agree. If it were up to me, I would have removed slang a long time ago and just kept curses.

The problem is that once slang is removed, people will be forced to use curses, and that will open a floodgate of bug reports that I wouldn't know how to deal with.

I'm not quite sure how slang got added in the first place, probably something to do with the troubled history of curses, Unicode support, and new features. But for me, curses have the huge advantage of being literally everywhere. Just a few weeks ago, I did a port to AIX, and guess what? Even if the operation is degraded due to older curses, that's perfectly fine. Most will get the newest ones anyway.

So if we are NOT going to implement our own library and continue to use an external one, I don't think there is a better option than curses that meets our needs in terms of availability. I have nothing against notcurses per se, but any dependency I don't have to port to Solaris or AIX or HP-UX is a win.

[egmont]

Well, if you mean Andrew, he is a perfectly reasonable man who can be convinced with rational arguments, and I can completely understand his knee-jerk reaction of "are you insane?".

The referred conversation took place 10 years ago. I did not refresh my memories now, can't recall who participated and who said exactly what. My overall impression was that this idea wasn't welcome, and I believe I sort of accepted that; didn't want to and still don't want to push for that idea.

Bonus points if it opens the door to writing enough terminal emulation to properly embed subshell in mc instead of the atrocity of crazy hackery we have now.

I truly wouldn't go down this rabbit hole. I think the current subshell code is better (although I don't know how hacky the actual code is) in the sense that whatever my terminal emulator supports, it's automatically supported in mc's subshell as well. Having an intermediate terminal emulation layer in mc would necessarily limit the features to the intersection of mc's and my native terminal's features, which is not something I'd be looking forward to.

But for me, curses have the huge advantage of being literally everywhere.

There's definitely a strong advantage in using the de facto standard solution.

[zaytsev]

I truly wouldn't go down this rabbit hole.

Well, maybe you're right. I guess my lack of exposure to the terminal stuff automatically makes me more hostile to our current solution. My current understanding is that, architecturally, we have

• A custom prompt that we use to control the shell
• Pipes through which we get the current directory or send change directory commands
• Alternate screen, which is basically what sits behind the panels.

This is annoying in many ways:

• Custom and fragile code to support each shell, which breaks all the time.
• Not all shells are even advanced enough for us to remove our endless cd commands from history.
• Shell lockups happen when something breaks, if shells are slow they lock mc.
• Shell output behind panels is lost on toggle if no altscreen
• Partial splits are not possible

The latter points can probably be solved by "proper" embedding via proxy terminal emulation, but now that I think about it, the first part will probably be just as bad as before :( I was thinking in the direction of OSC 7, but the shells certainly don't support that stuff, and if they do, then inconsistently.

Oh well, so basically we can't do any better than we do now... but in any case, it feels like you definitely think that terminal emulation and proxying are going to be hell.

[zaytsev]

didn't want to and still don't want to push for that idea.

If nothing else, it would be great to kill slang. Maybe one day I'll man up to handle the fallout.

[egmont]

If nothing else, it would be great to kill slang.

FYI: ncurses build is still affected by #3158 (no double lines and some other similar chars).

As OP suggested, it's probably just one of a few problems.

[zaytsev]

I know, this is exactly what I meant. There are also other differences, like bold being automatically included in bright colours, something with shifted keys, mouse stuff, etc. :-( but now it's quiet because nobody really uses it.

[egmont]

but in any case, it feels like you definitely think that terminal emulation and proxying are going to be hell.

I can't see how much of a hell the current subshell situation is, but it seems to me from your comment that indeed is quite a hell.

Proxying is not necessarily bad, but it would have its own downsides. One I've just mentioned is about being limited to intersection of the features of the two layers. Another is probably not being able to use the native terminal's scrollback; having to resort to own scrolling methods as in screen or tmux (but maybe it's possible to make it work natively as expected). There's surely several more.

It's unclear to me which one is the bigger hell. From a user's point of view, I think the current subshell code works decently with most popular shells, it's mostly the developers for whom it sucks a lot. The other approach, given a plethora of terminal emulators, would probably expose more problems towards end users. Just my guess.

That being said, if you decide to experiment, I'd first look into libvterm (note: _not_ libvte) which is a headless terminal emulation library. I have no experience with that piece of software, but architecturally this is probably what mc needs, assuming it doesn't want to implement a terminal emulator engine from scratch.

[andrew_b]

Replying to egmont:

That being said, if you decide to experiment, I'd first look into libvterm (note: _not_ libvte) which is a headless terminal emulation library.

I know two different libraries with this name:

​https://github.com/TragicWarrior/libvterm
​https://github.com/neovim/libvterm

And

​https://www.freedesktop.org/wiki/Software/libtsm/
​https://github.com/Aetf/libtsm