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
signature.asc
Description: PGP signature
