[ clisp-Feature Requests-1339718 ] screen & keyboard interaction

SourceForge Headquarters 1320 Columbia Street Suite 310 San Diego, CA 92101 +1 (858) 422-6466

Feature Requests item #1339718, was opened at 2005-10-27 19:11
Message generated for change (Comment added) made by edgar-rft
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=1339718&group_id=1355

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: UI
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Sam Steingold (sds)
Assigned to: Nobody/Anonymous (nobody)
Summary: screen & keyboard interaction

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

----------------------------------------------------------------------

Comment By: edgar-rft (edgar-rft)
Date: 2010-10-12 07:42

Message:
> 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

----------------------------------------------------------------------

Comment By: Arseny Slobodyuk (ampy)
Date: 2010-10-12 02:42

Message:
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.

----------------------------------------------------------------------

Comment By: Arseny Slobodyuk (ampy)
Date: 2010-10-12 02:15

Message:
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)

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2010-10-08 16:06

Message:
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.

----------------------------------------------------------------------

Comment By: Arseny Slobodyuk (ampy)
Date: 2010-10-08 02:10

Message:
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.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2010-10-06 15:44

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

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2010-10-05 22:46

Message:
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.

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-11-02 15:46

Message:
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.

----------------------------------------------------------------------

Comment By: Arseny Slobodyuk (ampy)
Date: 2005-11-02 02:06

Message:
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. 

----------------------------------------------------------------------

Comment By: Don Cohen (donc)
Date: 2005-11-01 22:52

Message:
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

----------------------------------------------------------------------

Comment By: Sam Steingold (sds)
Date: 2005-10-27 19:32

Message:
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)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=351355&aid=1339718&group_id=1355