clisp-devel

Feature Requests item #1339718, was opened at 2005-10-27 13:11
Message generated for change (Comment added) made by sds
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: Sam Steingold (sds)
Date: 2010-10-05 16: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 09: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-01 20: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 16: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 13: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

Feature Requests item #1339718, was opened at 2005-10-27 13:11
Message generated for change (Comment added) made by sds
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: Sam Steingold (sds)
Date: 2010-10-06 09:44
Message:
<http://article.gmane.org/gmane.lisp.clisp.devel/22093&gt;
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2010-10-05 16: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 09: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-01 20: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 16: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 13: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

Feature Requests item #1339718, was opened at 2005-10-28 03:11
Message generated for change (Comment added) made by ampy
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: Arseny Slobodyuk (ampy)
Date: 2010-10-08 10: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 23:44
Message:
<http://article.gmane.org/gmane.lisp.clisp.devel/22093&gt;
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2010-10-06 06: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-03 00: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 11: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-02 07: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-28 03: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

Feature Requests item #1339718, was opened at 2005-10-27 13:11
Message generated for change (Comment added) made by sds
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: Sam Steingold (sds)
Date: 2010-10-08 10: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-07 20: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 09:44
Message:
<http://article.gmane.org/gmane.lisp.clisp.devel/22093&gt;
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2010-10-05 16: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 09: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-01 20: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 16: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 13: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

Feature Requests item #1339718, was opened at 2005-10-28 03:11
Message generated for change (Comment added) made by ampy
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: Arseny Slobodyuk (ampy)
Date: 2010-10-12 10: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-09 00: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 10: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 23:44
Message:
<http://article.gmane.org/gmane.lisp.clisp.devel/22093&gt;
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2010-10-06 06: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-03 00: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 11: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-02 07: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-28 03: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

Feature Requests item #1339718, was opened at 2005-10-28 03:11
Message generated for change (Comment added) made by ampy
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: Arseny Slobodyuk (ampy)
Date: 2010-10-12 10: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 10: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-09 00: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 10: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 23:44
Message:
<http://article.gmane.org/gmane.lisp.clisp.devel/22093&gt;
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2010-10-06 06: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-03 00: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 11: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-02 07: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-28 03: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

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&gt;
----------------------------------------------------------------------
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

Feature Requests item #1339718, was opened at 2005-10-27 13:11
Message generated for change (Comment added) made by sds
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: Sam Steingold (sds)
Date: 2010-10-12 15:48
Message:
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
----------------------------------------------------------------------
Comment By: edgar-rft (edgar-rft)
Date: 2010-10-12 01: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-11 20: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-11 20: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 10: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-07 20: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 09:44
Message:
<http://article.gmane.org/gmane.lisp.clisp.devel/22093&gt;
----------------------------------------------------------------------
Comment By: Sam Steingold (sds)
Date: 2010-10-05 16: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 09: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-01 20: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 16: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 13: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

Community

Help

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

CountryState

JavaScript is required for this form.

I agree to receive quotes, newsletters and other information from sourceforge.net and its partners regarding IT services and products. I understand that I can withdraw my consent at any time. Please refer to our Privacy Policy or Contact Us for more details