Remove standard output of compile

>This seems like a stupid question, but I cannot find the answer anywhere... When compiling, how can I remove all output in the \*compilation\* buffer except output issued by my code itself? i.e. remove everything except the line(s) marked \*\*\* below: -*- mode: compilation; default directory: ... -*- Compilation started at ... make -f ... make: Entering directory ... echo hello world hello world *** make: Leaving directory ... Compilation finished at ...

You could try to change your make command. According to the manual, it takes some interesting arguments: ‘-s’ ‘--silent’ ‘--quiet’ Silent operation; do not print the recipes as they are executed. See Recipe Echoing.

In addition to this, which will make `make` itself quiet, you could redirect `stderr` to `/dev/null`: `make` puts its messages on `stderr`, so if your code only uses `stdout`, `make <your flags, etc> 2> /dev/null` should do the trick

You haven't said *why* you want to do this, so just to make sure...you *are* aware of the `next-error` command (bound by default to C-x backtick or M-g n), which automatically parses the compilation buffer to take you to the next error message *and* take you to the file and line where the error occurred, yes? You also might be able to use the same regex as next-error as an argument to `occur` in order to extract the errors to a separate buffer.

Not to get [philosophical](https://www.gnu.org/philosophy/linux-gnu-freedom.en.html), but it shouldn't matter. I want to do it, and presumably it is technically possible, so I just want to know how. For context, I'm not actually compiling things, but running various makefile targets. I now realize `compile` is not the best tool for this, and I'm exploring other options, in particular [ivy-taskrunner](https://github.com/emacs-taskrunner/ivy-taskrunner). Thanks for your idea about pulling regex from `next-error` though.

While it *may* not matter, it is *extremely* common for people to come to a technical forum and ask how to perform some very specific task, but, if you take a moment to ask *why* they want to accomplish that task, it will turn out that they believe it's a necessary step to accomplish something *else*, which is actually *much* more easily done *some other way entirely*\--possibly even with an existing function or command they were unaware of. That is why I *always* try to ask what someone's *actual* goal is when have a very specific question like this. Yes, the approach they have planned may be the best one to achieve their specific goal, but often it's not! In my experience, a lot of time and effort can often be saved, and a lot of pain avoided, simply by asking "why?" Asking "why?" allows me to give better answers.