I am writing my own lisp interpreter in C++ using emacs as editor and for debugging with gdb. I use termios and escape sequence, to have control about input, so that it is possible to edit a lisp-command in a terminal. My aim is, that my lisp-interpreter should also run in emacs with "M-x run-lisp" and in an ansi-terminal. The problem I have, when I use the debugger, emacs use his own dumb-terminal which don't work with escape-sequences, so debugging becomes difficulty.
I want to know, how it it possible to get control to the dumb-terminal or eterm, or if it is not possible, how can I temporarily control emacs from my program? Maybe if the dumb-terminal is started to run, that I can switch to another terminal like ansi-term in emacs without changing the .emacs file.
If I use the lisp-interpreter sbcl or gcl in emacs with
(setq inferior-lisp-program "sbcl");
or
(setq inferior-lisp-program "gcl");
in .emacs and invoke it in emacs with M-x run-lisp
it seems, that emacs use the dumb-terminal.
and sbcl it is able to edit a lisp-command like
* (* 3
4 )
also you can do this in gcl
> (+ 8
5
7
6
)
over any lines using arrow-keys, backspace and del to edit and Carriage Return evaluate the lisp-command only, until the round brackets "(" and ")" are correctly set.
If sbcl or gcl can do this, there must be a way to control the dumb-terminal of emacs, using arrow-keys, backspace and maybe changing the input after using Carriage-Return when the lisp-command is not finished.
I also recognised, that sbcl are not editible in ansi-terminals but in emacs dumb-terminal. When I experimented with this dumb-terminal, I was also able to edit a line, until Carriage-Return is pressed. After it is pressed, the input-buffer is empty. Maybe the solution is, if the line is after Carriage-Return not finished, I must find a way, to refill this buffer with the old information again. Maybe if I have success with it, I can edit the line until to the next Carriage-Return. But there is another problem! The unfinished line is printed at the next line position. It must be printed at his old position, where I started the input.
Now I can do this only in ansi-terminal with escape sequences and run into troubles during debugging in emacs.
If I want to force to use escape-sequences or ncurses, there I am looking for a way, temporarily without changing the .emacs-file to start another terminal in emacs. Especially if I am debugging. Maybe the dumb-terminal must be killed and an ansi-term-terminal begin to start. This is generally useful, if you debug code, which uses ncurses or escape-sequences in different terminal-programs.
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).
This used to work really well. I loved it. I showed everyone how cool it was. Now it's broke.
M-X gdb,
gdb -i=mi MYPROGRAMNAME,
set args,
run,
screen splits to show output,
C-X o to output screen,
C-X b to get to gdb commandline
BOOM, error message
Cannot switch buffers in a dedicated window.
I don't need the program output at this point and rarely do. I need to control gdb and see the source code but now I cannot use the program output screen to control gdb because it's a "dedicated window?". I have to split the program output screen into two tiny windows. Very sad. I need a drink.
Use M-x gud-gdb instead of M-x gdb. But it has drawbacks, e.g. you can't set breakpoints by clicking in the fringe. On the plus side, you can have several debugging sessions running in parallel.
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
What's the preferred practice for a compile-run cycle in emacs?
Previously, I used M-x compile (mapped to F12) with make as my compile command. Within the Makefile I had an entry which would run the program that was compiled. This worked fine when my programs were non-interactive, but the compilation buffer is non-interactive.
Of course I could open a shell and run the executable, but I'd like to automate the compile-run cycle as much as possible and I assume there must be a standard practice for this and I'm guessing my executing-from-the-makefile method is a kluge...
C-u F12 works, but I'm wondering if that's the best approach for doing this (and if so, how can I bind F12 to be equivalent to C-u M-x compile instead of just M-x compile?).
It can't get simpler than C-u M-x compile. You already have the Makefile task defined. So you're just asking how to map this to f12?
Try this:
(defun compile-interactive ()
(interactive)
(setq current-prefix-arg '(4))
(call-interactively 'compile))
(global-set-key (kbd "<f12>") 'compile-interactive)
You should also read the Interactive Options and Optional Arguments sections of the manual.
Problem A:
I start gdb in command line with "gdb test"
I press ctrl-x,ctrl-a before I do anything else
Then I set break point using "b main"
Then I start running the program using "r"
Till this point, if I press the Up arrow key the src window will not scroll. Instead, something will appear in my command window - "^[0A". If I try to refresh the screen with ctrl-l, "^L" is what appears in the command window.
I don't think this is supposed to happen. Under this situation I can't even quit tui mode with c-x,c-a ("^X^A" will appear instead). Am I doing something wrong? I realize this problem occurs so long as I use the "run" command inside the TUI interface. I can, however, use the run command in TUI if I start gdb with "gdb -tui"
Problem B
I can't see the output of my program in TUI mode. GDB's own output can be seen, but not that of the program being debugged. This occurs both when I enter TUI using ctrl-x,ctrl-a and when using -tui command-line option.
Is there any way to fix this?
I've read some TUI articles on the net and some people seem to use TUI "exclusively". I suppose TUI can work properly, it's just there's a set of rules that must be carefully followed?
EDIT: I use gnome-terminal in ubuntu 11.04
Run gdb with -tui option instead (https://bbs.archlinux.org/viewtopic.php?id=112660)
~/.inputrc was the culprit in GDB 7.7 because of:
set editing-mode vi
set keymap vi
If I remove those lines it works.
This seems to be mentioned at in the following bug report: https://sourceware.org/bugzilla/show_bug.cgi?id=15163
I have requested a workaround at https://sourceware.org/ml/gdb/2015-06/msg00009.html and Andrew Burgess replied that he had just submitted a well received patch to add:
tui enable
tui disable
so in future versions we should have commands as an alternative to the shortcuts.
But then I saw the light and moved from TUI to GDB Dashboard: https://github.com/cyrus-and/gdb-dashboard which is simply more powerful and less buggy. See also: How to highlight and color gdb output during interactive debugging?
Change your terminal to get rid of your first problem. I used to use gnome-terminal my self, but then changed to terminator. Some terminals don't support keys like Alt sometimes (used to experience this in vim with some Alt+something maps)
You can change forcus to another window by 'focus winName', in your case, use 'focus src'
got this from here
Not sure about your 2nd problem. Good luck!
I think you are looking for, "focus next." it switches you among (there can be more than two) the windows. I'm sure there is a short-cut for this too. Please note, this is almost the same answer as user1888039, so if you agree you should up-vote that answer.
Problem A:
Use Ctrl+X then press a to enter or exit TUI mode.
Or as you mentioned run gdb -tui
Problem B:
Note that your program print could be ran over by the (gdb) prompt. In other words, it is possible that your program prints but the " (gdb)" is printed over it after.
To easily check if this is indeed the case, try to print either a line longer than 6 characters or multiple lines each time.
You should see part of your print.