Artifact 419b791078fd090ac1efbd74ebe394de919c6d80197e1ac647dc598e361fb88f:

• Executable file r38/lisp/csl/cslbase/ctrl-c.txt — part of check-in [f2fda60abd] at 2011-09-02 18:13:33 on branch master — Some historical releases purely for archival purposes

  git-svn-id: https://svn.code.sf.net/p/reduce-algebra/code/trunk/historical@1375 2bfe0521-f11c-4a00-b80e-6202646ff360 (user: arthurcnorman@users.sourceforge.net, size: 1604) [annotate] [blame] [check-ins using] [more...]

     Line editing and keyboard controls (eg ^C)
     ==========================================



CSL can run in a whole range of modes and environments, and that
fact seriously complicates life for the implementation of support
for local editing and ^C processing. The modes are:

(1) Via fwin in a window that I control.
    In this case keyboard input is received as events via the FOX
    toolkit, and everything is easily under my own control.

(2) With fwin, and keyboard input direct from a "terminal" (and
    with output sililarly direct to a "terminal"). But without
    a window, for instance because the "-w" flag was used to avoid
    creating one. Furthermore this case applies if the terminal is
    recognized and fwin can do cursor control on it (that is always the
    case under windows but may not be so under Unix/Linux/MacOS, eg if
    the TERM variable is not properly set). In this case fwin tries to
    switch the keyboard to "raw" mode and do its own line editing.
    (^C ???)

(3) Either without fwin compiled in at all (that is probably no longer
    a supported configuration, but could perhaps arise in an embedded
    use), with terminal input or output not attached to a console (eg
    with file re-direction set up using the shell), with the terminal
    indirected for other reasons (running CSL at the end of a pipe, or
    the windows binary under the cygwin shell), or Unix/Linux with an
    un-recognised terminal type. In such cases CSL uses simple "cooked"
    IO and both local editing and ^C handling are up to the system.