GNU bug report logs - #31888
27.0.50; Segmentation fault in replace-buffer-contents

Previous Next

Package: emacs;

Reported by: Michał Kondraciuk <k.michal <at> zoho.com>

Date: Mon, 18 Jun 2018 21:00:04 UTC

Severity: normal

Found in version 27.0.50

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

Full log


Message #25 received at 31888 <at> debbugs.gnu.org (full text, mbox):

From: João Távora <joaotavora <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: k.michal <at> zoho.com, 31888 <at> debbugs.gnu.org
Subject: Re: bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents
Date: Mon, 25 Jun 2018 16:55:59 +0100
Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: João Távora <joaotavora <at> gmail.com>
>> Cc: eliz <at> gnu.org,  k.michal <at> 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





This bug report was last modified 6 years and 326 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.