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 would prefer allocating a buffer using BUFSIZ defined in stdio.h and > then make it grow exponentially. Instead of using a upper limit I would > prefer to continue reading until NL/EOF occurs or realloc fails.
Well, if arbitrary long lines are supported, where would they be useful? Certainly not for displaying, it would scroll through many pages. Perhaps for a script that analizes the error further. But I find that a bit far fetched. I think a 100 Kbyte limit is very resonable. Especially since currently it's chopped up after 1 Kbyte. > > 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? > > Reading and displaying the whole line despite its length is a reasonable > behavior nowadays, however like marius@ pointed out I would not mind if > the lines where truncated since they seldom adds value. > > > Are you interested in implementing this? > > Sure! But what's your take on the concerns above? I think reading into IObuff at first, and using a growing buffer after that would be a good solution. Probably keep the buffer until all errors are done, if one line is long there is a bigger change of another one. -- hundred-and-one symptoms of being an internet addict: 229. You spend so much time thinking what to add on this list. /// 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.
