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-6364ng@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
rmf@cs.columbia.edu (Robert M. Fuhrer) (02/22/91)
Well, since we're on the subject, the IBM RS/6000 XLC C compiler generates pretty funny looking error messages. The really unfortunate part is that where compilation-error-regexp is expected to parse a file name and line number, the XLC compiler's messages don't include the file name. Does anyone have a solution? I've really gotten used to this feature, and would hate to see it go... -- -------------------------- Robert M. Fuhrer Computer Science Department Columbia University 1117B Fairchild Building Internet: rmf@cs.columbia.edu UUCP: ...!rutgers!cs.columbia.edu!rmf
barmar@think.com (Barry Margolin) (02/23/91)
In article <RMF.91Feb21171911@chopin.cs.columbia.edu> rmf@cs.columbia.edu (Robert M. Fuhrer) writes: >Well, since we're on the subject, the IBM RS/6000 XLC C compiler generates >pretty funny looking error messages. The really unfortunate part is that >where compilation-error-regexp is expected to parse a file name and line >number, the XLC compiler's messages don't include the file name. Does anyone >have a solution? I've really gotten used to this feature, and would hate to >see it go... If the compiler's messages don't include the file name, how do *humans* figure out which file the message refers to? If humans can't do it, then we'd be hard pressed to teach a computer to do it. -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
rmf@cs.columbia.edu (Robert M. Fuhrer) (02/27/91)
>In article <RMF.91Feb21171911@chopin.cs.columbia.edu> rmf@cs.columbia.edu (Robert M. Fuhrer) writes: >>Well, since we're on the subject, the IBM RS/6000 XLC C compiler generates >>pretty funny looking error messages. The really unfortunate part is that >>where compilation-error-regexp is expected to parse a file name and line >>number, the XLC compiler's messages don't include the file name. Does anyone >>have a solution? I've really gotten used to this feature, and would hate to >>see it go... > >If the compiler's messages don't include the file name, how do *humans* >figure out which file the message refers to? If humans can't do it, then >we'd be hard pressed to teach a computer to do it. >-- >Barry Margolin, Thinking Machines Corp. Well, of course, the problem is that it doesn't include the file name on each line. I've since realized the way to do it is by pre-processing the compilation buffer to insert the filename on each line so as not to have to munge compilation-parse-errors. -- -------------------------- Robert M. Fuhrer Computer Science Department Columbia University 1117B Fairchild Building Internet: rmf@cs.columbia.edu UUCP: ...!rutgers!cs.columbia.edu!rmf