From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Lars Ingebrigtsen Newsgroups: gmane.emacs.devel Subject: Proposal for a new mechanism for delayed stuff Date: Tue, 25 Dec 2012 14:20:31 +0100 Organization: Programmerer Ingebrigtsen Message-ID: <87pq1y46ao.fsf@gnus.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1356441661 17151 80.91.229.3 (25 Dec 2012 13:21:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 25 Dec 2012 13:21:01 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Dec 25 14:21:13 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 1TnURV-0006Fw-7q for ged-emacs-devel@m.gmane.org; Tue, 25 Dec 2012 14:21:13 +0100 Original-Received: from localhost ([::1]:58708 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TnURG-0005td-VT for ged-emacs-devel@m.gmane.org; Tue, 25 Dec 2012 08:20:58 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:45754) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TnURB-0005tQ-8j for emacs-devel@gnu.org; Tue, 25 Dec 2012 08:20:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TnUR6-0004OB-C4 for emacs-devel@gnu.org; Tue, 25 Dec 2012 08:20:53 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:41943) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TnUR6-0004O5-1L for emacs-devel@gnu.org; Tue, 25 Dec 2012 08:20:48 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1TnURG-000625-Oy for emacs-devel@gnu.org; Tue, 25 Dec 2012 14:20:58 +0100 Original-Received: from ip-90-20-179-93.dialup.ice.net ([93.179.20.90]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Dec 2012 14:20:58 +0100 Original-Received: from larsi by ip-90-20-179-93.dialup.ice.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Tue, 25 Dec 2012 14:20:58 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 39 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip-90-20-179-93.dialup.ice.net Mail-Copies-To: never X-Now-Playing: Winston Tong's _Theoretically Chinese_ User-Agent: Gnus/5.130006 (Ma Gnus v0.6) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:kWhoYqmsFopknfw1Zqq7vPJRVHg= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 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:155874 Archived-At: 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". -- (domestic pets only, the antidote for overdose, milk.) http://lars.ingebrigtsen.no * Lars Magne Ingebrigtsen