From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Philipp Stephani Newsgroups: gmane.emacs.devel Subject: Re: Keeping replace-buffer-contents runtime in bounds Date: Sun, 24 Feb 2019 21:13:03 +0100 Message-ID: References: <87r2c7ze9n.fsf@gnu.org> <83imxil8h6.fsf@gnu.org> <87y365a42g.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="123266"; mail-complaints-to="usenet@blaine.gmane.org" Cc: Eli Zaretskii , Emacs developers To: Tassilo Horn Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Feb 24 21:14:07 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 1gy0A2-000Vvg-9T for ged-emacs-devel@m.gmane.org; Sun, 24 Feb 2019 21:14:06 +0100 Original-Received: from localhost ([127.0.0.1]:55413 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gy0A1-0007RA-69 for ged-emacs-devel@m.gmane.org; Sun, 24 Feb 2019 15:14:05 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:56137) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gy09w-0007R4-5U for emacs-devel@gnu.org; Sun, 24 Feb 2019 15:14:00 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gy09s-00046v-Pg for emacs-devel@gnu.org; Sun, 24 Feb 2019 15:13:59 -0500 Original-Received: from mail-oi1-x22c.google.com ([2607:f8b0:4864:20::22c]:38666) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1gy09G-0003kN-DQ; Sun, 24 Feb 2019 15:13:19 -0500 Original-Received: by mail-oi1-x22c.google.com with SMTP id q81so5668585oic.5; Sun, 24 Feb 2019 12:13:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e4j0Ny2CGD5PDpNJzTglLql07v5DGR12ufXWUlICxKk=; b=fUfDzDZpfpK52xduLQOKtN+CeyQcXa0e+uXiN0JEiLjiYG2mt8UjKUPLmMzQwIKdoI FzJmdN4EJWnZUiAb6BtLunu+lLLyHbse963p7kSbH7y10PJG+OzYTtKL9ZJF3eSutNfg PE5kM3acmCzE5louHqEcSsKHm06HRDn+uKvCZsQiEz/1VXr6QUN0oa3yLUQT2AEJSHZj nwG29D5gSZ9RQHAEXyxEbenc0hVGtMAM47hRm6Wq3ie5ksx1jq0dcxx+GCNuVlaFfcnE 8SJq+5EkSgywIYoqFNM02OtpN10XL1suGHmMiWZKHN7WHU261ds9hEymvKaR37j/fPrH CsdA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e4j0Ny2CGD5PDpNJzTglLql07v5DGR12ufXWUlICxKk=; b=W3/OOL6NHF9+q1pB1RKpj903+cZQJCK5vqb12XxKK9sD0+xSyrjNCs1XsTP4lhFXI+ MJglaaQ8xP/NI6dCsihTN7oFXVXFqHHE4Qbz9ZTxD38TUXawu4YL3uwv/U+CmyUBLQDn oeJLn58WZchJFmWdSEg5veXGzlv2putGpZ/FzcDcUWp2aGOUJnoXkqtOeNEDddPAAn2C HBO/9GWELILxu9ixM3W90h4FEOEfwbXgv8vQSUyrkLCOqxQOpKJpYNJWyBpVrTwdOXme xM827lpnPbmmidMboVyPDj7Si4/6UgAqJGNYnbetcIsWTWJNDb04coY9ge6zD5A9tzMJ OoMQ== X-Gm-Message-State: AHQUAuaaqm6tfXk+xGaNbzdP2K5oAL6CeZkMmumebRqh3uEL1o5sp4Gs JX838jHPnci2wsszCHg/Bt3WKFwX2Mb446kAwnh7JUIg X-Google-Smtp-Source: AHgI3IaDzGbTy1qN+ThKn7+4OJ/RjDxHkRM4MQkaH8a8TZVwHCg5lTR1lWxH6AHMOvXR5rSG45WiEyBJKZNGdPwdhME= X-Received: by 2002:aca:5083:: with SMTP id e125mr9380746oib.9.1551039194983; Sun, 24 Feb 2019 12:13:14 -0800 (PST) In-Reply-To: <87y365a42g.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2607:f8b0:4864:20::22c 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:233580 Archived-At: Am So., 24. Feb. 2019 um 11:12 Uhr schrieb Tassilo Horn : > > Eli Zaretskii writes: > > >> In the end I settled for a maximum number of seconds one can define > >> by setting a new variable replace-buffer-contents-max-secs, so that > >> you can define what's still acceptable in the respective use-case. > >> (Actually, if you set that to 1.5 or so, it may still run for 2 or > >> more seconds because the EARLY_ABORT expression isn't tested at > >> regular intervals or rather it is, but the intervals don't take > >> equally long.) > >> > >> If that number of seconds is over, compareseq returns early and > >> replace-buffer-contents falls back to plain delete and insert. > > > > The gotcha about aborting after more than the time-out value should be > > mentioned in the doc string. > > > > Thanks for working on this. My only other comment is that maybe we > > should allow passing the time-out value via the function's arguments, > > not via a global variable. It seems to me the time-out will be used > > in more use cases than MAX-COSTS, and in any case treating these two > > differently API-wise sounds strangely inconsistent. > > I've done that and landed it in master. Thanks. However, the variable replace-buffer-contents-max-secs is still present, did you maybe keep it by mistake?