From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Nested sit-for's Date: Thu, 17 Aug 2006 02:02:48 -0400 Message-ID: References: <87y7tp90i1.fsf@stupidchicken.com> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1155794619 7577 80.91.229.2 (17 Aug 2006 06:03:39 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 17 Aug 2006 06:03:39 +0000 (UTC) Cc: cyd@stupidchicken.com, emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 17 08:03:36 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1GDayc-0003Ov-R2 for ged-emacs-devel@m.gmane.org; Thu, 17 Aug 2006 08:03:35 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GDayc-0005zW-8p for ged-emacs-devel@m.gmane.org; Thu, 17 Aug 2006 02:03:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1GDaxv-0005Sh-9r for emacs-devel@gnu.org; Thu, 17 Aug 2006 02:02:51 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1GDaxu-0005Ra-Cb for emacs-devel@gnu.org; Thu, 17 Aug 2006 02:02:50 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1GDaxu-0005RU-8L for emacs-devel@gnu.org; Thu, 17 Aug 2006 02:02:50 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1GDb4K-0000jR-AY for emacs-devel@gnu.org; Thu, 17 Aug 2006 02:09:28 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1GDaxs-0000xM-MG; Thu, 17 Aug 2006 02:02:48 -0400 Original-To: storm@cua.dk (Kim F. Storm) In-reply-to: (storm@cua.dk) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:58459 Archived-At: >> What about the change that we discussed where nested sit-for calls >> should not wait longer than any of the outer calls?? I am not sure it is really a bug. Whether this behavior is incorrect depends on how you think of sit-for's purpose, and there is a natural way to think of it which makes this behavior correct. For the inner sit-for fail to wait for the time specified seems clearly wrong. My conclusion is that it is wrong for a timer to do a sit-for that lasts any substantial time. It should instead schedule a new timer. As long as jit-lock-stealth-nice is a short period such as 0.5, its sit-for cannot cause a big delay to anything else. The potential problem I do see is that jit-lock-stealth-fontify will keep looping as long as input-pending-p is nil. If it were to run from inside some other idle timer, that other idle timer would not get control back until fontification is finished. Making jit-lock-stealth-fontify's sit-for return faster won't avoid this problem, only reduce it, since jit-lock-stealth-fontify still would not return until it finishes fontification. The only solutions are (1) that jit-lock-stealth-fontify reschedule itself instead of using sit-for, or (2) that the other timer function avoid using sit-for. If several timers try this sit-for trick, then no matter what we make sit-for do, they can't all get the behavior they want, which is to do some more processing at a certain time in the future. The only method they can all use that enables them all to get this behavior is that of rescheduling timers. It would work to have ONE timer that does sit-for if we make a rule that no others can do so. We could define jit-lock as this one exception. (This has the advantage of not involving any change in the code, just comments and the Lisp Manual.) What do people think of that?