Re: Improve error reporting in 027_stream_regress test

On Mon, Jul 21, 2025 at 11:53:00AM +0300, Nazir Bilal Yavuz wrote:
> I realized that we actually don't trim the file, we do the opposite;
> read the file from both ends. Sorry for not realizing earlier. I will
> update the remaining patches according to that but I think trim_file()
> is helpful, too. What do you think about adding both

I did not review the contents of the patch yet, as I was rather unsure
about the right semantics here.

> ```
> trim_file() -> trims $n lines from head or tail of the file and
> returns the remaining lines.
> read_file_ends() -> returns $n lines from head or tail of the file.
> ```
> 
> although trim_file() will not be used in these particular patches?

And this made me wonder over the weekend if only showing the head
and/or tail of a file is always the best set of properties.
Then I came up that  this could be something close to what git-grep
-A/-B is able to do.  For example, for a crash, it would be much 
cheaper to target a log entry that matches with what we see in the
usual crash stacks, then print the surroundings.  The "trim" behavior
you have proposed is a subset of that, where the matching patterns are
the end and/or the beginning of the file to show.

So the API could com down to a pattern matching, with "head" and
"tail" being the optional number of lines we'd want to print around
the pattern we are looking for.
--
Michael