Define edit block dividers as constants to simplify experimentation

[akaihola]

This stlil doesn't make the dividers (<<<<<<< SEARCH, =======, and >>>>>>> REPLACE) user configurable, but at least it's now more straightforward to try out and evaluate different divider strings in this branch.

The patch in this PR should make it easier to fix:

• Can't handle rst #1803

Note that regular expression matchers are now the exact divider strings instead of the old

HEAD = r"<{5,9} SEARCH"
DIVIDER = r"={5,9}"
UPDATED = r">{5,9} REPLACE"

Maybe we could have them configured separately as well.

[paul-gauthier]

The flexibility is needed for aider to work with the o1 models. They don't conform to the edit format and return variable numbers of the prefix characters.

[akaihola]

The flexibility is needed for aider to work with the o1 models. They don't conform to the edit format and return variable numbers of the prefix characters.

Ok, I understand.

But I believe there's a bug which makes the regex built from DIVIDER = r"={5,9}" match not only lines like:

=====
======
=======
========
=========

but also lines with any number of equal signs, e.g. here:

This is a long reStructuredText heading with way more than nine equal signs
===========================================================================

or, as a matter of fact, lines with any trailing junk (like ========junkjunkjunk).

This is due to

DIVIDER = r"={5,9}"
divider_pattern = re.compile(DIVIDER)

and subsequent

divider_pattern.match(lines[i].strip())

only checking that the beginning of the line matches (in find_original_update_blocks()).

So what happes is:

>>> lines = [
...     "This is a long reStructuredText heading with way more than nine equal signs\n",
...     "===========================================================================\n",
... ]
>>> re.compile(r"={5,9}").match(lines[1].strip())
<re.Match object; span=(0, 9), match='========='>

This is the reason for #1803, and the easy fix is:

divider_pattern = re.compile(fr"{DIVIDER}[ ]*$")

although that will still cause problems with reStructuredText files which have 5-to-9-character titles. Thus, I experimented (successfully) with pseudo-XML separators (see #1803 comment), although something like ======= DIVIDER should help just as well.

[paul-gauthier]

I will apply the fix so that it doesn't match =====whatever.

[paul-gauthier]

That change is in the main branch now.

[CLAassistant]

All committers have signed the CLA.