When I press and hold a key, a first symbol is typed, then there is a little delay, and then other symbols are typed fast. Something like this:
Same happens in Terminal. Same happens in linux console (tty), even though this delay is smaller there.
I'm working on a console app in Python that uses curses, and it processes the presses of arrow keys and this delay is present there as well.
I want to get rid of this delay, so that when I press and hold a key - it would send signals with uniformly, without any specific delays after first (or whichever) symbol.
How can I do it? Should I use something from the arsenal of curses? Or tinker with some system-wide settings?
EDIT1: I think I've found one way. I can go to keyboard settings and set delay of autorepeat. But it changes it globally and only for my graphical interface. It doesn't change anything in linux console. So, I'm looking fo a way to do it in console as well, and also so it would affect only my app, not the whole system.
and a way for linux console: https://unix.stackexchange.com/questions/58651/adjusting-keyboard-sensitivity-in-a-command-line-terminal
but still looking for an app-only way.
Related
I spent several decades using Digital Equipment Corporation's VMS operating system, and one of the things I really miss is the terminal driver's 'read-with-prompt' functionality.
It would display the prompt and position the cursor for input, as you'd expect, but the prompt was immune to things like CTRL/U, CTRL/R, and CTRL/W. It was an attribute of the read operation, and every time the terminal driver was ready to read from the terminal with this option, it would show the prompt. The user couldn't erase it, so if it went off the screen he'd still know what was being requested.
This is one of the few things that I think VMS did better than U*X -- unless there's a Linuxish way of doing this.
So far I've never found it, but maybe I'm just not looking in the right place.
Is there a way on Linux to read from a tty with a persistent prompt?
Thanks!
This question is purely out of curiosity; there's no problem to be resolved.
Note: I'm using Konsole on CentOS 7.
When I SSH to a remote box and leave the session inactive for a while, it times out. As a workaround, I use less [some-file] to keep the session active.
Obviously the sessions still break when I suspend the VM at the end of the day.
The next day when I start a new SSH session, everything is normal except that some Konsole functionality doesn't work (namely, clearing scrollback, which I use a lot) for the same terminal window used for the SSH session.
However, after I less a file and quit, two things happen:
Konsole resumes working normally.
Whatever output was in the terminal before I used less is replaced with whatever output was there the previous day, before the session was broken by shutting down the VM I'm SSHing from.
Curiously, this happens for all ~4 concurrent terminals/sessions (each one having its output from the previous day restored). [edit: clarification: each of the ~4 terminals exhibits this behavior when I SSH/less in that particular terminal. Each one resumes its output from the day before. Doing this in one terminal/session is not affecting the other terminals/sessions]
I assume this would happen with any terminal app (e.g. vi, nano, etc.) with its own "gui" and isn't specific to less.
Seems like there's some caching going on. I assume quitting less (or vi, nano, etc.) triggers some sort of shell output restoration in general, but this particular manifestation seems somewhat odd.
Any idea what's going on?
The terminal feature described in the question the alternate screen feature (originally xterm, but copied/imitated by several other terminals including konsole). Depending on the terminal description, you may/may not use this feature.
less and most full-screen terminal programs such as vi send the escape sequences to switch to/from alternate screen if they're defined in the terminal description (i.e., TERM=xterm).
From the description, it sounds as if you're using different tabs in the same instance of konsole, and that it's remembering that your terminal was set to the alternate screen. konsole and some other programs attempt to save/restore "session" information when halted, so that probably seemed like a good thing to save/restore.
While in the alternate screen, terminal programs typically have little or no access to the scrollback region.
You can use tput to send the same escape sequence (without running less):
tput rmcup
(If the terminal description doesn't have a definition for that, it'll do nothing).
Further reading:
Why doesn't the screen clear when running vi?
ncurses app checks if terminal has been resized. If the size is less than 80x25, then blank the screen and show error message.
If the app has N windows, should all of them be removed with delwin(), or calling clear() would be enough? On the other hand, can already existing windows be later reused after clear() - to refresh and display contents if terminal size became satisfactory - or they should be recreated?
Clearing the windows sounds like the application's behavior rather than ncurses as such. The ncurses library (see resizeterm) will clear areas if the windows increase in size.
The best policy when resizing really depends on what you have inside the windows. ncurses is making reasonably safe changes, but since it has no information about your intention in making some things close on the screen, and others separated, all it can do is to attempt to resize windows so that their contents are preserved. The application can still clear them and start over again — as well as moving windows around on the screen.
It's your decision whether it is simpler to recreate the windows or reuse them.
As long as all of the rebuilding is done before the next repainting of the screen (e.g., with wrefresh), ncurses will make the updates with as little activity as it can.
Why does it take significantly more time to print multiple lines to the terminal rather than redirecting it to a file which seems to be almost instant ?
Primarily, terminals are just plain slow. For every update, they have to:
Parse and interpret any control codes.
Parse, interpret and render any escape codes.
Interpret and account for any multibyte and composed characters.
Update appropriate screen and scroll buffers.
Render this with appropriate fonts.
and possibly do all of the above over again if you use screen or tmux.
Meanwhile, for redirecting to a file, you just have to:
Dump data into RAM (for later writeback to storage).
This step is so minor that it doesn't even register on the terminal's checklist.
This is not something people optimize for, because the speed of your terminal is rarely an issue. The difference between terminals can be 50x (VGA vs fbcon back in the day), and you can time it with a simple time cat somebigfile.txt.
I know that the following statement is a way to query the current cursor position:
echo -en '\033[6n'
Does anyone know how to query the character under the cursor or populate a array with the contents of the current screen/window? I've searched through the ANSI terminal commands however a lot of these are pretty abstract and it doesn't look like they would do this properly. I also looked into doing it with the tcup command with no luck.
Thank you for your help.
An ANSI terminal is not really required to be able to tell you what is on the screen. You're supposed to remember that yourself, if you need the information. The popular ncurses library does that, for example, although it only allows you to export the screen to a file, and the fileformat is not documented. In any event, bash doesn't use ncurses, so it really doesn't know anything about the state of the console.
Most probably, the screen you are talking about is actually an artifact of some terminal emulation program like xterm. Those programs run in userspace, and rarely (if ever) have an external query interface. However, linux does have a console (actually, a number of emulated consoles, but using the display's console mode) and it maintains the display memory for those consoles. And furthermore, it provides an interface for reading the console memory, usually available as /dev/vcsN (for values of N between 0 and the number of virtual consoles linux was compiled with). /dev/vcs0 is the "current" console (the one which is visible).
Most linux distributions restrict access to /dev/vcsN, so if you want to play around with them you'll either need special privileges or you'll need to use root privileges to change the access permissions on the device files. (Ubuntu appears to provide rw access to users in group tty; check ls -l /dev/vcs0 to see how your system does it.) (And, of course, you'll need to find the console :-) Try CtlAlt1; CtlAlt7 will probably give you back your GUI.)
Once you've worked out the access issues, you could do something like cp /dev/vcs0 console_memory to take a look at it. What you'll find is that it is just a 2D array of characters with no newlines, and no indication of what the dimensions are. (You can get the dimensions with an ioctl or by looking at the environment variables $LINES and $COLUMNS.)
You could use /dev/vcsa0 instead; it has a slightly different format using two bytes per character in order to store display attributes (foreground and background colours, mostly) as well as the character. Also, the first four bytes of /dev/vcsaN are the screen dimensions and cursor position (one byte per coordinate), which will save you the work of querying the cursor position.
Note that the console does not support a full Unicode character set. In fact, it can only display 512 different glyphs at once. In order to maximize the available glyph space, Linux may reassign some codes to needed symbols, and this mapping is not part of the console memory. So the code extracted from console memory might not have an obvious mapping to a Unicode code, but it should work fine for standard ANSI characters.