When using vim in the terminal, it essentially blanks out the terminal's window and gives you a new one to start coding in, yet when you exit vim the terminal's previous output is still listed. How do you clear the terminal so that it only outputs your program's output, but returns to its normal state once the process has ended? (In linux, fedora)
At the low level, you send the terminal program a set of control characters that tell it what to do. This can be a bit too complex to to manage manually.
So instead, you might want to look at a console library like ncurses, which can manage all this complexity for you.
With respect specifically to the previous content magically appearing after the program exits, that's actually an xterm feature which vim is taking advantage of and which most modern terminals support. It's called "alternate screen" or simply "altscreen". Essentially you tell the terminal program "Ok, now switch to a completely new screen, we'll come back to the other one later".
The command to switch to the alternate screen is typically \E[?47h, while the command to switch back is \E[?47l For fun try this:
echo -e "\033[?47h"
and then to switch back:
echo -e "\033[?47l"
Or for a more more complete solution which relies a bit less on your shell to set things right (these are the sequences vim normally uses):
echo -e "\0337\033[?47h" # Save cursor position & switch to alternate screen
# do whatever
#Clear alternate screen, switch back to primary, restore cursor
echo -e "\033[2J\033[?47l\0338"
You can type "clear", or add a system command in your program to call "clear". Also, if you're not aware, you can run system commands from inside vim, so you dont have to exit and type clear. You can compile and run your programs from inside vim as well, for example ->
:!clear
:!make
:!./programName
Also, I never use this technique, but I believe you can have vim call a new terminal by using :set terminal
Related
I mainly use vim as an editor for C/C++ programming. Unfortunately, I'm not quite satisfied with the way my build process works. I know that it's possible to type in (or map to a key) :make to run the make process. I dislike the way this command works, though, as it runs the build process in the same terminal window without proper highlighting. I therefore usually run the make command in another window on my second monitor so that I have both proper highlighting and can look at the build errors the compiler shows me in one window while scrolling through the source code in my main vim window. This is also quite tedious because it requires me to change focus to another window, then type in the make command.
Now, my question is as follows: Is it possible to make vim run the make command in this other window without having to change focus? This way, I could just map the "build in other window" command to some key in vim and could achieve all of this with a single key press.
My system is Manjaro Linux with i3 as DWM.
(I was unsure wether to post this on the unix forum or here, please forgive me if this is the wrong forum.)
You can achieve this by using xdotool and i3 config-file mappings. These mappings require that the last command executed in the terminal of the window rightwards was make.
set $prevR xdotool key --clearmodifiers --delay 2 super+l ctrl+p Return super+h
set $prevRclr xdotool key --clearmodifiers --delay 2 super+l ctrl+l ctrl+p Return super+h
And then map those commands to your preferred keys, for example:
bindsym --release Mod4+Shift+e exec --no-startup-id $prevR
bindsym --release Mod4+e exec --no-startup-id $prevRclr
The first mapping runs the previous command on the window right to the current one.
The second one does the same while first clearing the terminal. You need to substitute the super+[lh] with your own mappings that change the focus to your alternate monitor.
You may also have to increase the --delay to accommodate for the lag of changing windows.
If you also want to populate the quickfix list, you have to separately run :make in vim. By doing this you can both see the errors properly colored and formatted on your alternate monitor and be able to jump to the next error in vim with :cnext, :cprevious (see :help quickfix.txt for more info).
If you want to apply your make command to an arbitrary window, have a look at the
'WINDOW_STACK' section of the man page xdotool(1).
We've been struggling for a while now to understand the keyboard scancode behavior in Linux.
When we open a normal bash shell, the arrow keys works as expected: UP shows the previous item in the history etc. However when you spawn a process, arrows does not work as expected anymore. For example, UP prints ^[[A instead of the previous command.
To demonstrate this, do something like:
bash$ ping www.google.com
Now, press UP or DOWN etc. and you will see the wrongly mapped key codes while the process is running. However, when you terminate the process the arrow keys will work again.
We've tested it on CentOs, Ubuntu, Mac and even in different shells (bash, sh, zsh) and the same happens everywhere. I've also tried different keyboard modes using kbd_mode where we tested with RAW and XLATE modes.
The closest thing I could see while searching for answers were IPython users have experienced the same behavior when IPython was not build against readline. However, this is not related to our case as far as I can see.
We are developing a C++ Tcl based console application which uses cin and cout to communicate with, and get input from the user. We are having issues with the arrow keys when we try to access the history of previously entered commands. This is a major issue for us as 99% of people expects the arrow characters to just work.
Any ideas on how we could overcome this would be much appreciated.
You must set the terminal into raw mode to get the scan codes and handle them (that is: disable ICANON, you want the non-canonical mode). You probably also want to disable ECHO (so that it doesn't print your input on the terminal).
That is what readline or linenoise are doing. See here for some code. Esp. see the function linenoiseEnableRawMode. Some other simple sample Python code is here where I have written a simple console media player which checks for the keypresses left ("\x1b[D") and right ("\x1b[C").
The relevant calls are to tcgetattr (to get the current terminal state and modify that state struct to get into raw mode and enable some other useful behavior stuff) and tcsetattr (to set the state).
readline, libedit or linenoise are some libraries which do all that work for you and provide you with history, autocompletion, etc.
At the end, you must restore back the old state, otherwise you get the behavior you are describing in your shell.
I want to make a version of cin that works in a graphics display window (it's SDL, but I don't think that matters here): that is, when you type, the characters echo into that window rather than the console window. The solution should be cross-platform.
I have this page to tell me how to get characters NOT to echo to the console window: Reading a password from std::cin
...but what I don't know how to do is to make the characters echo on the new graphics display window.
One thing I could do is intercept keyboard events, and if one happens, print the character. But this wouldn't perfectly echo the actual behavior of the istream buffer, because of repeating keys, backspace, enter, tab, and also the real behavior of cin in that if you are typing before C++ gets to the cin, it will put that stuff you typed on the screen at that point.
I think this echoing is done inside the call to _read (read in the Unix world), and that I'm not sure how to access.
TIA.
The behaviors you're talking about are not done by cin nor read() syscall; buffering and processing of special character is done by the terminal emulator and the shell.
You do need to intercept key events and implement these yourself. Alternatively, some terminal emulators (e.g. VTE widget in Gnome) were designed so they can be embedded into another program. You might want to look at that option.
Considering your application is running in a window you shouldn't read input from the console . It's probably possible but you'll have to switch to the terminal window from where you started the window each time you want to input text. If you take this route you need to disable tty echo: http://man7.org/tlpi/code/online/dist/tty/no_echo.c.html (for Linux). Check out http://www.cplusplus.com/forum/general/12256/ for some solutions for Windows too. I don't think there is a solution that works for both so you'll need to bury some #ifdef's in some utility functions.
Since you're using SDL you should probably use SDL's input functions.
Check out http://www.libsdl.org/docs/html/guideinputkeyboard.html
And, more specific to your needs: http://wiki.libsdl.org/moin.fcg/Tutorials/TextInput
I was just debugging a program in gdb and somehow I found a new feature I've never seen or even heard of before, a split view where I can see and browse the code in addition to giving commands:
What is this? What did I do, or, more specifically, how can I get this split-screen mode again? Is there a name for this mode, or somewhere I can read about how to use it?
It's called the TUI (no kidding). Start for example with gdbtui or gdb -tui ...
Please also see this answer by Ciro Santilli. It wasn't available in 2012 to the best of my knowledge, but definitely worth a look.
You can trigger it dynamically by push ctrl+x and ctrl+a.
There are two variants of it.
to only see code Press
Press CTRL X together and then 1
To see both source and assembly
Press 'CTRL' 'X' together and then '2'
http://www.cs.fsu.edu/~baker/ada/gnat/html/gdb_23.html
A screen shot of the view with code and assembly.
Also check out this amazing Github project.
GDB Dashboard
https://github.com/cyrus-and/gdb-dashboard
GDB dashboard uses the official GDB Python API and prints the information that you want when GDB stops e.g. after a next, like the native display command.
Vs TUI:
more robust, as it just prints to stdout instead of putting the shell on a more magic curses state, e.g.:
vi mode in .inputrc causes problems: https://superuser.com/questions/180512/how-to-turn-off-gdb-tui/927728#927728
program stdout / stderr breaks your interface: GDB in TUI mode: how to deal with stderr's interaction with the ui
highly configurable from Python: you can select what you want to output and how big each section is depending on what you are debugging.
The most useful views are already implemented: source, assembly, registers, stack, memory, threads, expressions... but it should be easy to extend it with any information that is exposed on the GDB Python API.
TUI only allows showing two of source, assembly and registers and that is it. Unless you want to modify it's C source code of course ;-)
I believe that GDB should ship with a setup like that out of the box and turned on by default, it would attract much more users that way.
Oh, and the main developer, Andrea Cardaci, has been very responsive and awesome. Big kudos.
See also: How to highlight and color gdb output during interactive debugging?
You can also start it from the gdb shell using the command "-" (dash). Not sure how to dynamically turn it off though.
Type layout as a command in gdb and the split window will be shown.
When GDB is in the standard mode, using win will automatically switch in the TUI mode.
Other command for TUI mode:
info win
List and give the size of all displayed windows.
focus next | prev | src | asm | regs | split
Set the focus to the named window. This command allows to change the active window so that scrolling keys can be affected to another window.
Read here form more help.
There is also interface tool for GDB called cgdb. Even with some color highlighting.
"ESC" to switch to code view, "i" to switch back to gdb
tui mode was clearly inspired by emacs -- I discovered it by accident when I hit ^X-o, which switches among split windows in emacs -- I sometimes hit that absent-mindedly when what I should be doing is switching to a different program. Anyway, that leads to another feature not mentioned yet, that you can move the cursor from the code window (where you can scroll) to the command line, or vice versa, with ^X-o.
I've just installed Pyclewn. It works and shows variables and etc. But it doesn't show my program's output and when my program wants to input something, it doesn't do anything(I can write ":C run output" and it works. but not with standard I/O.
There was something in its documentation: http://pyclewn.sourceforge.net/_static/pyclewn.html
But I didn't understand what it says.
P.S: I've done that. Now I want to map for example to run those commands. but because the "nn" in /dev/pts/nn may vary, I should manually enter the number(see it from the xterm opened). I also have another problem when I map a key to a sequence of gdb commands, it says gdb is busy, I can add ":sleep 100m" between commands and the problem will be soved. but in the documentation it says that I should enable async option. but when I run pyclewn from vim with :Pyclewn command I don't know how to enable the async option.
You should use inferior_tty.py to create a terminal to be used with the program being debugged.
Abridged summary (most relevant bits only) from the FAQ:
:Cshell setsid xterm -e inferior_tty.py &
Determine what the name of the tty to be used is from this newly spawned window, then:
:Cset inferior-tty /dev/pts/nn
Or just start pyclewn from a terminal and it will automatically grab that terminal for input and output.
E.g:
pyclewn -c "main.cc other.h other.cc"