[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents
From: |
João Távora |
Subject: |
bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents |
Date: |
Mon, 25 Jun 2018 16:55:59 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
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
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Michał Kondraciuk, 2018/06/18
- bug#31888:, Milan Stanojević, 2018/06/18
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/22
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/23
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, João Távora, 2018/06/25
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/25
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents,
João Távora <=
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Stefan Monnier, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Stefan Monnier, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, João Távora, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/29
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, João Távora, 2018/06/30
- bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents, Eli Zaretskii, 2018/06/30