From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Tassilo Horn Newsgroups: gmane.emacs.devel Subject: Re: [RFC]: replace-region-contents Date: Fri, 08 Feb 2019 23:03:04 +0100 Message-ID: <875ztulyzr.fsf@gnu.org> References: <871s4rqk7u.fsf@gnu.org> <87o97syvno.fsf@gnu.org> <878syubwv3.fsf@gnu.org> <87y36u9xqt.fsf@gnu.org> <83k1ietcox.fsf@gnu.org> <87k1iew3u6.fsf@gnu.org> <83va1wsy95.fsf@gnu.org> <87h8dgetp1.fsf@gnu.org> <83mun8styg.fsf@gnu.org> <87lg2saiz9.fsf@gnu.org> <871s4idzb2.fsf@gnu.org> <83ef8iotr6.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="39035"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: eggert@cs.ucla.edu, monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Feb 08 23:03:52 2019 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gsEFU-000A27-MI for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2019 23:03:52 +0100 Original-Received: from localhost ([127.0.0.1]:35861 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsEFT-0007sj-Fp for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2019 17:03:51 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:47652) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsEEr-0007sb-So for emacs-devel@gnu.org; Fri, 08 Feb 2019 17:03:14 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:38200) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsEEr-0001iD-3o; Fri, 08 Feb 2019 17:03:13 -0500 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:52175) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1gsEEp-0006yK-Iu; Fri, 08 Feb 2019 17:03:12 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id 0A16A20E89; Fri, 8 Feb 2019 17:03:11 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 08 Feb 2019 17:03:11 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrledvgdduiedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfquhhtnecuuegrihhlohhuthemucef tddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenucfjughrpefhvffufhffjg fkfgggtgesthdtredttdertdenucfhrhhomhepvfgrshhsihhlohcujfhorhhnuceothhs ughhsehgnhhurdhorhhgqeenucfkphepleefrddvfeeirdduvdelrdehvdenucfrrghrrg hmpehmrghilhhfrhhomhepthhhohhrnhdomhgvshhmthhprghuthhhphgvrhhsohhnrghl ihhthidqkeeijeefkeejkeegqdeifeehvdelkedqthhsughhpeepghhnuhdrohhrghesfh grshhtmhgrihhlrdhfmhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Original-Received: from thinkpad-t440p (p5dec8134.dip0.t-ipconnect.de [93.236.129.52]) by mail.messagingengine.com (Postfix) with ESMTPA id 5C6A5E412F; Fri, 8 Feb 2019 17:03:08 -0500 (EST) In-Reply-To: <83ef8iotr6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 08 Feb 2019 23:27:57 +0200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:233150 Archived-At: Eli Zaretskii writes: >> if nobody complains, I'd like to install the following patch. > > No complaints from me, just a few comments. Too late, but I'll happily do some more changes. >> I've set too_expensive to 64 because then my benchmark was almost as >> fast as the original version without `replace-buffer-contents', and I >> couldn't find any difference in observable behavior in that value >> anyway except lower values give much better performance but a too low >> value like 10 will segfault. My main concern was that point was at >> the same position before and after pretty-printing my JSON. > > I'd prefer to expose this to Lisp, not hardcode the value. We could > use the hardcoded value in json.el, but I'd like to leave this to the > application in the other cases. I'm not sure such a small value will > always be the right tradeoff, so I think we shouldn't decide just yet. > > If you agree with that, let's expose this via a new optional argument > to replace-buffer-contents, and let's treat the value of nil as a very > large integer value, i.e. "no limit". Yes, fine with me. I'll do that tomorrow. >> #undef ELEMENT >> #undef EQUAL >> +#define USE_HEURISTIC >> + >> +#ifdef USE_HEURISTIC >> +#define DIFFSEQ_HEURISTIC >> +#endif >> >> /* Counter used to rarely_quit in replace-buffer-contents. */ >> static unsigned short rbc_quitcounter; >> @@ -2017,8 +2022,11 @@ differences between the two buffers. */) >> .insertions = SAFE_ALLOCA (ins_bytes), >> .fdiag = buffer + size_b + 1, >> .bdiag = buffer + diags + size_b + 1, >> +#ifdef DIFFSEQ_HEURISTIC >> + .heuristic = true, >> +#endif > > Why do we need this triple-level conditional? If we think the > heuristic is a good idea, let's just enable it unconditionally. If > someone wants to modify Emacs on the C level, they can edit the source > as easily as they can invoke the compiler with a -U switch. Ok. > Finally, I think this needs NEWS entries, both regarding the new > function and the additional argument to replace-buffer-contents. The > latter is also documented in the ELisp manual, which will need to be > updated. I'll write it. Thanks, Tassilo