bug#31837: 26.1; replace-buffer-contents doesn't work if buffer has multibyte characters

["Milan Stanojević" <mstanojevic@janestreet.com>]

>> But what matters is whether there are actual multibyte characters in
>> the buffer
>
> If a buffer is unibyte, there could be no multibyte characters in it,
> by definition.
>
>> buf_charpos_to_bytepos already shortcircuits if there are none.
>
> Not before it calls some macros.  And it is confusing to call a
> conversion function when no conversion is needed, because the
> correctness of that can only be established by looking at the called
> conversion function.  That gets in the way of code reading, IME.

Right, I get your point regarding readability but maybe I can clarify
what I'm thinking.

The question is whether we need to optimize buffer_chars_equal  or not.

If not, then we can just call buf_charpos_to_bytepos without any other
checks, that seems most readable.

If we do care about optimizing it, then it is better to check whether
the buffer actually contains multibyte characters (I guess with
BUF_Z(buf) == BUF_Z_BYTE(buf)) than using enable_multibyte_characters
since the the former would catch strictly more cases when we don't
need charpos to bytepos conversion.
Also, it occurs to me, the check shouldn't be done in
buffer_chars_equal, since the same check would be done multiple times
for a single character (for every comparison of that character), it
should be done once and the result stored in ctx before calling
compareseq.
Again, I'm not sure this matters at all in practice, all the checks
are just a few memory accesses (presumable in the cache) and integer
comparisons.

Anyway, I could try doing something in the future about this, but the
code as it is now is perfectly fine.

Thanks again!