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?