about errorformat

[SungHyun Nam]

Hello,

There is always a message:

CTIME - 2011-01-03 09:57:57

And vim detects it as error message.

Can vim ignore this message? starting with CTIME...
Or ignore a message if it cannot find a file in message.

Regards,
namsh

[Ben Fritz]

Which compiler is this? Are you using the correct errorformat for that
compiler or just the default errorformat?

[SungHyun Nam]

It is not a compiler's output, but a message from a tool which
called by makefile. So that, I wanted to ignore this message by
tweaking the 'errorformat' without success. :(

And I use default errorformat. Just tried to tweak default
errorformat to ignore that message.

I can use filter like:
tool ... | sed 's/\([0-9]*\):\([0-9]*\):\([0-9]*\)/\1.\2.\3/g'
(Not good, I think.)

Actually I wanted to raise a issue like:
can VIM ignore errorformat if a file is not found?

Also, in the hope someone suggest a 'errorformat' which ignore
that message.

Regards,
namsh

[Gary Johnson]

You can add a pattern to the end of your 'errorformat' option like
this:

setlocal errorformat+=%-G%.%#

That will cause Vim to ignore any pattern not yet matched. See

:help efm-ignore

Regards,
Gary

[SungHyun Nam]

It does not work. You can check with the sequence below:

$ cat m.sh
#!/bin/bash
echo 'CTIME - 2000-01-01 12:34:56'
exit 0

$ vim
:set errorformat+=%-G%.%# makeprg=./m.sh
:make

Now, vim opens 'CTIME - 2000-01-01 12' file.

Thanks,
namsh

[Gary Johnson]

I see now that I misunderstood the problem. Thank you for the
example. In that case, a solution would be to put a pattern
matching the CTIME line at the front of 'errorformat', like so:

set errorformat^=%-GCTIME\ -\ %.%#

Note the ^= operator and that spaces in the pattern are escaped with
backslashes. See

:help set^=

Whether you use "set" or "setlocal" depends on what you wish the
scope of the resulting 'errorformat' to be.

Regards,
Gary

[SungHyun Nam]

Oh, many thanks! it works!

namsh

[Bram Moolenaar]

Namsh wrote:

This is mainly caused by the %f item in 'errorformat' accepting file
names with a space. That's needed for MS-Windows where quite a few
directory names have a space, such as "Program Files".

We could add a %F item that does not accept spaces inside a file name.
That would fix it for most people, especially on Unix, where spaces are
uncommon.

Would someone want to make a patch for that?

--
Proof techniques #2: Proof by Oddity.
SAMPLE: To prove that horses have an infinite number of legs.
(1) Horses have an even number of legs.
(2) They have two legs in back and fore legs in front.
(3) This makes a total of six legs, which certainly is an odd number of
legs for a horse.
(4) But the only number that is both odd and even is infinity.
(5) Therefore, horses must have an infinite number of legs.

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[SungHyun Nam]

Bram Moolenaar wrote:
>
> Namsh wrote:
>
>> There is always a message:
>>
>> CTIME - 2011-01-03 09:57:57
>>
>> And vim detects it as error message.
>>
>> Can vim ignore this message? starting with CTIME...
>> Or ignore a message if it cannot find a file in message.
>
> This is mainly caused by the %f item in 'errorformat' accepting file
> names with a space. That's needed for MS-Windows where quite a few
> directory names have a space, such as "Program Files".
>
> We could add a %F item that does not accept spaces inside a file name.
> That would fix it for most people, especially on Unix, where spaces are
> uncommon.
>
> Would someone want to make a patch for that?

To me, vim opens an empty buffer is somewhat annoying.

User who runs ':make' would know there occurs an error though vim
does not open empty buffer I think.

So that, I hope vim ignores a error message if it cannot find a
file (by default, if '%F' is used, option ??).

regards,
namsh

[Bram Moolenaar]

Namsh wrote:

Sometimes the file name is OK but the path is wrong, then it's still
useful to have the error parsed. Especially when it's one line in a
very long output. Deciding on whether the file exists also has the
disadvantage that this requires access to the file system, which can be
slow.

--
From "know your smileys":
!-| I-am-a-Cylon-Centurian-with-one-red-eye-bouncing-back-and-forth