Re: Freebsd 14+ -- tcsh incompatible with terminfo

Jamie Landeg-Jones wrote in
 <202311020241.3A22f4o3042181@donotpassgo.dyslexicfish.net>:
 |Steffen Nurpmeso <steffen@sdaoden.eu> wrote:
 |> Why?
 |> (That is to say: why -- if it is a *real* termcap?  If it is only
 |> a translation layer to terminfo, i am with you.  But otherwise
 |> not, i think a real termcap is much, much smaller, while offering
 |> anything a (simple) console program needs.)
 |> That is not to talk small the efforts of Mr. Dickey.  But for
 |> example the mailer i maintain *can* directly use BSD termcap if so
 |> desired, and it works just nice.
 |
 |I agree that termcap does most of what we need already, so my main
 |reason is that there are 2 different systems in use to do the same
 |job, which is annoying. (FreeBSD doesn't exist in a vacuum) As terminfo
 |exists, is supported, and has terminal entries that our termcap doesn't
 |have, it seems to be better to switch to that. I'm sure it would mean
 |less maintenance for the FreeBSD committers too.

I do understand that a bit.  Other than that plain termcap was so
small and i would assume essentially unchanged for decades, that
i do not.  Termcap entries, yes.  I could imagine vt220, xterm,
screen-256color, and take one of st-256color, whatever KDE and
GNOME terminal, and rxvt-unicode.  Makes seven.  Likely
automatically extractable via "infocmp -C" of Dickey's terminfo.

Let's just try that:

  $ rm .TCAP;\
    for f in vt220 xterm screen-256color st-256color \
        rxvt-256color gnome-256color konsole-256color; do \
      infocmp -C $f >> .TCAP;\
    done;\
    ls -l .TCAP
  -rw-r----- 1 steffen steffen 7145 Nov  2 18:40 .TCAP

Not that i come over as a sarcastic person.

 |If terminfo didn't exist, I'd live with termcap.
 |
 |There are also benefits to terminfo:

No.  It is not "also", it is that there are.
And that programs which use facilities of modern terminfo require
terminfo anyway.

Yet it is that many console programs do not (by far), nor do they
know how to use all the amazing things that are possible with
a UNIX terminal (just by glancing over ECMA-48, plus some OSC
extension, plus superficial glancing over tmux console
interaction).

A real (non-wrapper) termcap library is very (very) small, so
small that it could be a header-only thing that is included in
every program (statically that is).

 |https://invisible-island.net/ncurses/ncurses.faq.html#extended_term
 |
 |We don't even run with a "proper" termcap anyway!
 |
 |"The base system's terminal database is referred to as “termcap.db”
 |but is actually an ncurses terminfo hashed database." -  https://invisib\
 |le-island.net/ncurses/ncurses.faq.html#what_platforms
 |
 |So, yeah, despite Mr Dicky's success in making working with both as \
 |seamless
 |as possible ,it would still just be nice to not have to deal with 2 \
 |different
 |standards, that's all.
 |
 |"setaf or AF, that is the question."

So to say.  For example the MUA i maintain needs 12 commands at
maximum (then also 2 for ca_mode and 2 for keypad on/off,
8 otherwise).  This is sufficient for complete control over
command line editing.  If it would, like bash, would implement
multi-line editing it would add i think one or two on top, for
vertical movement.  All these commands are several decades old and
exist everywhere.

Add some queries for auto_right_margin, eat_newline_glitch,
max_colors etc, and several dozen special-key bindings.  The same
is true for those.  You get away without them, of course.

But i tell you what.  Instead of, i do not know, 50 or so
kilobyte, on this Linux system we indeed end up linking against
libncursesw.so.6.4 that is almost half a megabyte and has lots of
symbols and other linker work to be done.

The *complete* ncursesw library!

O tempora, o mores!

--steffen
|
|Der Kragenbaer,                The moon bear,
|der holt sich munter           he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)