From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Karl Fogel Newsgroups: gmane.emacs.devel Subject: Re: Proposal for a new mechanism for delayed stuff Date: Tue, 25 Dec 2012 13:57:35 -0600 Message-ID: <87ehidrjkg.fsf@floss.red-bean.com> References: <87pq1y46ao.fsf@gnus.org> Reply-To: Karl Fogel NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1356465467 27334 80.91.229.3 (25 Dec 2012 19:57:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Dec 2012 19:57:47 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 25 20:58:03 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TnadX-000192-Ea for ged-emacs-devel@m.gmane.org; Tue, 25 Dec 2012 20:58:03 +0100 Original-Received: from localhost ([::1]:46155 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TnadJ-00008d-97 for ged-emacs-devel@m.gmane.org; Tue, 25 Dec 2012 14:57:49 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:41097) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TnadE-00008S-Tv for emacs-devel@gnu.org; Tue, 25 Dec 2012 14:57:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Tnad8-00008q-Az for emacs-devel@gnu.org; Tue, 25 Dec 2012 14:57:44 -0500 Original-Received: from mail-ob0-f179.google.com ([209.85.214.179]:39045) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Tnad8-00008l-69 for emacs-devel@gnu.org; Tue, 25 Dec 2012 14:57:38 -0500 Original-Received: by mail-ob0-f179.google.com with SMTP id x4so7391568obh.38 for ; Tue, 25 Dec 2012 11:57:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:sender:from:to:subject:references:reply-to:date :in-reply-to:message-id:user-agent:mime-version:content-type; bh=VdMwlzI+yPAkqqM2djY4dHaB8Gz1vQ8N9YLmE2RNNQw=; b=L+SwXJ7uG9Xap+HZkeg+etyItLaGmOANvYnyx9VSFsF7OZyas3V9P378dEjBeh0c8v 4mNiEYQhIsRmhk10zNmximprKzvFYUPCyLbhDqGHIKu8SsmlEBpABg09My9wxHfOTeno mAyVRoTZCeYZcbZGGbBT2ykgSV8z8Jc5UuRPaeFhIXLEedxkZKhvmfyrdwaBLBEC95GM FsyH0nj9uN1twSM8J3KTbPFKtCzw3MyP0lNI0mbt/opE3KtTyvNnaRUnoCXJv/R/Nc+c lhFWiL83ior0IJ6P/1cUgPXkJcgMfCPGvzzN6IikuxKpX3SpkHsu8elW8uM1tuihvrSi rQSg== X-Received: by 10.60.171.201 with SMTP id aw9mr9104524oec.126.1356465457123; Tue, 25 Dec 2012 11:57:37 -0800 (PST) Original-Received: from floss.red-bean.com (64-145-114-106.client.dsl.net. [64.145.114.106]) by mx.google.com with ESMTPS id u1sm17478937oee.8.2012.12.25.11.57.36 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 25 Dec 2012 11:57:36 -0800 (PST) In-Reply-To: <87pq1y46ao.fsf@gnus.org> (Lars Ingebrigtsen's message of "Tue, 25 Dec 2012 14:20:31 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [fuzzy] X-Received-From: 209.85.214.179 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:155881 Archived-At: Lars Ingebrigtsen writes: >Gnus does a lot of stuff that it doesn't really know how long it'll take >to do. For instance, connecting to a mail server, and rendering >complex HTML. > >If Gnus were to output "Connecting to foo", "sending retrieval >commands", "waiting for foo to finish outputting" (which are usually >done asynchronously, intermingled between many servers), Gnus would spew >an inordinate number of messages. > >And sometimes the user should know what's taking so long, so that the >user can decide what to do about it. > >So the ideal would be if we could say "display a message if things take >too long". > >The idea I had yesterday was to make this totally general: > >(with-timeout-forms > (progn > (bla) > (bla)) > (1.5 (message "This is sure taking a lot of time...")) > (10 (message "This is sure taking forever!"))) > >A la condition-case and stuff, although here we have forms that are >run if the main form takes too long. So after 1.5 seconds we trigger >the first, and after 10 we trigger the second. > >And perhaps it would also be possible to have a special thing in the >timeout forms that would conclude the entire main form? Like `return' >or something. > >So it's like `with-timeout', only that it doesn't end executing the >body. And it would hopefully be possible to implement it such a way >that a looping body form would also be "pre-emptible". I think that's a great generalization idea. And `with-timeout' could then be (re)implemented using `with-timeout-forms', presumably.