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
