;;; -*- Mode: Lisp; Package: CCL; Coding: utf-8; -*-

(chapter "Questions and Answers"
  (defsection "How can I do nonblocking (aka \"unbuffered\" and \"raw\") IO?"
    (para #:|There's some code for manipulating TTY modes in
      "ccl:library;pty.lisp".|)
    (code-block #:|
? (require "PTY")

? (ccl::disable-tty-local-modes 0 #$ICANON)
T
      |)
    #:|will turn off "input canonicalization" on file descriptor
      0, which is at least part of what you need to do here.  This
      disables the #$ICANON mode, which tells the OS not to do any
      line-buffering or line-editing.  Of course, this only has any
      effect in situations where the OS ever does that, which means
      when stdin is a TTY or PTY.

If the #$ICANON mode is disabled, you can do things like:|
    (code-block "
? (progn (read-char) (read-char))
a
#\\a
      ")
    (para "(where the first READ-CHAR consumes the newline, which
      isn't really necessary to make the reader happy anymore.)  So,
      you can do:")
    (code-block "
? (read-char)
#\\Space
")
    (para "(where there's a space after the close-paren) without
      having to type a newline."))
  (defsection "I'm using the graphics demos. Why doesn't the menubar
      change?"
    "When you interact with text-only {CCL}, you're either
      in Terminal or in Emacs, running {CCL} as a subprocess.  When
      you load Cocoa or the graphical environment, the subprocess does
      some tricky things that turn it into a full-fledged Application,
      as far as the OS is concerned.

      So, it gets its own icon in the dock, and its own menubar,
      and so on.  It can be confusing, because standard input and
      output will still be connected to Terminal or Emacs, so you can
      still type commands to {CCL} from there.  To see the menubar
      you loaded, or the windows you opened, just click on the {CCL}
      icon in the dock.")
  (defsection "I'm using Slime and Cocoa. Why doesn't *standard-output*
      seem to work? "
    "This comes up if you're using the Slime interface
      to run {CCL} under Emacs, and you are doing Cocoa programming
      which involves printing to *standard-output*.  It seems as
      though the output goes nowhere; no error is reported, but it
      doesn't appear in the *slime-repl* buffer.

      For the most part, this is only relevant when you are
      trying to insert debug code into your event handlers.  The SLIME
      listener runs in a thread where the standard stream variables
      (like {code *STANDARD-OUTPUT* and} and
      {code *TERMINAL-IO*} are bound to the stream used to
      communicate with Emacs; the Cocoa event thread has its own
      bindings of these standard stream variables, and output to these
      streams goes to the *inferior-lisp* buffer instead.  Look for it
      there."))