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

Previous Next

Full log

Message #58 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: acm <at> muc.de, k.michal <at> zoho.com, monnier <at> IRO.UMontreal.CA,
 31888 <at> debbugs.gnu.org
Subject: Re: bug#31888: 27.0.50; Segmentation fault in replace-buffer-contents
Date: Sat, 30 Jun 2018 09:33:48 +0100

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

>> >> Is that worth the hassle?  The caller asked to replace the entire
>> >> buffer by something else, why should they expect after-change hooks to
>> >> be run on something other than the entire buffer?
>> > s/entire buffer/entire accessible portion of buffer/g
>> FWIW I use this on potentially small sections of the buffer, by first
>> narrowing down to it.
> In that case, the after-change hook will be called on the narrowed
> portion of the buffer.

Sorry Eli, my previous assessment of the need for need for tighter
bounds was misleading.  I now think I aggree with Stefan's take on this
because:

*  Some LSP servers do in fact serve an entirely reformated file even if
   the actual change is very small.  This is inneficient from these
   servers but there's nothing we can do afaik.

*  I forgot Eglot *is* using the modification hooks to record and
   transmit back changes that it does to files while connected to the
   LSP server (yes, even if the file was reformatted from the server
   side, LSP specifies we must send back the changes we did to it).

   The point here is that if modification hook sees the whole file as
   changed, Eglot is just as inneficient as the server.

Thanks very much for the optimization efforts, I'll try to do some
benchmarks once they are in master (they aren't yet right?)

João

Previous Next

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