Talk:Terminal control/Positional read

From Rosetta Code

Very Difficult

Just so that people know up front before trying to implement this, it is exceptionally difficult to do because “read displayed character” (whether at the current or a specific location) is not an operation that forms part of the standard set of operations. –Donal Fellows 13:01, 17 October 2010 (UTC)

Or you can just not support vt100 terminals (and I am pretty sure that the basic implementations for these terminal control tasks do not support vt100 terminals, and I wonder about some of the other implementations also -- none really give any clues about hardware support).
But I also wonder about the utility of "terminal control". For most applications, on modern computers, you can do a complete update of a terminal's screen with about 2k of data. These terminal control artifacts date back to the age when 2k of data was prohibitively bulky and slow. Nowadays, except for interactive gaming, just sending a full screen replacement should be more than adequate for most tasks. And, nowadays, if I was writing an interactive game, I would much rather be working with OpenGL than with a fixed-width character based terminal.
Meanwhile, for this task, if you have a local data structure representing how things are supposed to be, that should be adequate for most tasks. (If you have a system where the display can change due to outside factors, you are not really working with a normal terminal.)
After thinking about the hardware support issues (or lack-of-support issues), and the utility issues (or lack-of-utility issues), I have decided to stay out of this category of tasks. I think employing these concepts in a modern program would almost always be a mistake. --Rdm 14:53, 18 October 2010 (UTC)
On the subject of utility of terminal control...Over a DSL link, I can have latency/screen draw issues when running irssi over a compressed SSH tunnel to a PuTTY window with over 7000 character cells visible. On a more general note; might I suggest folks try tying into a curses library, so we can get some more code examples in here? --Michael Mol 01:38, 19 October 2010 (UTC)
Ok, but I think the big reason irssi uses a terminal, rather than a windowing environment (gtk or whatever), for display purposes, is backwards compatability? If the issue is proxying, you can use socks over your ssh connection. --Rdm 12:59, 19 October 2010 (UTC)
I use a terminal-mode IRC client (as opposed to a GUI one such as XChat) for detachable sessions, speed and portability. While detachable, VNC, nx and RDP would all be slower than a terminal over SSH (I contend this would be true of any flexible remote console involving raster imagery), and I can find a terminal emulator for whatever platform I'm using. --Michael Mol 13:57, 19 October 2010 (UTC)
Ok, but some (perhaps most) of the current terminal control implementations, here, on Rosetta, do not support that kind of terminal. But also, if I were building the kind of application you are now describing, from scratch, and I wanted to support use by a lot of people, I think I would implement it to support ajaxy web browsers (mostly on localhost), and mobile phones. --Rdm 15:47, 19 October 2010 (UTC)