Re: tn3270, mset and map3270

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>>> Yes.  The *interface* is called "curses".  How about we hunt down
>>> and kill off all the programs that still use *either* raw termcap
>>> or raw terminfo?

>> For what it may be worth, in my opinion that would be a crippling
>> regression.

>> One of the programs I use most heavily day-to-day uses termcap
>> directly and, while it might be possible to adapt it to a
>> curses-only interface, it would be rather difficult and would
>> involve at least a little functionality loss (possibly more; I
>> wouldn't know without trying).

> What does it do?

It's...well, basically, a text editor.

The functionality losses I mentioned are (1) the ability to pause a
screen update partway through to handle new user input and (2) various
application-specific update optimizations made possible by integration
of the screen updater with the bulk of the thing.

Since I wrote that, it has occurred to me that some shells'
command-line editors use terminal-specific sequences to construct a
non-fullscreen interface.  While I don't personally like them for most
purposes, I do not think they are so wrongheaded that it shouldn't even
be possible to construct them.

> I tend to think of curses as a regression relative to e.g. DOS
> <conio.h>,

Which it is, in terms of available functionality.  It is a significant
advance in terms of portability, though - <conio.h> doesn't support
terminals on the other ends of serial lines, for example.

> but it does mostly cover the territory for full-screen apps.

(1) "Mostly" != "entirely", and (2) there are non-full-screen uses for
termcap/terminfo, such as those shells I mentioned.

> (The most glaring omission is that you can't use the input key
> handling with select/poll; next is probably that you can't do raw key
> up/down input;

That last is, unfortunately, fundamental, unless you propose to abandon
serial-line-attached devices entirely.

> and it would be nice if there were a clearly defined portable way to
> make SIGWINCH handling behave.  But using raw termcap doesn't exactly
> improve the experience for any of these cases.)

True; those are basically orthogonal to the "curses is the One True
Interface" question.

> Admittedly, there should be some kind of curses-like library for
> line-mode apps, but we could write that.

That has at least three problems that come to mind immediately, two of
which strike me as fairly major: (1) whom are you volunteering to write
this (and how quickly will it be done), (2) a system designed around
this library and curses as the only Approved terminal-specific
interfaces would be incompatible with third-party code which expects a
termcap or terminfo backend, and (3) it would have the same basic
problem curses has: "one size fits all" interfaces generally end up
being "one size sorta mostly fits most" interfaces (invariably, in my
experience, though for varying degrees of "mostly" and "most").

Furthermore, it's pretty pointless.  If I as a code author were
subjected to such a system, honestly, I would most likely simply ship a
copy of libtermcap and/or libterminfo with my application.

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B