guido@mcvax.uucp (Guido van Rossum) (10/03/86)
In article <757@wjvax.wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes: >... What I would like to see is someone >define and implement a new package similar to curses but more powerful. >This package should have a well-defined interface to the >underlying terminal driver library, allowing termcap and terminfo drivers >to be written for it, and even drivers for certain pc's. It should also >have separate drivers for controlling system-dependent information, such >as the BSD job-control-dependent stuff in 4.2 BSD curses. It >should provide a more coherent and general mechanism for performing >input through windows. Finally, it should provide a rational method to >treat dynamic window resizing, which I understand occurs on at least one >system, SUN, and which can be expected to appear on others. > >I don't understand why it would not be possible to take the display end of >one of the powerful, portable editors and turn it into a display package of >this sort. If done right, the core of the package could be completely >portable across systems both unix and non-unix. As such, the package could >become a de facto standard for video character display handling for the C >language. Far too often people keep re-inventing this package for different >editors, even under unix systems (because curses isn't powerful or general >enough). Well spoken. Our group has designed and written a package which looks like it would be a good start. I am posting its specification here to evoke reactions. Implementations are available for Unix (termcap only, runs under 4.{1,2,3} BSD, v7 and System 5) and MS-DOS (Monochrome or Color (CGA, not EGA) monitor). It wouldn't be hard to write a version for the Macintosh, Amiga or Atari ST; in fact I once hacked together a Mac version but it isn't in distributable form. Some things it doesn't do for now: low-level character-I/O, comparable to curses' move and addch; multiple overlapping windows (though Emacs-style windows are trivial to implement on top of it). What it does do, although it doesn't show from the specs, is extensive optimization of redudant operations within a screen line (using insert/delete character if available and useful, for instance). Like Brett suggests, this package was designed as the display part of a powerful, portable editor. It has served in at least three different editors I have written, one of which I am using right now to type this message. If you want the code, write to me and I can mail it to you; it'll be free but copyrighted and available for non-commercial use only. However, the kind of reactions I would like to see most are those proposing a kind of cooperation on the further development of this package to fill the need of a larger group of users, and make it a de-facto standard for portable screen/window manipulation. Discussion in this group seems also fine. Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp> ---------------------------------------------------------------------- Note: these specs are public domain! /* * The VTRM package (Virtual TeRMinal). * * This package uses termcap to determine the terminal capabilities. * * The lines and columns of our virtual terminal are numbered * y = {0...lines-1} from top to bottom, and * x = {0...cols-1} from left to right, * respectively. * * The Visible Procedures in this package are: * * trmstart(&lines, &cols, &flags) * Obligatory initialization call (sets tty modes etc.), * Returns the height and width of the screen to the integers * whose addresses are passed as parameters, and a word of flag * bits that describe some capabilities (specs available on request). * Function return value: 0 if all went well, an error code if there * is any trouble. No messages are printed for errors. * * trmundefined() * Sets internal representation of screen and attributes to undefined. * This is necessary before a hard redraw, which would get optimized to * oblivion. * * trmsense(&y, &x) * Performs a 'cursor sense' if available on the hardware. * Returns the cursor position through its parameters * after a possible manual change by the user; these are set * to -1, -1 if no sense is possible (this may be a temporary * or permanent condition). * * trmputdata(yfirst, ylast, indent, data) * Fill lines {yfirst..ylast} with data, after skipping the initial * 'indent' positions. It is assumed that these positions do not contain * anything dangerous (like standout cookies or null characters). * * trmscrollup(yfirst, ylast, by) * Shift lines {yfirst..ylast} up by lines (down |by| if by < 0). * * trmsync(y, x) * Call to output data to the terminal and set cursor position. * * trmbell() * Send a (possibly visible) bell, immediately (flushing stdout). * * trmend() * Obligatory termination call (resets tty modes etc.). * * You may call these as one or more cycles of: * + trmstart * + zero or more times any of the other routines * + trmend * Trmend may be called even in the middle of trmstart; this makes it * possible to write an interrupt handler that resets the tty state * before exiting the program by simply calling trmend. * * trminput() * Return the next input character (with its parity bit cleared * if any). This value is a nonnegative int. Returns -1 if the * input can't be read any more. Input is not echoed. * * trmavail() * Return 1 if there is an input character immediately available, * 0 if not. Return -1 if unknown. * * THE FOLLOWING SPECS ARE TENTATIVE ADDITIONS: * * trminterrupt() * Return 1 if an interrupt has occurred since the last call to * trminput or trmavail, 0 else. [Currently not implemented.] * * trmsuspend() * When called in the proper environment (4BSD with job control * enabled), suspends the editor, temporarily popping back to * the calling shell. The caller should have called trmend() * first, and must call trmstart again afterwards. * BUG: there is a timing window where keyboard-generated * signals (such as interrupt) can reach the program. */
hansen@pegasus.UUCP (Tony L. Hansen) (10/21/86)
< >... What I would like to see is someone < >define and implement a new package similar to curses but more powerful. < ... < >I don't understand why it would not be possible to take the display end of < >one of the powerful, portable editors and turn it into a display package of < >this sort. < ... < > As such, the package could < >become a de facto standard for video character display handling for the < >C language. Far too often people keep re-inventing this package for < >different editors, even under unix systems (because curses isn't < >powerful or general enough). It was precisely because of the problems with the BSD version of curses which caused the System V version of curses to be created. The original version of System V curses was indeed based on the display end of one of the newer "powerful, portable editors" (Gosling's Emacs). All of that code was subsequently rewritten to make it even more powerful and faster. (For that matter, the BSD curses display code was taken from Vi.) The Vr3 curses was made much faster, and you should see how slick (fast and small!) the Vr3.1 version of curses is. When this version of curses becomes available, I can see no reason for wanting to write one's editor on top of anything else. Tony Hansen ihnp4!pegasus!hansen
gwyn@brl-smoke.ARPA (Doug Gwyn ) (10/21/86)
In article <2859@pegasus.UUCP> hansen@pegasus.UUCP (62545457-Tony L. Hansen;LZ 3B-315;6243) writes: >The Vr3 curses was made much faster, and you should see how slick (fast and >small!) the Vr3.1 version of curses is. When this version of curses becomes >available, I can see no reason for wanting to write one's editor on top of >anything else. It sounds nice, but I'm afraid that it will see relatively little use until and unless SVR3.1 has a more sensible licensing policy. Many vendors decided not to license SVR3.0 due to the silly SVID clause. Perhaps you're in a position to recommend a change in this?
guido@mcvax.uucp (Guido van Rossum) (10/30/86)
In article <2859@pegasus.UUCP> hansen@pegasus.UUCP (Tony L. Hansen) writes: >For that matter, the BSD curses display code was taken from Vi. The BSD curses code cannot have been taken from VI because VI does not contain something like curses. BSD termcap code was taken from VI, but this is only a set of four or five routines. >The Vr3 curses was made much faster, and you should see how slick (fast and >small!) the Vr3.1 version of curses is. When this version of curses becomes >available, I can see no reason for wanting to write one's editor on top of >anything else. Availability. Basing software on AT&T curses limits the distribution range quite seriously (especially in the academic world, I suspect). If you have to fall back on BSD curses where AT&T curses is not available, it may be better to write something yourself on top of termcap. -- Guido van Rossum, CWI, Amsterdam <guido@mcvax.uucp> (PS: I've sent my code to Rich Salz. He said it will take a few weeks before it goes out...)
jeff@gatech.EDU (Jeff Lee) (11/03/86)
>>The Vr3 curses was made much faster, and you should see how slick (fast and >>small!) the Vr3.1 version of curses is. When this version of curses becomes >>available, I can see no reason for wanting to write one's editor on top of >>anything else. >Availability. Basing software on AT&T curses limits the distribution >range quite seriously (especially in the academic world, I suspect). Not to mention the stupid licensing that ATT is attempting with the Vr3 releases that should further limit the distribution of the Vr3.1 release of curses. The licensing reads something like if you include ANY part of Vr3 then your product has to conform to the entire SVID release 3. Am I mistaken or do they keep trying something like this? There were initially stupid pricing policies for Honey DanBer and no educational discounts for the DMD software (it still cost us $1000 educational for DMD). Unix is liked by a lot of people but ATT is a long way from being IBM. If I am wrong I am sure that SOMEONE will correct me. Enjoy, -- Jeff Lee CSNet: Jeff @ GATech ARPA: Jeff%GATech.CSNet @ CSNet-Relay.ARPA uucp: ...!{akgua,allegra,hplabs,ihnp4,linus,seismo,ulysses}!gatech!jeff