I use gdb version 7.0 for debugging from emacs. The gdb when launched from emacs behaves slighlty differently compared with one launched from the shell. The points of differences are :-
gdb prompt, when launched from emacs doesn't recogonize the files in the current directory (from which the gdb session is launched.) This very cumbersome as when you run the application through gdb (using run), you have to give the full absolute path of the file. This is not the case when you launch the application through gdb from shell.
The arrow keys (that give the most recent commands typed on the gdb prompt), doesn't work for gdb launched from emacs. Instead, it moves the scroll up and down in the emacs gdb command prompt. Am I doing anything wrong here.. ?
Thanks and regards
since you are in a buffer, up and down move up and down in the buffer. most of the emacs shell-like buffers access the command history using "C-up" and "C-down".
Related
I can open a single file with Emacs, no problem. But I'm used to Emacs on Linux, where typing emacs test.cpp & would open a new Emacs frame, leaving the terminal free. On OS X, however, when I try to open a new frame with emacs test.cpp &, the terminal shows a process was created but the window fails to pop up. If I push Ctrl+C, the terminal shows "Stopped", but I see the process is still running because I can see it in the task monitor.
How to solve this problem? Thanks!
The issue here is that the command emacs on Linux is generally just the Emacs binary itself, which opens a new frame (that's Emacs-speak for X11 or other GUI window) unless you specify -nw on the command line; in contrast, the emacs command provided by Homebrew is a shell script that calls /usr/local/Cellar/emacs/24.3/Emacs.app/Contents/MacOS/Emacs -nw "$#" (substituting the version installed for 24.3). So the Homebrew version launches as a terminal app.
You can make a shell script that just runs /usr/local/Cellar/emacs/24.3/Emacs.app/Contents/MacOS/Emacs "$#", and it would behave somewhat as you expect, except that you would be launching a brand-new instance of the Mac app, which would cause an additional Emacs icon to appear on the Dock. Such a thing isn't considered "Mac-like," but it's not the end of the world.
An alternate solution, which is used a lot across different operating systems, is to make one Emacs process a server and then use emacsclient to open files from the command line. Emacsclient can open files in the current terminal, a new frame (GUI window), or an existing instance of Emacs. For an instance of Emacs to run as a server just requires that you run M-x server-start within it, or put (server-start) inside your init file (~/.emacs or ~/.emacs.d/init.el).
My Emacs config has this snippet, which starts server mode automatically when I launch the GUI app:
(when (display-graphic-p)
(server-start))
Then, once Emacs is running (you can make it autostart upon login in System Preferences > Users & Groups > Login Items), type emacsclient -nw test.cpp to open the file in the terminal, or emacsclient test.cpp & to open it in an existing frame, or emacsclient -c test.cpp & to open a new frame. (Note that if you open it in an existing frame, you use C-x # to close the buffer without closing the frame, as opposed to C-x C-c.)
Note that the terminal emacsclient command I gave just now didn't use & but the GUI ones did. & at the end of a command line puts the process in the background, meaning it's not monopolizing your terminal. For whatever reason (probably because it wouldn't be sensible to have a full-screen terminal app running in the background), when you invoke the terminal version of Emacs with &, it just suspends itself. The same thing would happen if you pressed C-z within Emacs. To get it back into the foreground, type fg (actually you can have multiple background processes, in which case fg would just pick the most recent one unless you specified a job specifier; see bash's man page (man bash) and search for JOB CONTROL if you're interested in the details).
My OS is OSX 10.9.4, and I'm using gdb 7.7.1.
I can open gdb in shell mode in emacs.
but cannot open gdb using M-x gdb. Emacs just says "No such file or directory, gdb". Why does this happen? Do I need to configure the M-x command?
Probably PATH is set differently in the shell and in Emacs. You can get around that by specifying the path explicitly in M-x gdb.
In the shell, type which gdb, and note what it prints, something like /foo/bar/gdb.
Then, type M-x gdb. The minibuffer asks for Run gdb (like this):, and the default value is gdb -i=mi. Edit the command line in the minibuffer, replacing the initial gdb with the result of which gdb.
If that works, you can customize gud-gdb-command-line and set the correct path once and forever.
I am coding with Go 1.2 on Ubuntu 12.04 LTS machine - using LiteIDE (very pleased with it).
I downloaded and installed the go termbox package - built the demo keyboard.go - built fine.
But when I run from LiteIDE, I get this panic - same happens with all the termbox demos:
panic: open /dev/tty: no such device or address
Any clues would be helpful....
OK, that's completely reasonable: interactive terminal applications require, well, terminal to be available. Terminals may be real—hardware—or virtual (like Linux virtual terminals you see on a typical x86 box when you hit Ctrl-Alt-F1) or emulated (like those provided by xterm, rxvt, GNOME Terminal and a ton of others).
Contrary to Windows, in which running a program of type "console" forces a console window to be created and an application attached to it, on POSIX systems there's no "types" of applications, and if an aplication wants a real terminal available for its I/O it performs a special check for this, and if that fails, the application signals an error and quits1. Very few folks have access to real hardware terminals these days so most of the time emulation is used, and then we talk about the so-called pseudo terminals. Linux virtual terminals and GUI terminal emulators and terminal console multiplexors like screen and tmux—all of them allocate pseudo terminals for running programs they control.
So basically you have these options:
Find a setting in your IDE which makes it allocate a pseudo-terminal when running your program. Some programs are able to do that by embedding a terminal emulator into their UI or by running it explicitly.
Teach your IDE to run your program in a terminal emulator. Most of them obey the convention established by the venerable xterm and accept the -e <program> command-line option, so instead of
./myprogram
your IDE should run
xterm -e ./myprogram
If you're on a Debian system or its derivative, you might get away with
x-terminal-emulator -e ./myprogram
which is supposed to spawn your preferred terminal emulator program.
Stop running the code in the IDE and do it in a terminal emulator using the regular
go build
./myprogram
workflow.
I've never used LiteIDE so have no immediate experience with how to do that in it—you'll have to do your own research.
1 Some programs may happily work with or without being attached to a terminal, with shells (like bash or zsh) and interpreters (like Tcl or Python) being good examples: when they detect a terminal device available, they go into interactive mode, enable line editing and so on, otherwise they just read the code from their standard input and execute it. Another good example is Git: its high-level programs detect if they're attached to a terminal and if so they might enable colouring of their output and automatically spawn a pager program if their output if about to overflow the single screenful of lines; otherwise they cut the fuss and just dump their output to their standard output stream.
For some external program (not all), I want the program running independently outside Emacs, after executing the command. In another word, if I close Emacs, the external program can still run.
PS: my operating system is windows.
I think (w32-shell-execute "start" "myprog" "args") should do the trick.
I'm a long time GNU/Linux user. Even though OSX is much like GNU/Linux is many ways, it differs in some. For example, when I install Firefox I expect to be able to run firefox in a shell to start it. But not in OSX.
That gives me some trouble when running Emacs batch scripts. Lets say I have this script:
#!/usr/bin/env emacs --script
(message "Hello world!")
I can run it without any problems. But I'll be using the emacs builtin to OSX. And most of the times that's not possible since the Emacs version is pretty old.
Installing Emacs from scratch made it possible to create a Bash-script, which called some emacs binary file.
But installing Emacs from http://emacsformacosx.com/ I can not make this work. Can anyone think of a solution for this?
(1) Launch Emacs.
(2) Open Activity Monitor. (Applications > Utilities > Activity Monitor)
(3) Find Emacs in the list of running processes, under "Process Name".
(4) Select it.
(5) Choose "Inspect" from the Toolbar.
(6) In the window that opens, choose the "Open Files and Ports" tab.
(7) The name of the Emacs executable currently running should be the second line in the list. (The first line should be /Users/yourusername.) In my case it's /Applications/Emacs.app/Contents/MacOS/Emacs, which is pretty standard.
Yes, you dig out the path to the Emacs app emacs.
I've got X EMACS on my machine (not an emacs app), but the path will be something like
/Applications/Emacs.app/Contents/bin/emacs
You can find the exact path with ls from the command line.