feat: support %L conflict marker size option #136

oh, it seems like we don't actually get to use DisplaySettings's methods, since, we may get an incomplete settings (with *_revision_name still being at default values). Having such incomplete structs passed around is really an anti-pattern, so I'd say we try to get rid of that first

cleaned up the commit history a little

got rid of the whole builder thing, rebased onto main

I'm still unsure about how this should interact with ParsedMerge::parse – isn't it the case that even if mergiraf merge gets called on a file wtih conflicts properly annotated with markers of some non-standard size, Mergiraf will still try to parse the file with the marker length assumed to be 7 (by virtue of the marker regex), and get totally confused? Because of this, I have first changed parse to make it also take DisplaySettings as input, but then reverted this change

I've experimented with a test Git repo a little, and am now pretty sure that we indeed need to respect conflict-marker-size during parsing. I'll revert the revert then

rebased onto main

I now realize that 8a2a4f192f actually doesn't have anything to do with this PR per se (what I wanted to was 979ac4e77c9d5c9878b42debd6907fe7c1bf8caa), but I guess I'll just leave it be

Fixed the test

By the way, I made a quick test to understand better how the conflict marker size is picked by git. I was hoping that it would be able to dynamically pick a size that made conflict markers distinct from the lines already contained in the files involved, but that doesn't seem to be the case (it can be configured in gitattributes). Maybe it wouldn't be so useful anyway, because the reader would still have a hard time understanding which marker is what if the size of the conflict markers produced by git varies depending on the contents.

I was hoping that it would be able to dynamically pick a size that made conflict markers distinct from the lines already contained in the files involved

I think it's also not often that you even have what-looks-like-conflict-markers lying around in your codebase. Rather, that would be expected in exactly the software that deals with the parsing/creation of those, e.g. diffy or mergiraf for that matter.

So I think that's another reason why such auto-detection functionality wouldn't be of much use anyway, and handling the exceptions explicitly by using .gitattributes would be exactly the right escape hatch. Speaking of which... that's exactly what my follow-up PR will consist of!