If long lines are matched (e.g. in binary or minified files) then 2 bad things happen...
1) An internal buffer apparently crops each line, before the length of the line grepping is wrapping to (apparently) 2) Subsequent lines which grep has wrapped then show on separate lines
The result is a mess of disjointed output.
It can be fixed very easily by adding this after your grep command...
` | cut -c-80`
See comments [here](https://github.com/geany/geany/blob/21b06d1e4bf18f2cab137ab08a976dbf14274d58...). Fixes welcome.
Unfortunately the grep is not run in a shell, so piping to cut isn't possible.
(Thanks for all your replies to my issues @elextr - I know I've been posting a lot and fixing nothing myself, but I have too many backlogged commitments right now to start making pull requests.)
This patch resolves the problem, simply by matching the spawn API line limit to the messaging window limit...
``` diff --git a/src/spawn.c b/src/spawn.c index 1560d71a..5fdea3b5 100644 --- a/src/spawn.c +++ b/src/spawn.c @@ -1219,7 +1219,7 @@ gboolean spawn_with_callbacks(const gchar *working_directory, const gchar *comma { sc->cb.read = stdout_cb; sc->max_length = stdout_max_length ? stdout_max_length : - line_buffered ? 24576 : DEFAULT_IO_LENGTH; + line_buffered ? 1024 : DEFAULT_IO_LENGTH; } else { ```
I have tested.
I don't see the patch as causing harm, but I haven't done a full review of every use of the spawn API to see what they are doing with their line output.
Thanks for the patch, but why not pass 1024 to `stdout_max_length` when spawn is called to run programs displaying in the message window rather than add yet another mysterious constant to _every_ call to spawn?
Agreed, that makes more sense.
github-comments@lists.geany.org