There are several libraries like ncurses that assist in making command-line GUIs.
Simply put, how do they work?
My first thought was that ncurses intercepts all keyboard input, and draws each "frame" by outputting it line-by-line normally. Closer inspection, however, reveals that each new frame overwrites the previous one. How does it modify lines that have already been outputted? Furthermore, how does it handle color?
EDIT: The same question applies to anything with a "fancy" interface, like vim and emacs.
Text terminals have command sequences that do things like move the cursor to a particular position on the screen, insert characters, delete lines etc.
Each terminal type is different and has its own set of command sequences. ncurses has a databse (see terminfo for details)
Internally ncurses maintains 2 views of the screen: the current contents and what the screen should look like after the current pending changes are applied. Once the program requests a screen redraw, ncurses calculates an efficient way to update the screen to look like the desired view. The exact characters/command sequences output depend on what terminal type is in use.
curses (and ncurses, too, I think) works by moving the cursor around on the screen. There are control sequences to do such things. Take a look at the code again and you'll see them. These sequences are not ASCII control characters, they are strings starting with (umm...) ESC, maybe. Have a look here for a higher-level explanation.
Related
there is this annoying behavior in emacs which I don't know how to get rid of it.
lets say the current cursor position is on line 10 column 15.
now I need to quickly look up something far down the same buffer, I scroll down to that location and as I scroll down (or up) the cursor keeps moving and it loses its original location.
many people suggest to set a marker before scrolling but that is not a good solution, because you have to be always mindful of this fact before scrolling (which is impossible)
I know there should be a simple solution but I have not found it yet.
I'll appreciate your suggestions
As far as I know, Emacs doesn't allow you to scroll in such a way that your point disappears. I just took a quick look at xdisp.c and it looks like this is a fundamental assumption in the C code. This is different from some more recent editors (Sublime Text, VSCode etc).
However, the "many people" you mention actually have a reasonable point. If you're moving through the file by searching (C-s the-thing-im-looking-for) then Emacs will set a marker for you automatically.
I guess you could try adding a hook that set a marker at point whenever you scrolled? It wouldn't be trivial because you'd have to cope with things like not setting a load of markers through the file as your scroll dragged the cursor down. But my recommendation is probably to alter your workflow to match how Emacs wants to do things. In this case, it's probably a better approach than the modern editors it sounds like you're used to.
An option that might or might not be useful is scroll-preserve-screen-position. The description is somewhat hard to understand, but a net result is that if you mainly scroll using C-v/M-v, the point will visually stay at the same place on the screen (so if you do e.g. C-v C-v M-v M-v, the point will come back to its original position.
However, note that many commands do push a mark before they jump: isearch, end-of-buffer, imenu, xref-find-definition ... In all those cases, you can then press C-u C-SPC (the same command that you use to set the mark but called with a prefix argument) to pop the mark (concretely, jump to the last mark). If you need to jump back more than once, you can set the variable set-mark-command-repeat-pop to t, so that you only need to do C-u once and then repeatedly press C-SPC to pop more and more marks from the mark ring.
In general, there are better ways to navigate a buffer than scrolling in the wild; the cases where you do need to scroll, starting from "your current" point are (or should/could be ...) sufficiently rare that you know beforehand that you will be spending a possibly long time "looking around" in the buffer. It is then quite fast to set a mark, do your stuff somewhere else, and C-u <mash C-SPC as often as needed> until you get back to your initial point.
When running vim if I type : the input cursor goes to bottom row of the screen and I can type a command, then go back to the top of the screen. Arrow keys let me move around, all that jazz. In Golang using the fmt package how can I do this?
I think you're kind of confused. What fmt is essentially equivalent to are C's printf and scanf family of functions. The complexity of controlling the screen buffer is quite a bit more complex than just printing some stuff in a terminal output.
The behavior you're talking about is a result of vim's integration with the ncurses library (or something similar to it). Haven't ever used this, but here's a link to an ncurses wrapper in cgo, which you could probably use to do something like vim does.
I believe this is the realm of the ncurses library. I'm trying to avoid having to get down and dirty with it though.
I'm looking for a program that I can configure to run a command while performing terminal mouse reporting translation to keypresses.
This is for use with pagers like less.
For example the MouseTerm SIMBL plugin for Terminal.app does exactly this.
But iTerm2 does not. And I want it.
I think the answer may be as simple as directly remapping the codes.
It looks like there are escape codes to switch the terminal into and out of mouse-listening mode, and mouse click escape codes actually seem to include the character coordinates. I can look at them with Ctrl+V inside of Vim because I have told vim to turn on the mouse.
It looks like this:
Note ^[ denotes escape (you can type escape by typing ctrl+[)
left click: ^[[M !!
right click: ^[[M"!!
middle click: ^[[M!!!
scroll up: ^[[M`!!
scroll down: ^[[Ma!!
So that does match up with the mouse wheel button codes being 64 more than the mouse button ones according to documentation (I like this page).
Now that I'm armed with the knowledge of what codes I need to map to what I just need to find out how to get a layer that lets me filter the input.
This has apparently led me to an epiphany. I simply need a simple non-line-buffering program that listens for mouse escape codes and replaces them with key codes. Surely Perl Term::ReadKey will let me set raw mode and do this nearly trivial task.
This stuff is difficult. I've been making do by configuring Tmux to handle things.
I need to turn automatic margins off according the following statement from Screen's manual in my Mac
If your terminal is a "true"
auto-margin terminal (it doesn't allow
the last position on the screen
to be updated without scrolling the screen) consider using a version
of your terminal's termcap that
has automatic margins turned off.
How can you turn automatic margins off by your terminal's termcap?
Most terminal emulators, including the mac default terminal, are not "true auto-margin terminals" in the sense being discussed here - they emulate a vt100-series terminal, which had "smart" wraparound. You can check by running cat and typing to the end of the last line - after you type the last character, the cursor remains at the end of the line (highlighting the character you just typed) until you type another character.
The only consequence of a 'true auto-margin terminal' is that a character cannot be displayed in the lower right hand corner (though some programs are able to work around that by shifting a character into place with ich/ich1)
According to XTerm Control Sequences, this sequence should do what was asked:
CSI ? 7 l
That is,
printf '\033[?7l'
The 7 is documented as
Ps = 7 -> Wraparound Mode (DECAWM).
and the final character l (lowercase L) denotes this as a reset rather than a set control.
For whatever reason, the terminfo name for this is more obscure: "automatic margins". These terminfo capabilities deal with the feature (see terminfo(5)):
auto_right_margin am am terminal has auto‐
matic margins
enter_am_mode smam SA turn on automatic
margins
exit_am_mode rmam RA turn off automatic
margins
Interestingly, the vt100-nam terminal description in ncurses (which apparently no one uses) initializes the terminal to use automargins margins using this string:
rs2=\E>\E[?3l\E[?4l\E[?5l\E[?7h\E[?8h,
(the \E[?7h sets it), and asserts that the terminal does not use automatic margins by cancelling am. It also has the terminfo capabilities rmam and smam. So you could do this to prove that it works:
tput rmam
stty columns 999
ps -efwwwwwl
and (for the ordinary user) see the ps listing nicely truncated against the right margin of the terminal window.
The other variants vt220-nam and vt320-nam appear correct...
By the way, for Mac, you would use the terminfo names such as rmcup rather than the termcap RA, because OSX uses ncurses' tput (terminfo) rather than the BSD variant.
Further reading:
tput, reset - initialize a terminal or query terminfo
database
history section for tput
history section for tset
Occasionally someone asks about suppressing automargins because they suppose that terminals can pan/scroll left/right to show the information which was not wrapped to a new line. Terminals which do this are rare, and OSX Terminal is not one of those. It behaves like a subset of xterm, which itself emulates the series of DEC terminals vt52/vt100/vt220/etc. In this question, OP is concerned/confused about this paragraph from the screen manual:
If your terminal is a "true" auto-margin terminal (it doesn't allow the
last position on the screen to be updated without scrolling the screen)
consider using a version of your terminal's termcap that has automatic
margins turned off. This will ensure an accurate and optimal update of
the screen in all circumstances. Most terminals nowadays have "magic"
margins (automatic margins plus usable last column). This is the VT100
style type and perfectly suited for screen. If all you've got is a
"true" auto-margin terminal screen will be content to use it, but
updating a character put into the last position on the screen may not
be possible until the screen scrolls or the character is moved into a
safe position in some other way. This delay can be shortened by using a
terminal with insert-character capability.
That last position on the screen refers to the lower-right corner of the terminal. In the normal case, if your cursor is on the lower-right corner and you print a character, you would expect the display to scroll up by one line and show the character on the next line. Also (because terminals can be implemented in different ways), some could scroll up when you print a character in the last position. The VT100 does not do this. Not only does it not scroll up in that case, but it ignores non-printing characters while on the margin (see xterm FAQ That description of wrapping is odd, say more?). There is a terminfo flag xenl which is set to show when the terminal does this special behavior. About a third of the terminal descriptions in the terminal database have this flag. While most of those are for terminals which you likely will never encounter, keep in mind that the advice in the manual page was written back in an era when those other terminals were as likely to be found as a VT100-lookalike. The early change-history for screen is poor, but the text was in screen's second posting to Usenet in 1992. The initial posting in 1987 said something similar:
Screen
never writes in the last position of the screen, unless the boolean
capability LP is found in the termcap entry of the terminal.
Usually,
screen
cannot predict whether or not a particular terminal scrolls when
a character is written in the last column of the last line;
LP indicates that it is safe to write in this position.
Note that the LP capability is independent of am (automatic
margins); for certain terminals, such as the VT100, it is reasonable
to set am as well as LP in the corresponding termcap entry
(the VT100 does not move the cursor when a character is written in
the last column of each line).
The later wording reflects the fact that the terminfo system was prevalent, and the name LP was not termcap name chosen for corresponding with xenl (it is xn).
The point of all of this is that screen attempts to convert between programs writing to different terminal types and make them all appear like one type of terminal — which means that it tries to put text on the terminal's display in all of the locations. The lower-right corner is a problem because some terminals would scroll up, spoiling the attempt to write there. As a workaround, some terminals provided an alternative:
using a different mode (insert),
put the cursor on the next to last position of the display,
write characters to fill in, pushing a character into the last position, and
turn insert-mode off once it is done (otherwise a nuisance).
About two thirds of the descriptions in the terminal database have the capability to do this insert-mode (smir). That still was not perfect, but it certainly was worth mentioning in 1992. About a quarter implement a similar similar feature ich1. Some implement both (and vi could get confused by those, by trying to do both methods).
VT100-lookalikes provide a third way to write that last position; screen checks for and uses whatever is there.
If I understand you correctly you're looking to set the autowrap feature to NO using terminfo database. If so I believe you can use the -nam flag to turn it off - something like vt100-nam should do it. You can also check by looking at the man pages for terminfo.
If this solves your question, mark this up. (^_^) If not... well comment back and I'll check again for you. Cheers!
Update: There's also a shortcut that may apply to you to toggle the wrap off and on. Check out the shortcut sheet here. And additional information for Screen can be found here (search for wrap). You can also check here on how to use setterm (section 17.14 Changing the Terminal Settings). Also check here for examples of changing settings.
Good luck again. (^_^)
I'm fairly new at programming, but I've wondered how shell text editors such as vim, emacs, nano, etc are able to control the command-line window. I'm primarily a Windows programmer, so maybe it's different on *nix. As far as I know, it's only possible to print text to a console, and ask for input. How do text editors create a navigable, editable window in a command line environment?
By using libraries such as the following which, in turn, use escape character sequences
NAME
ncurses - CRT screen handling and optimization package
SYNOPSIS
#include
DESCRIPTION
The ncurses library routines give the user a terminal-independent
method of updating character screens with reasonable optimization. This
implementation is ‘‘new curses’’ (ncurses) and is the approved replacement
for 4.4BSD classic curses, which has been discontinued.
[...snip....]
The ncurses package supports: overall screen, window and pad
manipulation; output to windows and pads; reading terminal input; control
over terminal and curses input and output options; environment query
routines; color manipulation; use of soft label keys; terminfo capabilities;
and access to low-level terminal-manipulation routines.
Short answer: there are libraries for it (like curses, slang).
Longer answer: doing things like jumping around with the cursor or changing colors are done by printing special character sequences (called escape-secquences, because they start with the ESC character).
Learning about ncurses might be a good starting point.
There is an old protocol called vt100 based on a "VT100" terminal. It used codes starting with escape to control cursor position, color, clearing the screen, etc.
It's also how you get colored prompts.
Google VT100 or "terminal escape codes"
edit: I Googled it for you: http://www.termsys.demon.co.uk/vtansi.htm
You will also notice this if you type "edit" in a Windows command line console. This "feature" is not unique to unix-like systems, though the concepts for manipulating the windows console in that way are quite different to in unix.
On Unix systems, a console window emulates an ancient serial terminal (usually a VT100). You can print special control characters and escape sequences to move the cursor around, change colors, and do other special effects. There are libraries to help handle the details; ncurses is the most popular.
On Windows, the [Win32 Console API](http://msdn.microsoft.com/en-us/library/ms682073(VS.85%29.aspx) provides similar functionality, but in a rather different manner.
Type "c:\winnt\system32\edit" or "c:\windows\system32\edit" at the command line, and you'll be shown a command line text editor.
People are mostly right about the ESC character being used to control the command screen, but some older programs also write characters directly to the memory space used by the Windows Command Line screen.
In order to control the command line window, you used to have to write your own windowing forms, entry box, menus, etc. You'd also have to wrap all that up in a big loop for handling events.
More Windows command line specific, the app typically calls DOS or BIOS functions that do the same. Sometimes ANSI command code support is available, sometimes it isn't (depending on exact MS OS version and whether or not it's configured to load it).