add setfable accessors:
Logged In: YES
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)
Logged In: YES
I have some code (actually quite old, but still in use) that
scrolling subwindow part. I haven't tried it with screen in
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
(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
Logged In: YES
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
for unix you can use 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.
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.
- 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.
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.
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.
(#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_YA :BITS 0 :FONT 0 :KEY NIL)
(#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_ZE :BITS 0 :FONT 0 :KEY NIL)
(#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_SHCHA :BITS 0 :FONT 0 :KEY NIL)
(#S(SYSTEM::INPUT-CHARACTER :CHAR #\CYRILLIC_SMALL_LETTER_SHA :BITS 0 :FONT 0 :KEY NIL)
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.
> 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
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