From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Power: blink-cursor-mode is a pig Date: Fri, 30 Dec 2011 17:32:55 +0200 Message-ID: <83liput6qg.fsf@gnu.org> References: <4EFCFDCA.6060802@dancol.org> <831urmv30g.fsf@gnu.org> <4EFD826D.2060309@dancol.org> <83pqf6theu.fsf@gnu.org> <4EFDA761.1040506@dancol.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: lo.gmane.org X-Trace: dough.gmane.org 1325259184 25428 80.91.229.12 (30 Dec 2011 15:33:04 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 30 Dec 2011 15:33:04 +0000 (UTC) Cc: Emacs-devel@gnu.org To: Daniel Colascione Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Dec 30 16:33:00 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1RgeS3-0007RY-Tr for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 16:33:00 +0100 Original-Received: from localhost ([::1]:35959 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgeS3-00013N-E0 for ged-emacs-devel@m.gmane.org; Fri, 30 Dec 2011 10:32:59 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:60136) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgeS0-000133-Ha for Emacs-devel@gnu.org; Fri, 30 Dec 2011 10:32:57 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RgeRz-00079y-BG for Emacs-devel@gnu.org; Fri, 30 Dec 2011 10:32:56 -0500 Original-Received: from mtaout20.012.net.il ([80.179.55.166]:59660) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RgeRz-00079u-3b for Emacs-devel@gnu.org; Fri, 30 Dec 2011 10:32:55 -0500 Original-Received: from conversion-daemon.a-mtaout20.012.net.il by a-mtaout20.012.net.il (HyperSendmail v2007.08) id <0LX000800WFOZZ00@a-mtaout20.012.net.il> for Emacs-devel@gnu.org; Fri, 30 Dec 2011 17:32:54 +0200 (IST) Original-Received: from HOME-C4E4A596F7 ([77.126.18.76]) by a-mtaout20.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0LX00066DWITV7V0@a-mtaout20.012.net.il>; Fri, 30 Dec 2011 17:32:54 +0200 (IST) In-reply-to: <4EFDA761.1040506@dancol.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 (beta) X-Received-From: 80.179.55.166 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:147060 Archived-At: > Date: Fri, 30 Dec 2011 03:58:25 -0800 > From: Daniel Colascione > CC: Emacs-devel@gnu.org > > Timers are used for all sorts of things. How is the C layer supposed > to know the purpose of a particular timer? See below: you proposed the same solution I had in mind. > I don't want my cursor-blinking timer to fire, but I might want > jit-lock to keep fontifying until it's done. If you want jit-lock to keep working, you already give up saving the power, so this whole discussion is moot. Why would one care about the cursor blinking when they don't care about JIT font lock? if they just don't like blink-cursor-mode, they can simply turn it off. > We could add a facility to allow lisp to communicate more information > about timers to the C layer --- perhaps some kind of timer metadata > meaning "run this timer only when Emacs has focus". I consider this > solution very ugly. I don't see this as ugly. We have already many Lisp symbols that have special properties which guide Emacs what to do or not to do with them. > > The loop that does this is always running; it never stops, except > > for very short periods of time. > > The Emacs main loop does not busy wait! I didn't say it busy waits. And I did mention "short periods of time", see above, during which we wait inside `select'. > Emacs chooses the timeout by looking at all its pending > timers and seeing which one will expire soonest. If the next timer > isn't due for an hour, Emacs will sleep for an hour before returning > from select. So why would it be a problem for Emacs to pay attention to the fact that it doesn't have focus, and choose the `select' timeout accordingly when it doesn't?