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: Sat, 09 Feb 2019 01:00:48 +0100 Message-ID: <87o97lltjj.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="120895"; 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 Sat Feb 09 01:01:14 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 1gsG53-000VFq-KB for ged-emacs-devel@m.gmane.org; Sat, 09 Feb 2019 01:01:13 +0100 Original-Received: from localhost ([127.0.0.1]:37022 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsG52-0003tJ-F0 for ged-emacs-devel@m.gmane.org; Fri, 08 Feb 2019 19:01:12 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:40712) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsG4r-0003re-8z for emacs-devel@gnu.org; Fri, 08 Feb 2019 19:01:02 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:40328) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gsG4m-0006aG-8V; Fri, 08 Feb 2019 19:00:56 -0500 Original-Received: from auth2-smtp.messagingengine.com ([66.111.4.228]:42271) by fencepost.gnu.org with esmtpsa (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.82) (envelope-from ) id 1gsG4l-00015R-6y; Fri, 08 Feb 2019 19:00:56 -0500 Original-Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailauth.nyi.internal (Postfix) with ESMTP id A1900205F9; Fri, 8 Feb 2019 19:00:52 -0500 (EST) Original-Received: from mailfrontend1 ([10.202.2.162]) by compute7.internal (MEProxy); Fri, 08 Feb 2019 19:00:52 -0500 X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedtledrleefgdduudcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfhuthenuceurghilhhouhhtmecufedt tdenucesvcftvggtihhpihgvnhhtshculddquddttddmnecujfgurhephffvufhfffgjkf gfgggtsehttdertddtredtnecuhfhrohhmpefvrghsshhilhhoucfjohhrnhcuoehtshgu hhesghhnuhdrohhrgheqnecukfhppeelfedrvdefiedruddvledrhedvnecurfgrrhgrmh epmhgrihhlfhhrohhmpehthhhorhhnodhmvghsmhhtphgruhhthhhpvghrshhonhgrlhhi thihqdekieejfeekjeekgedqieefhedvleekqdhtshguhheppehgnhhurdhorhhgsehfrg hsthhmrghilhdrfhhmnecuvehluhhsthgvrhfuihiivgeptd 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 EBC13E425A; Fri, 8 Feb 2019 19:00:49 -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:233153 Archived-At: Eli Zaretskii writes: >> 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". Done on branch scratch/replace-region-contents. >> --- a/src/editfns.c >> +++ b/src/editfns.c >> @@ -1910,6 +1910,11 @@ determines whether case is significant or ignored. */) >> +#define USE_HEURISTIC >> + >> +#ifdef USE_HEURISTIC >> +#define DIFFSEQ_HEURISTIC >> +#endif >> @@ -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. Removed. Shall I also move replace-region-contents from subr.el to subr-x.el? > 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 that when everybody is ok with the code. > P.S. I still hope Paul will chime in and comments on the diffseq bits > we are modifying here. Oh, yes, please. Bye, Tassilo