|quickfix-directory-stack| for details, tips and
limitations.


Multi-line messages				*errorformat-multi-line*

It is possible to read the output of programs that produce multi-line
messages, i.e. error strings that consume more than one line.  Possible
prefixes are:
	%E		start of a multi-line error message
	%W		start of a multi-line warning message
	%I		start of a multi-line informational message
	%N		start of a multi-line note message
	%A		start of a multi-line message (unspecified type)
	%>		for next line start with current pattern again |efm-%>|
	%C		continuation of a multi-line message
	%Z		end of a multi-line message
These can be used with '+' and '-', see |efm-ignore| below.

Using "\n" in the pattern won't work to match multi-line messages.

Example: Your compiler happens to write out errors in the following format
(leading line numbers not being part of the actual output):

     1	Error 275 ~
     2	line 42 ~
     3	column 3 ~
     4	' ' expected after '--' ~

The appropriate error format string has to look like this: >
   :set efm=%EError\ %n,%Cline\ %l,%Ccolumn\ %c,%Z%m

And the |:clist| error message generated for this error is:

 1:42 col 3 error 275:  ' ' expected after '--'

Another example: Think of a Python interpreter that produces the following
error message (line numbers are not part of the actual output):

     1	==============================================================
     2	FAIL: testGetTypeIdCachesResult (dbfacadeTest.DjsDBFacadeTest)
     3	--------------------------------------------------------------
     4	Traceback (most recent call last):
     5	  File "unittests/dbfacadeTest.py", line 89, in testFoo
     6	    self.assertEquals(34, dtid)
     7	  File "/usr/lib/python3.8/unittest.py", line 286, in
     8	 failUnlessEqual
     9	    raise self.failureException, \
    10	AssertionError: 34 != 33
    11
    12	--------------------------------------------------------------
    13	Ran 27 tests in 0.063s

Say you want |:clist| write the relevant information of this message only,
namely:
 5 unittests/dbfacadeTest.py:89:  AssertionError: 34 != 33

Then the error format string could be defined as follows: >
  :set efm=%C\ %.%#,%A\ \ File\ \"%f\"\\,\ line\ %l%.%#,%Z%[%^\ ]%\\@=%m

Note that the %C string is given before the %A here: since the expression
' %.%#' (which stands for the regular expression ' .*') matches every line
starting with a space, followed by any characters to the end of the line,
it also hides line 7 which would trigger a separate error message otherwise.
Error format strings are always parsed pattern by pattern until the first
match occurs.
							*efm-%>*
The %> item can be used to avoid trying patterns that appear earlier in
'errorformat'.  This is useful for patterns that match just about anything.
For example, if the error looks like this:

	Error in line 123 of foo.c: ~
	unknown variable "i" ~

This can be found with: >
	:set efm=xxx,%E%>Error in line %l of %f:,%Z%m
Where "xxx" has a pattern that would also match the second line.

Important: There is no memory of what part of the errorformat matched before;
every line in the error file gets a complete new run through the error format
lines.  For example, if one has: >
  setlocal efm=aa,bb,cc,dd,ee
Where aa, bb, etc. are error format strings.  Each line of the error file will
be matched to the pattern aa, then bb, then cc, etc.  Just because cc matched
the previous error line does _not_ mean that dd will be tried first on the
current line, even if cc and dd are multi-line errorformat strings.



Separate file name			*errorformat-separate-filename*

These prefixes are useful if the file name is given once and multiple messages
follow that refer to this file name.
	%O		single-line file message: overread the matched part
	%P		single-line file message: push file %f onto the stack
	%Q		single-line file message: pop the last file from stack

Example: Given a compiler that produces the following error logfile (without
leading line