GNU bug report logs - #70077
An easier way to track buffer changes

Previous Next

Full log

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: phillip.lord <at> russet.org.uk
Cc: Ihor Radchenko <yantar92 <at> posteo.net>, 70077 <at> debbugs.gnu.org,
 Yuan Fu <casouri <at> gmail.com>, Qiantan Hong <qhong <at> alum.mit.edu>,
 Frédéric Bour <frederic.bour <at> lakaban.net>,
 João Távora <joaotavora <at> gmail.com>,
 Nicolas Goaziou <mail <at> nicolasgoaziou.fr>, Alan Mackenzie <acm <at> muc.de>,
 Stephen Leake <stephen_leake <at> stephe-leake.org>,
 Alan Zimmerman <alan.zimm <at> gmail.com>
Subject: Re: bug#70077: An easier way to track buffer changes
Date: Sat, 30 Mar 2024 09:39:22 -0400

> Ah, yes, you are correct, I had missed that one. As you note, it would
> be costly, especially because if you wanted to do anything with that
> data, you would probably end up dumping it into a temp buffer.

That's indeed what I end up doing in the `eglot.el` case.
But if the API wants to tackle the performance issue of combining many
small changes into a larger one, I don't know how we can do better.

Another idea I considered was to keep a whole buffer as "previous
contents" (instead of a string that covers the modified area).
In some cases it would be more efficient, but the common case would be
a lot more costly.


        Stefan

Previous Next

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