bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents

["João Távora" <joaotavora@gmail.com>]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: João Távora <joaotavora@gmail.com>
>> Cc: eliz@gnu.org,  k.michal@zoho.com
>> Date: Mon, 25 Jun 2018 11:49:58 +0100
>> 
>> I'm using this function in my Eglot package, but only because of its
>> ability to preserve markers, not text properties. And only one marker in
>> particular, the point marker.  So I wonder if sth like a
>> replace-buffer-contents-no-properties could be added: according to your
>> analysis it could be significantly faster.

> I doubt that, because keeping markers needs the same technique:
> deletions interspersed with insertions, where both deletions and
> insertions are as small as possible.

Thanks for explaining.  Without looking at the code, I would expect
performance to vary in proportion to the number of things to preserve
Thus, text properties, especially font-lock's, of which there are many
more than markers, probably weigh more.

> (You should only see the slowness if there are a lot of small
> differences scattered all over the buffers.  A few large differences
> close together should let the function's optimized algorithm to do a
> better job.)

Thanks again.  FWIW, here's why I need it: when asking the LSP server to
reformat the buffer (mostly reindent + whitespace here and there), some
servers answer with multiple small edits resulting in multiple
replace-buffer-contents calls.  For these cases, some speedup can
probably be attained by only calling replace-buffer-contents when the
affected region contains point.

Unfortunately, other servers (Python's, afaik) reply with a complete
slightly changed copy of a buffer, with short whitespace sequences added
or removed more or less uniformely throughout buffer.  These cases would
probably fall into the conditions you describe.  So maybe it could help
if replace-buffer-contents accepted only a subset of buffer markers that
need saving.

João