System V curses implementations can support BSD curses programs with just a recompilation, so by capturing the System V API we also capture BSD's.
More importantly for the future, the XSI Curses standard issued by X/Open is explicitly and closely modelled on System V. So conformance with System V took us most of the way to base-level XSI conformance.
Accordingly, we have a policy of associating with each nonstandard extension a feature macro, so that ncurses client code can use this macro to condition in or out the code that requires the ncurses extension.
For example, there is a macro NCURSES_MOUSE_VERSION which XSI Curses does not define, but which is defined in the ncurses library header. You can use this to condition the calls to the mouse API calls.
We encourage (but do not require) developers to make the code friendly to less-capable UNIX environments wherever possible.
We encourage developers to support OS-specific optimizations and methods not available under POSIX/ANSI, provided only that:
The reason for choosing HTML is that it's (a) well-adapted for on-line browsing through viewers that are everywhere; (b) more easily readable as plain text than most other markups, if you don't have a viewer; and (c) carries enough information that you can generate a nice-looking printed version from it. Also, of course, it make exporting things like the announcement document to WWW pretty trivial.
The lib_trace.c, lib_traceatr.c, and lib_tracechr.c file are used only for debugging support. It is rather unlikely you will ever need to change these, unless you want to introduce a new debug trace level for some reasoon.
There is another group of files that do direct I/O via tputs(), computations on the terminal capabilities, or queries to the OS environment, but nevertheless have only fairly low complexity. These include: lib_acs.c, lib_beep.c, lib_color.c, lib_endwin.c, lib_initscr.c, lib_longname.c, lib_newterm.c, lib_options.c, lib_termcap.c, lib_ti.c, lib_tparm.c, lib_tputs.c, lib_vidattr.c, and read_entry.c. These are likely to need revision only if ncurses is being ported to an environment without an underlying terminfo capability representation.
The files lib_kernel.c, lib_raw.c, lib_tstp.c, and lib_twait.c have serious hooks into the tty driver and signal facilities. If you run into porting snafus moving the package to another UNIX, the problem is likely to be in one of these files.
Almost all of the real work is done in the files hardscroll.c, lib_addch.c, lib_doupdate.c, lib_mvcur.c, lib_getch.c, lib_mouse.c, lib_refresh.c, and lib_setup.c. Most of the algorithmic complexity in the library lives in these files. If there is a real bug in ncurses itself, it's probably here. We'll tour some of these files in detail below (see The Engine Room).
Finally, there is a group of files that is actually most of the terminfo compiler. The reason this code lives in the ncurses library is to support fallback to /etc/termcap. These files include alloc_entry.c, captoinfo.c, comp_captab.c, comp_error.c, comp_hash.c, comp_parse.c, comp_scan.c, and parse_entry.c, read_termcap.c, and write_entry.c. We'll discuss these in the compiler tour.
The central data structure in this module is a FIFO queue, used to match multiple-character input sequences against special-key capabilities; also to implement pushback via ungetch().
The wgetch() code distinguishes between function key sequences and the same sequences typed manually by doing a timed wait after each input character that could lead a function key sequence. If the entire sequence takes less than 1 second, it is assumed to have been generated by a function key press.
Hackers bruised by previous encounters with variant select(2) calls may find the code in lib_twait.c interesting. It deals with the problem that some BSD selects don't return a reliable time-left value. The function timed_wait() effectively simulates a System V select.
Under xterm, however, mouse event notifications come in via the keyboard input stream. They are recognized by having the kmous capability as a prefix. This is kind of klugey, but trying to wire in recognition of a mouse key prefix without going through the function-key machinery would be just too painful, and this turns out to imply having the prefix somewhere in the function-key capabilities at terminal-type initiialization.
This kluge only works because kmous isn't actually used by any historic terminal type or curses implementation we know of. Best guess is it's a relic of some forgotten experiment in-house at Bell Labs that didn't leave any traces in the publicly-distributed System V terminfo files. If System V or XPG4 ever gets serious about using it again, this kluge may have to change.
Here are some more details about mouse event handling:
The lib_mouse()code is logically split into a lower level that accepts event reports in a device-dependent format and an upper level that parses mouse gestures and filters events. The mediating data structure is a circular queue of event structures.
Functionally, the lower level's job is to pick up primitive events and put them on the circular queue. This can happen in one of two ways: either (a) _nc_mouse_event() detects a series of incoming mouse reports and queues them, or (b) code in lib_getch.c detects the kmous prefix in the keyboard input stream and calls _nc_mouse_inline to queue up a series of adjacent mouse reports.
In either case, _nc_mouse_parse() should be called after the series is accepted to parse the digested mouse reports (low-level events) into a gesture (a high-level or composite event).
The main job is to go from the current state of the screen (as represented in the curscr window structure) to the desired new state (as represented in the newscr window structure), while doing as little I/O as possible.
The brains of this operation are the modules hardscroll.c and lib_doupdate.c; both use lib_mvcur.c. Essentially, what happens looks like this:
The hardscroll.c module tries to detect vertical motion changes between the real and virtual screens. It does so by comparing line number vectors between curscr and newscr; both are modified by vertical-motion and clear operations, and both are re-initialized after each update.
The hardscroll.c module computes an optimum set of scroll, insertion, and deletion operations to make the vectors match. It calls _nc_mvcur_scrolln() in lib_mvcur.c to do those motions.
Then lib_doupdate.c goes to work. Its job is to do line-by-line transformations of curscr lines to newscr lines. Its main tool is the routine mvcur() in lib_mvcur.c. This routine does cursor-movement optimization, attempting to get from given screen location A to given location B in the fewest output characters posible.
The configuration code prefers the POSIX regex facility, modeled on System V's, but will settle for BSD regexps if the former isn't available.
The implementation therefore starts with a table-driven, dual-mode lexical analyzer (in comp_scan.c). The lexer chooses its mode (termcap or terminfo) based on the first `,' or `:' it finds in each entry. The lexer does all the work of recognizing capability names and values; the grammar above it is trivial, just "parse entries till you run out of file".
One possibly interesting aspect of the implementation is the way the compiler tables are initialized. All the tables are generated by various awk/sed/sh scripts from a master table include/Caps; these scripts actually write C initializers which are linked to the compiler. Furthermore, the hash table is generated in the same way, so it doesn't have to be generated at compiler startup time (another benefit of this organization is that the hash table can be in shareable text space).
Thus, adding a new capability is usually pretty trivial, just a matter of adding one line to the include/Caps file. We'll have more to say about this in the section on Source-Form Translation.
This won't do for ncurses. The problem is that that the whole compilation process has to be embeddable in the ncurses library so that it can be called by the startup code to translate termcap entries on the fly. The embedded version can't go promiscuously writing everything it translates out to disk -- for one thing, it will typically be running with non-root permissions.
So our tic is designed to parse an entire terminfo file into a doubly-linked circular list of entry structures in-core, and then do use resolution in-memory before writing everything out. This design has other advantages: it makes forward and back use-references equally easy (so we get the latter for free), and it makes checking for name collisions before they're written out easy to do.
And this is exactly how the embedded version works. But the standalone user-accessible version of tic partly reverts to the historical strategy; it writes to disk (not keeping in core) any entry with no use references.
This is strictly a core-economy kluge, implemented because the terminfo master file is large enough that some core-poor systems swap like crazy when you compile it all in memory...there have been reports of this process taking three hours, rather than the twenty seconds or less typical on the author's development box.
So. The executable tic passes the entry-parser a hook that immediately writes out the referenced entry if it has no use capabilities. The compiler main loop refrains from adding the entry to the in-core list when this hook fires. If some other entry later needs to reference an entry that got written immediately, that's OK; the resolution code will fetch it off disk when it can't find it in core.
Name collisions will still be detected, just not as cleanly. The write_entry() code complains before overwriting an entry that postdates the time of tic's first call to write_entry(), Thus it will complain about overwriting entries newly made during the tic run, but not about overwriting ones that predate it.
The translation output code (dump_entry() in ncurses/dump_entry.c) is shared with the infocmp(1) utility. It takes the same internal representation used to generate the binary form and dumps it to standard output in a specified format.
The include/Caps file has a header comment describing ways you can specify source translations for nonstandard capabilities just by altering the master table. It's possible to set up capability aliasing or tell the compiler to plain ignore a given capability without writing any C code at all.
For circumstances where you need to do algorithmic translation, there are functions in parse_entry.c called after the parse of each entry that are specifically intended to encapsulate such translations. This, for example, is where the AIX box1 capability get translated to an acsc string.
The tput and clear utilities just do an entry load followed by a tputs() of a selected capability.
Please join the ncurses mailing list. See the INSTALL file in the top level of the distribution for details on the list.
Look for the string FIXME in source files to tag minor bugs and potential problems that could use fixing.
Don't try to auto-detect OS features in the main body of the C code. That's the job of the configuration system.
To hold down complexity, do make your code data-driven. Especially, if you can drive logic from a table filtered out of include/Caps, do it. If you find you need to augment the data in that file in order to generate the proper table, that's still preferable to ad-hoc code -- that's why the fifth field (flags) is there.
Have fun!