Power: blink-cursor-mode is a pig

Power: blink-cursor-mode is a pig

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1676 bytes --]

blink-cursor-mode uses an idle timer to activate a regular timer that
blinks the cursor every 500ms.  While an Emacs frame has focus, we want
this timer to run so that we can make the cursor blink.  The problem is
that although the cursor stops blinking when Emacs loses focus, the
timer keeps running because Emacs has no idea it lost focus and doesn't
know it can turn off the timer.  The unnecessary Emacs wakeups caused by
this timer waste power.

We should turn off blink-cursor's timer when Emacs loses focus.  But as
far as I see, we don't send a focus-lost event to lisp.  The manual
specifically says that this switch-frame behavior is a feature, not a bug:

"Some X window managers are set up so that just moving the mouse into
a window is enough to set the focus there.  Usually, there is no need
for a Lisp program to know about the focus change until some other kind
of input arrives.  Emacs generates a focus event only when the user
actually types a keyboard key or presses a mouse button in the new
frame; just moving the mouse between frames does not generate a focus
event."

I think the reasoning behind this behavior has gone stale: blink-cursor
is on by default; most people use click-to-focus windowing systems; and
Emacs often runs on devices with batteries.  We should send focus and
blur events eagerly so blink-cursor can turn itself off.  (Ideally, we'd
also stop blinking the cursor when Emacs is invisible, but I imagine
it's rare for a window to be both focused and invisible.)

Is there an easier way of stopping the blink-cursor timer than plumbing
new events through the Emacs core, or turning blink-cursor off?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Power: blink-cursor-mode is a pig

[Lennart Borgman]

On Fri, Dec 30, 2011 at 00:54, Daniel Colascione <dancol@dancol.org> wrote:
>
> "Some X window managers are set up so that just moving the mouse into
> a window is enough to set the focus there.  Usually, there is no need
> for a Lisp program to know about the focus change until some other kind
> of input arrives.  Emacs generates a focus event only when the user
> actually types a keyboard key or presses a mouse button in the new
> frame; just moving the mouse between frames does not generate a focus
> event."
>
> I think the reasoning behind this behavior has gone stale: blink-cursor

Some event should be sent to Emacs lisp when it loses/gets focus.
Whether this is the same as that sent by a a key or mouse event is
another thing.

Re: Power: blink-cursor-mode is a pig

[Richard Stallman]

    Some event should be sent to Emacs lisp when it loses/gets focus.
    Whether this is the same as that sent by a a key or mouse event is
    another thing.

I think it is a bad idea.  It would lead people to do things that make
debugging impossible.

What do you want it for?

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use free telephony http://directory.fsf.org/category/tel/

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> Date: Thu, 29 Dec 2011 15:54:50 -0800
> From: Daniel Colascione <dancol@dancol.org>
> 
> I think the reasoning behind this behavior has gone stale: blink-cursor
> is on by default; most people use click-to-focus windowing systems; and
> Emacs often runs on devices with batteries.

FWIW, I _hate_ click-to-focus windowing systems.  They prevent me from
typing into a partially-obscured window while looking at a window in
the foreground; I need this frequently because I frequently work on
small displays.  When I need to work on a system whose default is
click-to-focus (e.g., MS-Windows), the first thing I do is figure out
how to set focus-follows-mouse operation, and then set it up.

> We should send focus and blur events eagerly so blink-cursor can
> turn itself off.  (Ideally, we'd also stop blinking the cursor when
> Emacs is invisible, but I imagine it's rare for a window to be both
> focused and invisible.)
> 
> Is there an easier way of stopping the blink-cursor timer than plumbing
> new events through the Emacs core, or turning blink-cursor off?

Let me turn the table and ask you why do you think we need to deliver
the focus-lost event to Lisp, if all we want is stop the cursor from
blinking?  Cursor blinking is implemented on the low level in C; why
can't we disable it at that same level, without bothering the command
loop and the input queue with events they don't need to see?

Re: Power: blink-cursor-mode is a pig

[Lennart Borgman]

On Fri, Dec 30, 2011 at 10:10, Eli Zaretskii <eliz@gnu.org> wrote:
>
> Let me turn the table and ask you why do you think we need to deliver
> the focus-lost event to Lisp, if all we want is stop the cursor from
> blinking?  Cursor blinking is implemented on the low level in C; why
> can't we disable it at that same level, without bothering the command
> loop and the input queue with events they don't need to see?

I agree that fixing blink cursor on a low level might be better.

However the events focus-lost/focus-got can still be useful. For
example I have long ago suggested to use focus-got for checking if a
displayed file have changed.

Re: Power: blink-cursor-mode is a pig

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 2862 bytes --]

On 12/30/11 1:10 AM, Eli Zaretskii wrote:
>> Date: Thu, 29 Dec 2011 15:54:50 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>>
>> I think the reasoning behind this behavior has gone stale: blink-cursor
>> is on by default; most people use click-to-focus windowing systems; and
>> Emacs often runs on devices with batteries.
> 
> FWIW, I _hate_ click-to-focus windowing systems.  They prevent me from
> typing into a partially-obscured window while looking at a window in
> the foreground; I need this frequently because I frequently work on
> small displays.  When I need to work on a system whose default is
> click-to-focus (e.g., MS-Windows), the first thing I do is figure out
> how to set focus-follows-mouse operation, and then set it up.

I wholly agree.  I prefer sloppy focus myself; if fewer Windows
applications would insist on raising themselves to the top whenever they
received input focus, I'd use sloppy focus even on that OS.  I'm just
pointing out that the majority of our users use click-to-focus systems,
assuming they're roughly similar to users at large.

>> We should send focus and blur events eagerly so blink-cursor can
>> turn itself off.  (Ideally, we'd also stop blinking the cursor when
>> Emacs is invisible, but I imagine it's rare for a window to be both
>> focused and invisible.)
>>
>> Is there an easier way of stopping the blink-cursor timer than plumbing
>> new events through the Emacs core, or turning blink-cursor off?
> 
> Let me turn the table and ask you why do you think we need to deliver
> the focus-lost event to Lisp, if all we want is stop the cursor from
> blinking?  Cursor blinking is implemented on the low level in C; why
> can't we disable it at that same level, without bothering the command
> loop and the input queue with events they don't need to see?

Cursor blinking is _not_ implemented at a low level in C; if it were,
the problem would be more tractable.  The cursor blinking is triggered
by a lisp timer.  The display code (specifically,
get_window_cursor_type) can use a different kind of cursor depending on
whether a window is selected or not; that's why we don't observe the
cursor blinking when Emacs loses focus.  But the decision to show the
cursor or not happens on the lisp level, in blink-cursor-timer-function.

I don't see anything wrong with this approach.  The only problem is that
lisp doesn't know when it can turn off the timer.  If we receive
focus-lost events, we can disable the timer until we receive a focus-in
event (which may be before the next switch-frame).  Delivering the event
has a low computational cost, and it allows users to customize Emacs in
other ways (e.g., by using different colors for focused frames).  The
current behavior gives up generality and elegance in exchange for
imaginary performance.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> Date: Fri, 30 Dec 2011 01:20:45 -0800
> From: Daniel Colascione <dancol@dancol.org>
> CC: Emacs-devel@gnu.org
> 
> Cursor blinking is _not_ implemented at a low level in C; if it were,
> the problem would be more tractable.  The cursor blinking is triggered
> by a lisp timer.  The display code (specifically,
> get_window_cursor_type) can use a different kind of cursor depending on
> whether a window is selected or not; that's why we don't observe the
> cursor blinking when Emacs loses focus.  But the decision to show the
> cursor or not happens on the lisp level, in blink-cursor-timer-function.

Timers are not Lisp-level creatures, they are fully implemented in C.
They just call Lisp functions when the value of some variable becomes
non-positive, but that's all they have to do with Lisp.  It should be
very easy to avoid calling Lisp under some conditions known at the C
level.

But I think I actually don't understand what you are trying to achieve
exactly, and why, because I admit I don't know well what exactly is it
that causes power waste due to "Emacs wakeups" you want to avoid.

Here's what confuses me.  Timers are implemented as part of the Emacs
internal loop that watches the various channels (keyboard, subprocess
pipes, network connections) for available input.  The loop that does
this is always running; it never stops, except for very short periods
of time.  A timer fires when this loop sees that the current time is
past the timer's expiration time.  An idle time fires when the loop
sees that Emacs was idle for more than the specified amount of time
(i.e., the loop records when Emacs became idle and then compares the
current time with that recorded time).  When the loop decides that a
time expired, it calls its Lisp function.

(Btw, unlike what you say, blink-cursor-mode does _not_ use an idle
timer.  But this is not important; I digress.)

Now, in the context of battery operation, why would you want to avoid
calling the Lisp function, given that the loop which invokes that
function will still be running?  How will that avoid waking up Emacs,
when the fact that the loop is running already means Emacs is awake?

What am I missing?

> I don't see anything wrong with this approach.  The only problem is that
> lisp doesn't know when it can turn off the timer.

Turning off the timer does not prevent the above-mentioned loop from
running.  So how would this avoid wasting power?

Re: Power: blink-cursor-mode is a pig

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 3769 bytes --]

On 12/30/11 3:42 AM, Eli Zaretskii wrote:
>> Date: Fri, 30 Dec 2011 01:20:45 -0800
>> From: Daniel Colascione <dancol@dancol.org>
>> CC: Emacs-devel@gnu.org
>>
>> Cursor blinking is _not_ implemented at a low level in C; if it were,
>> the problem would be more tractable.  The cursor blinking is triggered
>> by a lisp timer.  The display code (specifically,
>> get_window_cursor_type) can use a different kind of cursor depending on
>> whether a window is selected or not; that's why we don't observe the
>> cursor blinking when Emacs loses focus.  But the decision to show the
>> cursor or not happens on the lisp level, in blink-cursor-timer-function.
> 
> Timers are not Lisp-level creatures, they are fully implemented in C.
> They just call Lisp functions when the value of some variable becomes
> non-positive, but that's all they have to do with Lisp.  It should be
> very easy to avoid calling Lisp under some conditions known at the C
> level.

Timers are used for all sorts of things. How is the C layer supposed
to know the purpose of a particular timer? I don't want my
cursor-blinking timer to fire, but I might want jit-lock to keep
fontifying until it's done.

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.

> But I think I actually don't understand what you are trying to achieve
> exactly, and why, because I admit I don't know well what exactly is it
> that causes power waste due to "Emacs wakeups" you want to avoid.
> 
> Here's what confuses me.  Timers are implemented as part of the Emacs
> internal loop that watches the various channels (keyboard, subprocess
> pipes, network connections) for available input.  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!  When Emacs is not busy
running lisp or doing other work, it waits blocked in select(2) until
input arrives, a signal arrives, or the timeout given to select
expires.  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.  During this time, Emacs will use no power because it
won't actually run --- the operating system maintains its own timer
queue and wakes threads only when they need to run.

(Right now, there is a bug that currently causes Emacs to wake up
every two seconds, but these wakeups are spurious, and I've sent a
patch to bug-gnu-emacs.)

>  A timer fires when this loop sees that the current time is
> past the timer's expiration time.  An idle time fires when the loop
> sees that Emacs was idle for more than the specified amount of time
> (i.e., the loop records when Emacs became idle and then compares the
> current time with that recorded time).  When the loop decides that a
> time expired, it calls its Lisp function.
> 
> (Btw, unlike what you say, blink-cursor-mode does _not_ use an idle
> timer.  But this is not important; I digress.)

blink-cursor-mode uses an idle timer to start the regular timer and
disables the regular timer in pre-command-hook.  It's a long story.

> Now, in the context of battery operation, why would you want to avoid
> calling the Lisp function, given that the loop which invokes that
> function will still be running?  How will that avoid waking up Emacs,
> when the fact that the loop is running already means Emacs is awake?

This paragraph rests on the invalid assumption I discussed above.
Emacs does not busy-wait.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Power: blink-cursor-mode is a pig

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

On 12/30/11 3:58 AM, Daniel Colascione wrote:
>> Here's what confuses me.  Timers are implemented as part of the Emacs
>> internal loop that watches the various channels (keyboard, subprocess
>> pipes, network connections) for available input.  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!  When Emacs is not busy
> running lisp or doing other work, it waits blocked in select(2) until
> input arrives, a signal arrives, or the timeout given to select
> expires.  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.  During this time, Emacs will use no power because it
> won't actually run --- the operating system maintains its own timer
> queue and wakes threads only when they need to run.

I should add that the machine as a whole does something very similar
to what Emacs does with its select timeout: the OS's thread scheduler
looks at what timers are scheduled across the entire system and puts
the CPU into a low-power state until the next one is due to expire.
That's why it's important for programs not to wake themselves up
unnecessarily: even one badly-behaved program can force the entire
system out of this low-power state.  When Emacs wakes up every 500ms
to uselessly blink an invisible cursor, it's just being rude, like
that kid we all knew in college who interrupted the professor every
other sentence.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> Date: Fri, 30 Dec 2011 03:58:25 -0800
> From: Daniel Colascione <dancol@dancol.org>
> 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?

Re: Power: blink-cursor-mode is a pig

[山本 光晴]

On 2011/12/30, at 20:42, Eli Zaretskii wrote:

> Timers are not Lisp-level creatures, they are fully implemented in C.
> They just call Lisp functions when the value of some variable becomes
> non-positive, but that's all they have to do with Lisp.  It should be
> very easy to avoid calling Lisp under some conditions known at the C
> level.
> 
> But I think I actually don't understand what you are trying to achieve
> exactly, and why, because I admit I don't know well what exactly is it
> that causes power waste due to "Emacs wakeups" you want to avoid.

I confess I've been having the same concern as Daniel has.
(I usually turn off blink-cursor-mode in order to work around it.)

First, let us confirm that Emacs has two kinds of timers ("atimer"
and "timer") just in case, because it can be confusing:

  http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01350.html .

I can observe the difference in the timeout argument of the
select calls depending on whether blink-cursor-mode is turned on
or not.

(compile Emacs with CFLAGS=-g)
$ gdb emacs
(gdb) b select_wrapper
(gdb) command
> silent
> p *tmo
> cont
> end
(gdb) r -Q -D

Then the timeout value becomes 100k sec.  This means the Emacs
process blocks practically indefinitely as long as it is idle.

If you turn on blink-cursor-mode, then the timeout value is
shortened to 0.5 sec even if it is idle or there are no focused
frames.

What Daniel is trying to would be to make this timeout 100k sec
while there are no focused frames by suspending the timer for
blink-cursor-mode.

				     YAMAMOTO Mitsuharu 
				mituharu@math.s.chiba-u.ac.jp

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> From: 山本 光晴 <mituharu@math.s.chiba-u.ac.jp>
> Date: Fri, 30 Dec 2011 21:49:22 +0900
> Cc: Daniel Colascione <dancol@dancol.org>,
>  Emacs-devel@gnu.org
> 
> I confess I've been having the same concern as Daniel has.
> (I usually turn off blink-cursor-mode in order to work around it.)

I'm not arguing that we should solve this, I just don't see why a
change to the events visible from Lisp would be the only way.

> First, let us confirm that Emacs has two kinds of timers ("atimer"
> and "timer") just in case, because it can be confusing:
> 
>   http://lists.gnu.org/archive/html/emacs-devel/2004-10/msg01350.html .

I was talking about the latter.  The former is a signal, not an event.

> What Daniel is trying to would be to make this timeout 100k sec
> while there are no focused frames by suspending the timer for
> blink-cursor-mode.

And I'm saying we can do that on the C level, because that is the
level where the timeout for `select' is computed.

Re: Power: blink-cursor-mode is a pig

[YAMAMOTO Mitsuharu]

On 2011/12/31, at 0:35, Eli Zaretskii wrote:

>> What Daniel is trying to would be to make this timeout 100k sec
>> while there are no focused frames by suspending the timer for
>> blink-cursor-mode.
> 
> And I'm saying we can do that on the C level, because that is the
> level where the timeout for `select' is computed.

I didn't say anything about a particular way of solving this
problem.  I just explained why turning off the timers avoid
wasting power because you said, "Turning off the timer does not
prevent the above-mentioned loop from running.  So how would this
avoid wasting power?"

BTW, stopping/suspending timers does not avoid Emacs to wake up
in a short period on some ports, depending on how its `select'
emulation is implemented.  At least, this applies to the NS port
because it does periodic polling inside its `select'
implementation when there are some subprocesses or network
connections.  The Mac port does not have this drawback.  I'm not
sure about the W32 port.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
> Date: Sat, 31 Dec 2011 12:47:19 +0900
> Cc: dancol@dancol.org,
>  Emacs-devel@gnu.org
> 
> BTW, stopping/suspending timers does not avoid Emacs to wake up
> in a short period on some ports, depending on how its `select'
> emulation is implemented.  At least, this applies to the NS port
> because it does periodic polling inside its `select'
> implementation when there are some subprocesses or network
> connections.  The Mac port does not have this drawback.  I'm not
> sure about the W32 port.

If my reading of w32proc.c is correct, the w32 port blocks inside the
call to WaitForMultipleObjects for the same time interval as the
timeout specified in the call to `select' (redirected to `sys_select'
on w32).  But this only blocks the main thread, the one that runs
Lisp; the input thread that processes messages delivered to the Emacs
frames cannot be blocked (doing so could cause deadlock to the entire
system), so it continues running and processing messages.

Re: Power: blink-cursor-mode is a pig

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 1684 bytes --]

On 12/30/11 11:10 PM, Eli Zaretskii wrote:
>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>> Date: Sat, 31 Dec 2011 12:47:19 +0900
>> Cc: dancol@dancol.org,
>>  Emacs-devel@gnu.org
>>
>> BTW, stopping/suspending timers does not avoid Emacs to wake up
>> in a short period on some ports, depending on how its `select'
>> emulation is implemented.  At least, this applies to the NS port
>> because it does periodic polling inside its `select'
>> implementation when there are some subprocesses or network
>> connections.

Why? Some Cocoa limitation?

>> The Mac port does not have this drawback.  I'm not
>> sure about the W32 port.
> 
> If my reading of w32proc.c is correct, the w32 port blocks inside the
> call to WaitForMultipleObjects for the same time interval as the
> timeout specified in the call to `select' (redirected to `sys_select'
> on w32).  But this only blocks the main thread, the one that runs
> Lisp; the input thread that processes messages delivered to the Emacs
> frames cannot be blocked (doing so could cause deadlock to the entire
> system), so it continues running and processing messages.
> 

Right. cygw32 also uses MsgWaitForMultipleObjects (because
/dev/windows is in the select(2) set), so it behaves the same way as
the NT port.  In both, the UI thread will still receive messages, but
Windows takes pains to not send out useless message broadcasts.  Other
than these broadcasts, a program is only woken to receive a message
when something specifically sends it a message.  If there's no system
activity, or the only activity is unrelated to Emacs, Emacs won't
receive any messages and won't wake up.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 235 bytes --]

Re: Power: blink-cursor-mode is a pig

[YAMAMOTO Mitsuharu]

On 2011/12/31, at 16:21, Daniel Colascione wrote:

> On 12/30/11 11:10 PM, Eli Zaretskii wrote:
>>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>>> Date: Sat, 31 Dec 2011 12:47:19 +0900
>>> Cc: dancol@dancol.org,
>>> Emacs-devel@gnu.org
>>> 
>>> BTW, stopping/suspending timers does not avoid Emacs to wake up
>>> in a short period on some ports, depending on how its `select'
>>> emulation is implemented.  At least, this applies to the NS port
>>> because it does periodic polling inside its `select'
>>> implementation when there are some subprocesses or network
>>> connections.
> 
> Why? Some Cocoa limitation?

I don't know for sure.  Maybe for compatibility with GNUstep?

The Mac port uses either Grand Central Dispatch (on Mac OS X 10.6
or later) or Pthreads with CFRunLoopSource so as to avoid
periodic polling in the `select' emulation.  IIUC, both are
specific to Mac OS X, if not Carbon.

				     YAMAMOTO Mitsuharu
				mituharu@math.s.chiba-u.ac.jp

Re: Power: blink-cursor-mode is a pig

[Jan Djärv]

Hello.

31 dec 2011 kl. 08:42 skrev YAMAMOTO Mitsuharu:

> 
> On 2011/12/31, at 16:21, Daniel Colascione wrote:
> 
>> On 12/30/11 11:10 PM, Eli Zaretskii wrote:
>>>> From: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>
>>>> Date: Sat, 31 Dec 2011 12:47:19 +0900
>>>> Cc: dancol@dancol.org,
>>>> Emacs-devel@gnu.org
>>>> 
>>>> BTW, stopping/suspending timers does not avoid Emacs to wake up
>>>> in a short period on some ports, depending on how its `select'
>>>> emulation is implemented.  At least, this applies to the NS port
>>>> because it does periodic polling inside its `select'
>>>> implementation when there are some subprocesses or network
>>>> connections.
>> 
>> Why? Some Cocoa limitation?
> 
> I don't know for sure.  Maybe for compatibility with GNUstep?
> 
> The Mac port uses either Grand Central Dispatch (on Mac OS X 10.6
> or later) or Pthreads with CFRunLoopSource so as to avoid
> periodic polling in the `select' emulation.  IIUC, both are
> specific to Mac OS X, if not Carbon.

The CF suggests Core Foundation, so it is not Carbon specific (but still OSX specific).
An alternative for OSX would be to use CFFileDescriptor, but that is 10.5 or later.
I think the current ns-select tries to work on GNUStep also.  But the polling it does is not good for performance, it accounts for half of the slowdown flyspell-buffer (for example) currently sees in the NS-port.

Going back to select, there used to be a half a second timeout added to select (if the current timer timeout was longer) to handle timeouts that various toolkits use for example menu activation and scrollbar repeats.  As Emacs are/was not using the toolkit specific event loop, those timeouts where missing.  This was mostly Motif and Gtk+.  I think we don't do that anymore.  For the Gtk+ case we now use the Gtk+ event handling.  For Motif, we add the timeout when we know there is a menu activation or a scroll in progress, and remove it afterwards.  So there should be no polling going on if blink-cursor if off and Emacs is idle.

	Jan D.

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> Date: Fri, 30 Dec 2011 23:21:59 -0800
> From: Daniel Colascione <dancol@dancol.org>
> Cc: YAMAMOTO Mitsuharu <mituharu@math.s.chiba-u.ac.jp>, Emacs-devel@gnu.org
> 
> Windows takes pains to not send out useless message broadcasts.  Other
> than these broadcasts, a program is only woken to receive a message
> when something specifically sends it a message.  If there's no system
> activity, or the only activity is unrelated to Emacs, Emacs won't
> receive any messages and won't wake up.

As long as no messages arrive, the w32 message-reading thread is blocked
inside the call to WaitForSingleObject (see w32xfns.c:get_next_message).
This call has no timeout, so it will block indefinitely.

Re: Power: blink-cursor-mode is a pig

[David De La Harpe Golden]

On 30/12/11 09:10, Eli Zaretskii wrote:

> FWIW, I _hate_ click-to-focus windowing systems.  They prevent me from
> typing into a partially-obscured window while looking at a window in
> the foreground.

Strictly, that sounds more like a beef with raise-on-focus, a separate 
concern from click-to-focus on several window systems, e.g. AmigaOS was 
click-to-focus but _not_ click-to-raise by default (you could turn on 
"ClickToFront" if you wanted it), you instead clicked specific titlebar 
widgets to raise/lower windows (awkward in its own way of course -the 
widgets could easily be obscured, making raising one window an exercise 
in lowering others)

Various x11 wms permit similar click-to-focus but not click-to-raise 
configuration, though it's not usually the default 
(http://nickgravgaard.com/windowlab/ is one where it is).

 > how to set focus-follows-mouse operation, and then set it up.

It's also possible to have focus-follows-mouse with auto-raise (perhaps 
after further delay), which I assume you'd also find a bit irritating.

Anyway, not that it matters much to emacs beyond continuing to avoid any 
focussed == raised assumption.

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> Date: Fri, 30 Dec 2011 14:37:11 +0000
> From: David De La Harpe Golden <david@harpegolden.net>
> CC: Daniel Colascione <dancol@dancol.org>, Emacs-devel@gnu.org
> 
> On 30/12/11 09:10, Eli Zaretskii wrote:
> 
> > FWIW, I _hate_ click-to-focus windowing systems.  They prevent me from
> > typing into a partially-obscured window while looking at a window in
> > the foreground.
> 
> Strictly, that sounds more like a beef with raise-on-focus

Yes, definitely.

> It's also possible to have focus-follows-mouse with auto-raise (perhaps 
> after further delay), which I assume you'd also find a bit irritating.

Of course.

Re: Power: blink-cursor-mode is a pig

[Thien-Thi Nguyen]

() Daniel Colascione <dancol@dancol.org>
() Thu, 29 Dec 2011 15:54:50 -0800

   Is there an easier way of stopping the blink-cursor timer than plumbing
   new events through the Emacs core, or turning blink-cursor off?

I don't think so.

Why don't you try adding a ‘focus-lost’ event?

Another (higher-level) approach is to make Emacs recognize
a "go into powersave mode" message (via dbus or whatever).
Then, ‘blink-cursor-mode’ can DTRT w/ the provided hook.

Or perhaps you can trigger on the ‘iconify-frame’ event,
but you would need to iconify Emacs for that.  This would
work well w/ ratpoison, for example.

Re: Power: blink-cursor-mode is a pig

[Óscar Fuentes]

Thien-Thi Nguyen <ttn@gnuvola.org> writes:

> () Daniel Colascione <dancol@dancol.org>
> () Thu, 29 Dec 2011 15:54:50 -0800
>
>    Is there an easier way of stopping the blink-cursor timer than plumbing
>    new events through the Emacs core, or turning blink-cursor off?

One easy thing to do (at the Elisp user level) is to turn off
blink-cursor-mode off after N seconds of inactivity. That has the
advantage of working while Emacs has the focus too.

> I don't think so.
>
> Why don't you try adding a ‘focus-lost’ event?
>
> Another (higher-level) approach is to make Emacs recognize
> a "go into powersave mode" message (via dbus or whatever).
> Then, ‘blink-cursor-mode’ can DTRT w/ the provided hook.

Such event makes no sense. AFAIK it is a CPU feature, with the OS having
a marginal involvement. Then, it is turned off when significant CPU
activity arises, which is, precisely, what an event handler would cause
(that's why the OP is trying to turn off the timer associated with
blink-cursor-mode.)

> Or perhaps you can trigger on the ‘iconify-frame’ event,
> but you would need to iconify Emacs for that.  This would
> work well w/ ratpoison, for example.

IMO with ratpoison and similar window managers only a minority of Emacs
users would be coveverd.

Re: Power: blink-cursor-mode is a pig

[Chong Yidong]

Daniel Colascione <dancol@dancol.org> writes:

> blink-cursor-mode uses an idle timer to activate a regular timer that
> blinks the cursor every 500ms.  While an Emacs frame has focus, we want
> this timer to run so that we can make the cursor blink.  The problem is
> that although the cursor stops blinking when Emacs loses focus, the
> timer keeps running because Emacs has no idea it lost focus and doesn't
> know it can turn off the timer.  The unnecessary Emacs wakeups caused by
> this timer waste power.

On the Gnome terminal, the cursor stops blinking after ten blinks
(edits, X window selection, and cursor motion cause the blinking to
resume).  I think this idea is a reasonable one for us copy, and it
would eliminate the power wasting problem.

Re: Power: blink-cursor-mode is a pig

[Lennart Borgman]

On Sat, Dec 31, 2011 at 19:04, Chong Yidong <cyd@gnu.org> wrote:
>
> On the Gnome terminal, the cursor stops blinking after ten blinks
> (edits, X window selection, and cursor motion cause the blinking to
> resume).  I think this idea is a reasonable one for us copy, and it
> would eliminate the power wasting problem.

Good idea. Then that hook "got-focus" could be used to start blinking again.

Re: Power: blink-cursor-mode is a pig

[grischka]

Eli Zaretskii wrote:
>> Date: Fri, 30 Dec 2011 23:21:59 -0800
>> From: Daniel Colascione <address@hidden>
>> Cc: YAMAMOTO Mitsuharu <address@hidden>, address@hidden
>> 
>> Windows takes pains to not send out useless message broadcasts.  Other
>> than these broadcasts, a program is only woken to receive a message
>> when something specifically sends it a message.  If there's no system
>> activity, or the only activity is unrelated to Emacs, Emacs won't
>> receive any messages and won't wake up.
> 
> As long as no messages arrive, the w32 message-reading thread is blocked
> inside the call to WaitForSingleObject (see w32xfns.c:get_next_message).
> This call has no timeout, so it will block indefinitely.

(A) w32xfns.c:get_next_message doesn't run in the "w32 message-reading thread"
and (B) never calls WaitForSingleObject.

--- grischka

Re: Power: blink-cursor-mode is a pig

[Eli Zaretskii]

> Date: Sat, 31 Dec 2011 13:00:36 +0100
> From: grischka <grishka@gmx.de>
> Cc: emacs-devel@gnu.org
> 
> (A) w32xfns.c:get_next_message doesn't run in the "w32 message-reading thread"
> and (B) never calls WaitForSingleObject.

It also doesn't exist.

Anyway, yes, I was confused, sorry.  The Windows messages are
processed by w32fns.c:w32_wnd_proc.