#23 screen & keyboard interaction

open
nobody
UI (5)
5
2010-10-05
2005-10-27
Sam Steingold
No

add setfable accessors:
(SCREEN:TEXT-COLOR window-screen)
(SCREEN:BACKGROUND-COLOR window-screen)

Discussion

  • Sam Steingold
    Sam Steingold
    2005-10-27

    Logged In: YES
    user_id=5735

    another nice thing is being able to split the screen
    so that scrolling in different parts is done independently.
    I remember being able to do somehting like that
    with turbo pascal 5.5 15 years ago. :-)
    (this would make it necessary to introduce a _tree_ of
    screen streams - maybe too hairy)

     
  • Sam Steingold
    Sam Steingold
    2005-10-27

    • summary: screen: set text/ng color --> screen: set text/bg color
     
  • Don Cohen
    Don Cohen
    2005-11-01

    Logged In: YES
    user_id=8842

    I have some code (actually quite old, but still in use) that
    does the
    scrolling subwindow part. I haven't tried it with screen in
    some time
    so it might not quite work there. I gave up on screen a
    long time ago
    and use ansi terminal emulation instead. It turns out this
    is not so
    easy to get these days in win-xp, but pscp does it, so one
    way to use
    this stuff from win-xp is to ssh to a machine with an ssh
    server.
    (Anyone know where to get an ssh server for win-xp?)
    Ansi terminal emulation is also a good way to control colors.
    I can offer code for that too.
    I've put the window code at
    http://don-eve.dyndns.org/windows.lsp

     
  • Logged In: YES
    user_id=553883

    I thought about it 1000 times and since I don't know how to
    use colors on UNIX, didn't implemented. Tree of streams is
    too cool, on windows there is a system function to scroll
    console region and it even is used in current SCREEN code
    to scroll whole screen. Having lisp interface to it one can build
    his own nice libraries, using generic streams for the nice
    example given above. Again, threre is a question how to
    make this scroll function portable. And how to name colors
    portably, on windows there's Red, Green, Blue w/without
    intensity for text and same R, G, B w/without blinking for
    background.

     
  • Sam Steingold
    Sam Steingold
    2005-11-02

    Logged In: YES
    user_id=5735

    for unix you can use ncurses
    http://www.google.com/search?q=ncurses
    we already require them for readline.

    tree of sreams is not really necessary:
    just add x-offset/y-offset/width/height arguments
    to window-stream creation.

     
  • Sam Steingold
    Sam Steingold
    2010-10-05

    in general, clisp screen/keyboard interaction facilities are ancient and probably not used too much (if at all) by the users.
    this is obvious from the fact that (read-char *keyboard-input*) returns a SYS::INPUT-CHARACTER whose accessors are not exported.
    Proposal:
    - move screen & keyboard streams from stream.d into a separate module (window-stream and keyboard stream do not have to be lisp streams, and if you think they have to, you can use gray streams) together with xcharin.lisp.
    - make keyboard input recognize _all_ keyboard events (e.g., now f1 is recognized by ctrl-f1 is not).
    - resurrect the ancient src/editor.lsp (?) in the same module(?); make it more emacs-compatible.

     
  • Sam Steingold
    Sam Steingold
    2010-10-05

    • labels: --> UI
    • assigned_to: ampy --> nobody
    • summary: screen: set text/bg color --> screen & keyboard interaction
     
  • Sam Steingold
    Sam Steingold
    2010-10-06

    <http://article.gmane.org/gmane.lisp.clisp.devel/22093>

     
  • The fact that INPUT-CHARACTER accessors aren't exported wasn't important to me. I just used :: (checked my code).
    SCREEN doesn't constitute much of the stream code, is the work amount needed for rewriting it as a module justified?
    Next, it would be nicer when extra I/O features are integrated (at least, correctly interoperate) with basic ones (used by system (but the system could use extra features too, I mean IDE)). I strongly believe that stream code have to distinguish between terminal handle and file handle (use isatty), this is the first step to console window streams (do not use isatty, but have separate stream object type instead which is a subtype of terminal stream). It is not so for now, but probably it should be taken that way. On Windows, console handle is the standard input/output handle that is switched in special mode.
    Finally, what are the plans about GUI? I believe this should be taken in mind, that with GUI SCREEN probably should have the same programmer's interface, but use another OS calls. By GUI I mean just 'not console' - it may have the same 80x25 characters. I personally love the console (especially with windows, colors etc) - it's easy to program, it's lightweight, but I can't say many share my feelings.

     
  • Sam Steingold
    Sam Steingold
    2010-10-08

    1. indeed, xcharin.lisp exports char-key et al which makes it less necessary to use "::"
    2. I think the right way for gui is either the gtk2 module or embedding clisp in vim (like vim already embeds perl/python/ruby). I think console and window systems are too different to be handled by the same API.
    3. as summarized by edgar and in bug#1308473, read-char on *ikeyboard-input* is not compliant.

    the bottom line:
    1. keyboard/screen kruft sucks and needs TLC ("tender loving care" - i.e., lots of work).
    2. they do not belong in clisp core; turning them into a module should not be too hard; however, ultimately the decision is largely up to the prospective maintainer of the facility.
    3. it is not obvious that they should actually be lisp streams, but if the prospective maintainer wants them to, he can use gray streams or rfe#1834189 to make them such.

     
  • The problem with (read-char ext:*keyboard-input*) and unicode characters (two codes are returned for the single key pressed) is system-dependent, there is no such problem on Windows (Clisp ver 2.49 release). So it's a bug. No system info was supplied by Edgar, I just hope it's not C-64.

    On Win:
    (#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_YA :BITS 0 :FONT 0 :KEY NIL)
    #\CYRILLIC_SMALL_LETTER_YA)
    (#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_ZE :BITS 0 :FONT 0 :KEY NIL)
    #\CYRILLIC_SMALL_LETTER_ZE)
    (#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_SHCHA :BITS 0 :FONT 0 :KEY NIL)
    #\CYRILLIC_SMALL_LETTER_SHCHA)
    (#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_SHA :BITS 0 :FONT 0 :KEY NIL)
    #\CYRILLIC_SMALL_LETTER_SHA)

     
  • Forgot to mention that Control-F1 and Control-arrows and Alt-arrows are ok too on Windows. Control/Alt are encoded in INPUT-CHARACTER-BITS.

     
  • edgar-rft
    edgar-rft
    2010-10-12

    > No system info was supplied by Edgar, I just hope it's not C-64.

    Sorry, the *keyboard-input* problems appeared on Debian Lenny (Linux),
    Ubuntu 10.4 (Linux) and OpenSuse Linux (exact version not known yet).

    The only Windows system I have available at home is a Win2000 machine,
    but I do not think that in 2010 anybody is interested in Win2k bugs.

    But I know a few people who have still-working C-64 machines... :)

    There are two terminal emulators in "src/stream.d", one for Windows and
    one for Unix/Linux, so it looks as if the *keyboard-input* problems are
    Unix/Linux specific.

    - edgar

     
  • Sam Steingold
    Sam Steingold
    2010-10-12

    ok, so I am awaiting stream.d patches from edgar :-)
    meanwhile, you can play with the old clisp screen editor from the 1990-ies in modules/ediitor
    unless someone wants to work on it, it will be removed before the next release