tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: tn3270, mset and map3270



On Thu, Mar 04, 2010 at 12:59:54AM -0500, der Mouse wrote:
 > >> 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.

The first could be done in curses if anyone cared enough; however, I'd
question whether either of these really matters. My experience ~20
years ago was that once I moved up from a 2400 baud modem I no longer
cared about screen update issues. Are you using a terminal on a line
(or with equipment) that won't go at least 9600 bps? If so, wouldn't
you rather dump it and replace it with a PC/XT? :-)

 > 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.

Yes, I mentioned that case.

 > > (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.

No, they just can't support that mode. (Or at least, not without extra
gimcrackery.)

Nothing prevents a serial-attached terminal from sending key-up and
key-down codes of whatever kind it prefers. Nothing except of course
legacy Unix-derived system software that can't cope with the concept.

 > > 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), 

Coding it is an afternoon's work. Getting the API right is the hard
part.

 > (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, 

Most such code uses either libedit or libreadline, so it's not a big
patching problem. Besides, if you recall, the original motivation was
to find and kill all such code.

 > 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.

...which would accomplish no more than redboxing on a tcpip network. :-)

(red? I think I mean red...)

-- 
David A. Holland
dholland%netbsd.org@localhost


Home | Main Index | Thread Index | Old Index