Anton Lindqvist wrote:

> If a file passed to the 'qf_init_ext' function contains lines longer
> than 1021 bytes (might be platform specific) the rest of the line is
> recognized as a separate error without a valid filename and lnum. If a
> string or list is passed to 'qf_init_ext' the rest of a long line is
> discarded. This patch adds the same behavior while reading errors from a
> file. This is done by continue reading from the file in to a temporary
> buffer until end-of-line is encountered. Could any existing general
> purpose buffer with a known size be used instead of allocation a new
> one?

This code comes from when memory was scarce and error messages were
short.  Using a fixed size buffer isn't so nice these days.

A good strategy could be to use IObuff as it is, and when an error
message is longer then allocate a larger buffer and append to it.
It does require growing (doubling?) the buffer further until a NL is
found.  That can be slow, e.g. if the error file has no NL at all
(that's a mistake, but you don't want Vim to hang then).  So some upper
limit would still be useful.

I have seen error messages from a test that say "expected
<very-long-string> but got <other-long-string>".  Not sure what a useful
upper limit would be.  100 Kbyte perhaps?

Are you interested in implementing this?

-- 
How do I set the laser printer to stun? 

 /// Bram Moolenaar -- [email protected] -- 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    ///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui