Dan_Jacobson@ATT.COM (02/21/91)
A former office mate of mine asked about not having to worry about moving the cursor himself to the line with a compiler error in his editor. Well, I couldn't resist the urge to share my response with the net, in the hope I can create more GNU Emacs converts. GNU Emacs is available by anonymous ftp to prep.ai.mit.edu. Also see the *.emacs.* and gnu.* newsgroups. ----- [begin] GNU Emacs has been doing this for years, and as you might have read from its manual, has two vi emulation modes --- "VIP" mode has its own manual too. A GNU Emacs user rarely is aware of line numbers any more than inode numbers. The commands in question are ESC x compile: Compile the program including the current buffer. Default: run `make'. Runs COMMAND, a shell command, in a separate process asynchronously with output going to the buffer *compilation*. You can then use the command C-x ` to find the next error message and move to the source code that caused it. ESC x grep: Run grep, with user-specified args, and collect output in a buffer. While grep runs asynchronously, you can use the C-x ` command to find the text that grep hits refer to. We see in the GNU Emacs manual, furthermore -------- File: emacs Node: Compilation, Prev: Running, Up: Running, Next: Lisp Modes Running `make', or Compilers Generally ====================================== Emacs can run compilers for noninteractive languages such as C and Fortran as inferior processes, feeding the error log into an Emacs buffer. It can also parse the error messages and visit the files in which errors are found, moving point right to the line where the error occurred. `M-x compile' Run a compiler asynchronously under Emacs, with error messages to `*compilation*' buffer. `M-x grep' Run `grep' asynchronously under Emacs, with matching lines listed in the buffer named `*compilation*'. `M-x kill-compiler' `M-x kill-grep' Kill the running compilation or `grep' subprocess. `C-x `' Visit the locus of the next compiler error message or `grep' match. To run `make' or another compiler, do `M-x compile'. This command reads a shell command line using the minibuffer, and then executes the specified command line in an inferior shell with output going to the buffer named `*compilation*'. The current buffer's default directory is used as the working directory for the execution of the command; normally, therefore, the makefile comes from this directory. When the shell command line is read, the minibuffer appears containing a default command line, which is the command you used the last time you did `M-x compile'. If you type just RET, the same command line is used again. The first `M-x compile' provides `make -k' as the default. The default is taken from the variable `compile-command'; if the appropriate compilation command for a file is something other than `make -k', it can be useful to have the file specify a local value for `compile-command' (*Note File Variables::). Starting a compilation causes the buffer `*compilation*' to be displayed in another window but not selected. Its mode line tells you whether compilation is finished, with the word `run' or `exit' inside the parentheses. You do not have to keep this buffer visible; compilation continues in any case. To kill the compilation process, do `M-x kill-compilation'. You will see that the mode line of the `*compilation*' buffer changes to say `signal' instead of `run'. Starting a new compilation also kills any running compilation, as only one can exist at any time. However, this requires confirmation before actually killing a compilation that is running. To parse the compiler error messages, type `C-x `' (`next-error'). The character following the `C-x' is the grave accent, not the single quote. This command displays the buffer `*compilation*' in one window and the buffer in which the next error occurred in another window. Point in that buffer is moved to the line where the error was found. The corresponding error message is scrolled to the top of the window in which `*compilation*' is displayed. The first time `C-x `' is used after the start of a compilation, it parses all the error messages, visits all the files that have error messages, and makes markers pointing at the lines that the error messages refer to. Then it moves to the first error message location. Subsequent uses of `C-x `' advance down the data set up by the first use. When the preparsed error messages are exhausted, the next `C-x `' checks for any more error messages that have come in; this is useful if you start editing the compiler errors while the compilation is still going on. If no more error messages have come in, `C-x `' reports an error. `C-u C-x `' discards the preparsed error message data and parses the `*compilation*' buffer over again, then displaying the first error. This way, you can process the same set of errors again. Instead of running a compiler, you can run `grep' and see the lines on which matches were found. To do this, type `M-x grep' with an argument line that contains the same arguments you would give `grep' when running it normally: a `grep'-style regexp (usually in singlequotes to quote the shell's special characters) followed by filenames which may use wildcards. The output from `grep' goes in the `*compilation*' buffer and the lines that matched can be found with `C-x `' as if they were compilation errors. Note: a shell is used to run the compile command, but the shell is told that it should be noninteractive. This means in particular that the shell starts up with no prompt. If you find your usual shell prompt making an unsightly appearance in the `*compilation*' buffer, it means you have made a mistake in your shell's init file (`.cshrc' or `.shrc' or ...) by setting the prompt unconditionally. The shell init file should set the prompt only if there already is a prompt. In `csh', here is how to do it: if ($?prompt) set prompt = ... ------ [(Dan J. back again) Disclaimer: there may be ways to do this in the /usr/bin/vi program (as opposed to one of GNU Emacs' vi emulations).] Furthermore, when one runs GDB, the GNU debugger, one can get an arrow in GNU EMacs pointing at the current source line being debugged. -- Dan_Jacobson@ATT.COM Naperville IL USA +1 708-979-6364
ng@cfd.di.nrc.ca (Kai Ng) (02/21/91)
In article <DANJ1.91Feb20114049@cbnewse.ATT.COM>, Dan_Jacobson@ATT.COM writes: |> |> ESC x compile: |> Compile the program including the current buffer. Default: run `make'. |> Runs COMMAND, a shell command, in a separate process asynchronously |> with output going to the buffer *compilation*. |> You can then use the command C-x ` to find the next error message |> and move to the source code that caused it. |> Yes, it is one of the best feature of GNU Emacs, but it doesn't work in AIX 3002 (with GNU Emacs 18.57 with X11 support). Has anybody encountered the same problem and have a solution? The other nice feature is dynamic abbreviation and global/mode abbreviation. Again, the global/mode abbreviation doen't work. It insists on putting a '-' at the end of an expansion. Help me please! -- ----------------------------------------------------------------------------- Kai S. Ng Informatics, National Research Council Canada INTERNET ng@cfd.di.nrc.ca M-60 Montreal Road, Ottawa, Canada K1A 0R6 BITNET kain@nrcvm01.bitnet VOICE (613) 993-0240 FAX (613) 954-2561
tporczyk@na.excelan.com (Tony Porczyk) (02/21/91)
The News Manager) Nntp-Posting-Host: na Reply-To: tporczyk@na.excelan.com (Tony Porczyk) Organization: Novell, Inc. San Jose, California References: <DANJ1.91Feb20114049@cbnewse.ATT.COM> Date: Wed, 20 Feb 1991 20:44:29 GMT In article <DANJ1.91Feb20114049@cbnewse.ATT.COM> Dan_Jacobson@ATT.COM writes: >A former office mate of mine asked about not having to worry about >moving the cursor himself to the line with a compiler error in his >editor. Well, I couldn't resist the urge to share my response with >the net, in the hope I can create more GNU Emacs converts. Thank you for this information. To those who deal mostly with PC editors, such feat is easily achieved with QEdit (2.1 can do it for sure, I use it, I don't know about the shareware 2.08 - email me if you have problems), and, I believe, with Brief, but I'm not 100% sure - a Brief expert will help me here. It is indeed a very nice feature to have. Tony