@cks

Let me guess: historical termcap. (-:

Might be Joy+Horton #vi, but my first guess is #termcap.

The way that termcap, and even terminfo, handle switchable stuff like this is truly terrible, because it simply does not fit their model. They're poor on input sequences anyway.

#FreeBSD still uses termcap(5), pretty much the only operating system left that does, and its manual page discusses how one might want to be compatible with AT&T #Unix S5R2 in the future.

https://man.freebsd.org/cgi/man.cgi?query=termcap&sektion=5

A destructive back space, to go alongside a destructive forward space, is an exceedingly unusual but valid choice. There are terminals in the termcap database that did this.

If you want actual madness, however, look to u-boot, where BS is non-destructive *unless* the user is using TrueType fonts, when this code kicks in.

https://github.com/u-boot/u-boot/blob/master/drivers/video/console_truetype.c#L480

Just say no to using the BS character for text effects effects in boot loaders, kids! (-:

#uboot #termcap #NetBSD #FreeBSD #EFI

@b0rk Not only have I had this situation, I also have the reverse on my OpenBSD box, where pressing backspace inside tmux sends a control+h (0x08), so to actually backspace I need to type control+backspace (0x7F)

It works fine outside tmux. Gotta get that sorted out at some point. #termcap #terminfo

@cholling @bean

This brings back memories of having to set up my own TERMCAP variable for a 910+ many years ago, because the supplied database entry turned out to be wrong, although all of these years later I don't remember exactly what was wrong with it.

Joy's vi had an "open" mode that, if memory serves, didn't demand/use all of the capabilities that "visual" mode needed.

#termcap #vi

@bean

Of course, there is the O'Reilly book on #termcap and #terminfo, which does have that sort of documentation. But it hasn't been updated since 1992, thus tending to reinforce your point. (-:

@zirias @mpts

Actually you did: "Using termcap/terminfo directly nowadays means using curses." I hope that you understand the point that I was making, now. I don't want to belabour it. (-:

Things come along that expect either the #termcap compatibility functionality of #terminfo and break on true termcap, or the existence of true terminfo databases. Not often enough to press #FreeBSD to change, it appears, but still on a regular basis.

@_bapt_ @mpts

It's a good thing that I didn't say that it was, then. (-:

The whole point is that contrary to what @zirias said there are multiple independent libraries in different softwares and using #termcap/#terminfo directly does *not* mean using (n)curses, nor any lower-level library that it provides.

The world these days, especially the world outwith C/C++, rather works on the presumption that everyone is terminfo. #FreeBSD has brought porting up short several times.

@zirias @david_chisnall @mpts

It might be worth checking how well Write-Progress and its ilk work with only #termcap. And colourization of the error stream and suchlike.

#PowerShell #FreeBSD

@zirias @mpts

That's not enough. There are plenty of things that use #termcap/#terminfo directly without using (n)curses. And as you've seen there are cases where the two aren't exactly the same.

There is a persistent very slow trickle of instances where people come along with something new, which works with terminfo (or its termcap compatibility shims) on every other operating system, and true termcap turns out to be a gotcha in some subtle way. Because no-one targets it any more.

#FreeBSD