Blink cursor changes, possible W32 breakage.

Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

Just a heads up, I changed blink cursor in two ways, one is that it stops blinking after blinking
blink-cursor-blinks number of times (10 by default), as inspired by gnome-terminal.  Also, timers are stopped when no blinking occurs.

This works on NS and X but not on W32.  I tried to be careful to not break W32, but it might happen anyway.  If anybody wants to implement this for W32, you basically need to implement generating a FOCUS_OUT_EVENT, like xterm,c and nsterm.m does and adjust those places in keyboard.c and frame.el that checks for X and NS only.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Glenn Morris]

Jan Djärv wrote:

> Just a heads up, I changed blink cursor in two ways, one is that it
> stops blinking after blinking blink-cursor-blinks number of times (10
> by default), as inspired by gnome-terminal. Also, timers are stopped
> when no blinking occurs.

Sounds good! Does it fix/render redundant
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10404 ?

Re: Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

16 jul 2013 kl. 17:55 skrev Glenn Morris <rgm@gnu.org>:

> Jan Djärv wrote:
> 
>> Just a heads up, I changed blink cursor in two ways, one is that it
>> stops blinking after blinking blink-cursor-blinks number of times (10
>> by default), as inspired by gnome-terminal. Also, timers are stopped
>> when no blinking occurs.
> 
> Sounds good! Does it fix/render redundant
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10404 ?

I don't know, I haven't seen this 2 second polling that is mentioned (with strace/dtruss).  When the cursor stops blinking, there is a 30 second timeout, and after that a very long timeout (thousands of seconds, I don't have the exact value).  But on the other hand, I was not running Lisp at the time.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Juanma Barranquero]

The following patch works.

I'm not sure about the keyboard.c part. I suppose it is OK to use
FRAME_X_DISPLAY_INFO in the X and NS code?


=== modified file 'lisp/frame.el'
--- lisp/frame.el 2013-07-16 11:41:06 +0000
+++ lisp/frame.el 2013-07-16 16:44:14 +0000
@@ -1709,7 +1709,7 @@
   "Timer function of timer `blink-cursor-timer'."
   (internal-show-cursor nil (not (internal-show-cursor-p)))
   ;; Each blink is two calls to this function.
-  (when (memq window-system '(x ns))
+  (when (memq window-system '(x ns w32))
     (setq blink-cursor-blinks-done (1+ blink-cursor-blinks-done))
     (when (and (> blink-cursor-blinks 0)
        (<= (* 2 blink-cursor-blinks) blink-cursor-blinks-done))
@@ -1729,11 +1729,11 @@
     (setq blink-cursor-timer nil)))

 (defun blink-cursor-suspend ()
-  "Suspend cursor blinking on NS and X.
+  "Suspend cursor blinking on NS, X and W32.
 This is called when no frame has focus and timers can be suspended.
 Timers are restarted by `blink-cursor-check', which is called when a
 frame receives focus."
-  (when (memq window-system '(x ns))
+  (when (memq window-system '(x ns w32))
     (blink-cursor-end)
     (when blink-cursor-idle-timer
       (cancel-timer blink-cursor-idle-timer)

=== modified file 'src/keyboard.c'
--- src/keyboard.c 2013-07-16 11:41:06 +0000
+++ src/keyboard.c 2013-07-16 16:57:20 +0000
@@ -4085,7 +4085,7 @@
         }
       else if (event->kind == FOCUS_OUT_EVENT)
         {
-#if defined(HAVE_NS) || defined (HAVE_X11)
+#if defined (HAVE_NS) || defined (HAVE_X11) || defined (WINDOWSNT)

 #ifdef HAVE_NS
           struct ns_display_info *di;
@@ -4095,11 +4095,11 @@
           Lisp_Object rest, frame = event->frame_or_window;
           bool focused = false;

-          for (di = x_display_list; di && ! focused; di = di->next)
-            focused = di->x_highlight_frame != 0;
+          for (di = x_display_list; di && ! focused; di =
FRAME_X_DISPLAY_INFO (di)->next)
+            focused = FRAME_X_DISPLAY_INFO (di)->x_highlight_frame = 0;

           if (! focused) obj = make_lispy_focus_out (frame);
-#endif /* HAVE_NS || HAVE_X11 */
+#endif /* HAVE_NS || HAVE_X11 || WINDOWSNT */

           kbd_fetch_ptr = event + 1;
         }

=== modified file 'src/w32term.c'
--- src/w32term.c 2013-07-13 14:21:01 +0000
+++ src/w32term.c 2013-07-16 16:38:18 +0000
@@ -2912,9 +2912,15 @@
               && CONSP (Vframe_list)
               && !NILP (XCDR (Vframe_list)))
             {
-              bufp->kind = FOCUS_IN_EVENT;
-              XSETFRAME (bufp->frame_or_window, frame);
-            }
+              bufp->arg = Qt;
+            }
+          else
+            {
+              bufp->arg = Qnil;
+            }
+
+          bufp->kind = FOCUS_IN_EVENT;
+          XSETFRAME (bufp->frame_or_window, frame);
         }

       frame->output_data.x->focus_state |= state;
@@ -2929,7 +2935,10 @@
         {
           dpyinfo->w32_focus_event_frame = 0;
           x_new_focus_frame (dpyinfo, 0);
-        }
+
+          bufp->kind = FOCUS_OUT_EVENT;
+          XSETFRAME (bufp->frame_or_window, frame);
+      }

       /* TODO: IME focus?  */
     }

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Tue, 16 Jul 2013 13:48:49 +0200
> 
> Just a heads up, I changed blink cursor in two ways, one is that it stops blinking after blinking
> blink-cursor-blinks number of times (10 by default), as inspired by gnome-terminal.  Also, timers are stopped when no blinking occurs.

Why do we want that?  Is there a way to get previous behavior?

> This works on NS and X but not on W32.  I tried to be careful to not break W32, but it might happen anyway.  If anybody wants to implement this for W32, you basically need to implement generating a FOCUS_OUT_EVENT, like xterm,c and nsterm.m does and adjust those places in keyboard.c and frame.el that checks for X and NS only.

Sorry, I don't understand: w32 already implements the equivalent of
FOCUS_OUT_EVENT, but why is that relevant?  When no frame has focus,
Emacs on Windows doesn't blink the cursors already.

What am I missing?

And what is the other thing you changed?

Re: Blink cursor changes, possible W32 breakage.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Just a heads up, I changed blink cursor in two ways, one is that it
>> stops blinking after blinking
>> blink-cursor-blinks number of times (10 by default), as inspired by
>> gnome-terminal.  Also, timers are stopped when no blinking occurs.
>
> Why do we want that?  Is there a way to get previous behavior?

Set that variable to 0.  I'm not quite sure what the point is, though.
Perhaps it makes sense on low-power devices?  To avoid screen updates?

I think the variable should default to 0.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Blink cursor changes, possible W32 breakage.

[covici]

I hope you don't fix this for windows, it would probably make screen
readers not follow the cursor at all!

Glenn Morris <rgm@gnu.org> wrote:

> Jan Djärv wrote:
> 
> > Just a heads up, I changed blink cursor in two ways, one is that it
> > stops blinking after blinking blink-cursor-blinks number of times (10
> > by default), as inspired by gnome-terminal. Also, timers are stopped
> > when no blinking occurs.
> 
> Sounds good! Does it fix/render redundant
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=10404 ?
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Lars Magne Ingebrigtsen <larsi@gnus.org>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,  emacs-devel@gnu.org
> Date: Tue, 16 Jul 2013 20:02:44 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Just a heads up, I changed blink cursor in two ways, one is that it
> >> stops blinking after blinking
> >> blink-cursor-blinks number of times (10 by default), as inspired by
> >> gnome-terminal.  Also, timers are stopped when no blinking occurs.
> >
> > Why do we want that?  Is there a way to get previous behavior?
> 
> Set that variable to 0.

Thanks.

> I'm not quite sure what the point is, though.  Perhaps it makes
> sense on low-power devices?  To avoid screen updates?
> 
> I think the variable should default to 0.

To keep previous behavior by default, yes.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> Comments: In-reply-to Glenn Morris <rgm@gnu.org>
> 	message dated "Tue, 16 Jul 2013 11:55:33 -0400."
> Date: Tue, 16 Jul 2013 14:29:18 -0400
> From: covici@ccs.covici.com
> Cc: Jan =?utf-8?Q?Dj=C3=A4rv?=
> 	<jan.h.d@swipnet.se>, Emacs developers <emacs-devel@gnu.org>
> 
> I hope you don't fix this for windows, it would probably make screen
> readers not follow the cursor at all!

Screen readers follow the system caret, not the cursor.  Emacs on
Windows moves the caret when it moves the cursor, but I don't think
this has anything to do with blinking.

Re: Blink cursor changes, possible W32 breakage.

[covici]

Eli Zaretskii <eliz@gnu.org> wrote:

> > Comments: In-reply-to Glenn Morris <rgm@gnu.org>
> > 	message dated "Tue, 16 Jul 2013 11:55:33 -0400."
> > Date: Tue, 16 Jul 2013 14:29:18 -0400
> > From: covici@ccs.covici.com
> > Cc: Jan =?utf-8?Q?Dj=C3=A4rv?=
> > 	<jan.h.d@swipnet.se>, Emacs developers <emacs-devel@gnu.org>
> > 
> > I hope you don't fix this for windows, it would probably make screen
> > readers not follow the cursor at all!
> 
> Screen readers follow the system caret, not the cursor.  Emacs on
> Windows moves the caret when it moves the cursor, but I don't think
> this has anything to do with blinking.

Except that the screen readers require a blinking cursor, so there is a
special variable I have to set in my .emacs for this to work properly.


-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

         John Covici
         covici@ccs.covici.com

Re: Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

16 jul 2013 kl. 19:39 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Tue, 16 Jul 2013 13:48:49 +0200
>> 
>> Just a heads up, I changed blink cursor in two ways, one is that it stops blinking after blinking
>> blink-cursor-blinks number of times (10 by default), as inspired by gnome-terminal.  Also, timers are stopped when no blinking occurs.
> 
> Why do we want that?  Is there a way to get previous behavior?

To stop blink timers when there are no blinking cursors.  Put the variable to 0 to get previous behaviour, i.e. never stop blinking.

> 
>> This works on NS and X but not on W32.  I tried to be careful to not break W32, but it might happen anyway.  If anybody wants to implement this for W32, you basically need to implement generating a FOCUS_OUT_EVENT, like xterm,c and nsterm.m does and adjust those places in keyboard.c and frame.el that checks for X and NS only.
> 
> Sorry, I don't understand: w32 already implements the equivalent of
> FOCUS_OUT_EVENT, but why is that relevant?  When no frame has focus,
> Emacs on Windows doesn't blink the cursors already.

Yes, but timers are still running, so Emacs are never swapped out, and drains battery on laptops (yes it makes a difference).  The FOCUS_OUT_EVENT turns timers off, and FOCUS_IN_EVENT turns them back on, if needed.  This was discussed a long time ago, starting here:
http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00640.html.


> What am I missing?
> 
> And what is the other thing you changed?

1) Blinking stops after 10 blinks.
2) Timers are stopped when no blinking is done.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Lars Magne Ingebrigtsen]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Yes, but timers are still running, so Emacs are never swapped out, and
> drains battery on laptops (yes it makes a difference). 

Then I would suggest only turning on this functionality if the machine
is on battery power.  Surely there's a dbus message for that?

For machines that aren't on battery power, this doesn't seem like
something that users would want.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Blink cursor changes, possible W32 breakage.

[Óscar Fuentes]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>> Yes, but timers are still running, so Emacs are never swapped out, and
>> drains battery on laptops (yes it makes a difference). 
>
> Then I would suggest only turning on this functionality if the machine
> is on battery power.  Surely there's a dbus message for that?
>
> For machines that aren't on battery power, this doesn't seem like
> something that users would want.

I often access my home machine from a remote laptop with NX (you can
consider that X, to all effects on this discussion.) One of first things
I did was to turn cursor blinking off on Emacs, because every time the
cursor goes off or on, traffic is sent through the net. Energy-wise,
this is worse than a blinking cursor on a local application.

Of course, the Emacs instance running on my home machine does not know
that the remote X server is running on a laptop.

Most likely, VNC and any other remote desktop software would pose the
same problem with blinking cursors.

I'm not arguing for a specific default value for the new variable, as I
have no problem with editing my .emacs. I'm just providing some real
life experience related to this feature.

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> I'm not quite sure what the point is, though.  Perhaps it makes
>> sense on low-power devices?  To avoid screen updates?

Not just screen updates¸ but waking up the Emacs process, which changes
the CPU's power mode, etc...

>> I think the variable should default to 0.
> To keep previous behavior by default, yes.

I don't see the point of a 0 default value.  Most applications with
a blinking cursor try to stop blinking after a while, since "low power
devices" is now the norm more than the exception.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Miles Bader]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:
>> Yes, but timers are still running, so Emacs are never swapped out,
>> and drains battery on laptops (yes it makes a difference).
>
> Then I would suggest only turning on this functionality if the machine
> is on battery power.  Surely there's a dbus message for that?
>
> For machines that aren't on battery power, this doesn't seem like
> something that users would want.

It seems like rather nice behavior from a user point of view,
actually:  "active" windows will still be blinky, but "sitting in the
background forever" windows will not be.  I doubt most users will even
notice, to be honest, because they tend to focus on active windows --
and to the degree that a blinking cursor draws attention to non-active
windows, the old behavior (always blinking) is arguably a _bad_ thing.

Given that, adding all the complexity necessary to use _battery power_
as a precondition seems quite absurd...

-miles

-- 
Faith, n. Belief without evidence in what is told by one who speaks without
knowledge, of things without parallel.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Tue, 16 Jul 2013 23:12:49 +0200
> Cc: emacs-devel@gnu.org
> 
> > Sorry, I don't understand: w32 already implements the equivalent of
> > FOCUS_OUT_EVENT, but why is that relevant?  When no frame has focus,
> > Emacs on Windows doesn't blink the cursors already.
> 
> Yes, but timers are still running, so Emacs are never swapped out, and drains battery on laptops (yes it makes a difference).  The FOCUS_OUT_EVENT turns timers off, and FOCUS_IN_EVENT turns them back on, if needed.  This was discussed a long time ago, starting here:
> http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00640.html.

If you only stop the timers that blink the cursor, then this isn't
going to fix the problem.  There's any number of timers active at any
given time in any non-trivial Emacs session.  You need to stop them
all, or the battery drain will continue.

Re: Blink cursor changes, possible W32 breakage.

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
> If you only stop the timers that blink the cursor, then this isn't
> going to fix the problem.  There's any number of timers active at
> any given time in any non-trivial Emacs session.  You need to stop
> them all, or the battery drain will continue.

Is it _timers_ that cause battery drain, or _timers firing_?  I'd
imagine that with a reasonable implementation, it would be the
latter...

-miles

-- 
Sabbath, n. A weekly festival having its origin in the fact that God made the
world in six days and was arrested on the seventh.

Re: Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

17 jul 2013 kl. 06:56 skrev Miles Bader <miles@gnu.org>:

> Eli Zaretskii <eliz@gnu.org> writes:
>> If you only stop the timers that blink the cursor, then this isn't
>> going to fix the problem.  There's any number of timers active at
>> any given time in any non-trivial Emacs session.  You need to stop
>> them all, or the battery drain will continue.
> 

We can't know what other timers do, in general.  Maybe they are supposed to run some Elisp in the background and/or when the frame has no focus.  In contrast, we know very well what blinking timers are supposed to do, so we have control over those.  Default when starting Emacs, the only repeating timer is the blink timer.  To start other timers you would need to customize and/or load optional packages.

> Is it _timers_ that cause battery drain, or _timers firing_?  I'd
> imagine that with a reasonable implementation, it would be the
> latter...

You are right, it is the latter of course.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

16 jul 2013 kl. 23:23 skrev Lars Magne Ingebrigtsen <larsi@gnus.org>:

> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> Yes, but timers are still running, so Emacs are never swapped out, and
>> drains battery on laptops (yes it makes a difference). 
> 
> Then I would suggest only turning on this functionality if the machine
> is on battery power.  Surely there's a dbus message for that?

No dbus on OSX or W32.  Also dbus is not required when building Emacs.  It would not feel right to add such complexity just to reduce CPU usage.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

> Then I would suggest only turning on this functionality if the machine
> is on battery power.  Surely there's a dbus message for that?

It's also useful for many other circumstances.
It's definitely the right default.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 17 Jul 2013 09:38:32 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >> If you only stop the timers that blink the cursor, then this isn't
> >> going to fix the problem.  There's any number of timers active at
> >> any given time in any non-trivial Emacs session.  You need to stop
> >> them all, or the battery drain will continue.
> > 
> 
> We can't know what other timers do, in general.  Maybe they are supposed to run some Elisp in the background and/or when the frame has no focus.  In contrast, we know very well what blinking timers are supposed to do, so we have control over those.

But if you stop one timer, but leave the other N running, what did you
accomplish, exactly, in terms of allowing the laptop stop using
battery power and perhaps swap Emacs out of RAM?

> > Is it _timers_ that cause battery drain, or _timers firing_?  I'd
> > imagine that with a reasonable implementation, it would be the
> > latter...
> 
> You are right, it is the latter of course.

Now I'm completely confused: if blink-cursor timer doesn't drain the
battery, why should we try hard to stop it?  Why isn't it enough to
stop blinking when no Emacs frame has focus?

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 17 Jul 2013 09:42:02 +0200
> Cc: Eli Zaretskii <eliz@gnu.org>,
>  emacs-devel@gnu.org
> 
> > Then I would suggest only turning on this functionality if the machine
> > is on battery power.  Surely there's a dbus message for that?
> 
> No dbus on OSX or W32.

W32 can know if it's on a laptop without dbus.

Re: Blink cursor changes, possible W32 breakage.

[Lars Magne Ingebrigtsen]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Also dbus is not required when building Emacs.  It would not feel
> right to add such complexity just to reduce CPU usage.

I think all major distributions compile dbus into Emacs, so it's not
added complexity.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

17 jul 2013 kl. 16:56 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Wed, 17 Jul 2013 09:38:32 +0200
>> Cc: Eli Zaretskii <eliz@gnu.org>,
>> emacs-devel@gnu.org
>> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>> If you only stop the timers that blink the cursor, then this isn't
>>>> going to fix the problem.  There's any number of timers active at
>>>> any given time in any non-trivial Emacs session.  You need to stop
>>>> them all, or the battery drain will continue.
>>> 
>> 
>> We can't know what other timers do, in general.  Maybe they are supposed to run some Elisp in the background and/or when the frame has no focus.  In contrast, we know very well what blinking timers are supposed to do, so we have control over those.
> 
> But if you stop one timer, but leave the other N running, what did you
> accomplish, exactly, in terms of allowing the laptop stop using
> battery power and perhaps swap Emacs out of RAM?

In the default configuration, i.e. starting Emacs, editing files and so on, the only repeating timer there is is the blinking timer, there are no N other timers.  So for the majority of setups, this is a win.

> 
>>> Is it _timers_ that cause battery drain, or _timers firing_?  I'd
>>> imagine that with a reasonable implementation, it would be the
>>> latter...
>> 
>> You are right, it is the latter of course.
> 
> Now I'm completely confused: if blink-cursor timer doesn't drain the
> battery, why should we try hard to stop it?  Why isn't it enough to
> stop blinking when no Emacs frame has focus?

The terms used here are not clear.  When I say timer I mean when the timer fires.  The blink timer fires every 0.5 seconds, so saying "the blink timer" and "the blink timer firing" is almost the same thing.  It would be another thing for a timer that only fires every hour or so.

Emacs did not previously stop the blink timer from firing when focus was lost, hence the introduction if the FOCUS_OUT_EVENT.  Before, even if there was no visible blinking going on in any Emacs window, the timer kept firing every 0.5 seconds, running code to update the cursor state for the window.  This is the main issue, stop executing code for no reason every 0.5 seconds.

The other change, to stop blinking after 10 blinks, is a separate issue, inspired by other applications, and the comment made by Chong Yidong at http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00718.html:

> 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.

We can have focus out stopping the timer from firing without the "stopping after 10 blinks".
That is what happens if you set blink-cursor-blinks to 0.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 17 Jul 2013 18:29:46 +0200
> Cc: emacs-devel@gnu.org,
>  miles@gnu.org
> 
> >> We can't know what other timers do, in general.  Maybe they are supposed to run some Elisp in the background and/or when the frame has no focus.  In contrast, we know very well what blinking timers are supposed to do, so we have control over those.
> > 
> > But if you stop one timer, but leave the other N running, what did you
> > accomplish, exactly, in terms of allowing the laptop stop using
> > battery power and perhaps swap Emacs out of RAM?
> 
> In the default configuration, i.e. starting Emacs, editing files and so on, the only repeating timer there is is the blinking timer, there are no N other timers.  So for the majority of setups, this is a win.

I don't think it's a majority, not even close.  The only situation
that will certainly win here is "emacs -Q", but I wonder whether we
should optimize that one.

Re: Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

17 jul 2013 kl. 19:05 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Wed, 17 Jul 2013 18:29:46 +0200
>> Cc: emacs-devel@gnu.org,
>> miles@gnu.org
>> 
>>>> We can't know what other timers do, in general.  Maybe they are supposed to run some Elisp in the background and/or when the frame has no focus.  In contrast, we know very well what blinking timers are supposed to do, so we have control over those.
>>> 
>>> But if you stop one timer, but leave the other N running, what did you
>>> accomplish, exactly, in terms of allowing the laptop stop using
>>> battery power and perhaps swap Emacs out of RAM?
>> 
>> In the default configuration, i.e. starting Emacs, editing files and so on, the only repeating timer there is is the blinking timer, there are no N other timers.  So for the majority of setups, this is a win.
> 
> I don't think it's a majority, not even close.  The only situation
> that will certainly win here is "emacs -Q", but I wonder whether we
> should optimize that one.

What would those timers be for then?  I can't find a single periodic timer except blink timer that is on by default.  Also, why are you against reducing Emacs CPU-usage?  It is always a good thing IMHO, excpet when it becomes too complicated.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Jan Djärv <jan.h.d@swipnet.se>
> Date: Wed, 17 Jul 2013 20:53:04 +0200
> Cc: "emacs-devel@gnu.org developers" <emacs-devel@gnu.org>
> 
> What would those timers be for then?  I can't find a single periodic timer except blink timer that is on by default.

Like I said, I firmly believe that most Emacs users have many defaults
overridden by customizations.  Two popular timers that come to my mind
are display-time and jit-stealth.

> Also, why are you against reducing Emacs CPU-usage?

??? Who said I'm against it?  I just think that this particular change
will have almost no effect on Emacs CPU usage in any real-life
session.

Re: Blink cursor changes, possible W32 breakage.

[Jan Djärv]

Hello.

17 jul 2013 kl. 21:23 skrev Eli Zaretskii <eliz@gnu.org>:

>> From: Jan Djärv <jan.h.d@swipnet.se>
>> Date: Wed, 17 Jul 2013 20:53:04 +0200
>> Cc: "emacs-devel@gnu.org developers" <emacs-devel@gnu.org>
>> 
>> What would those timers be for then?  I can't find a single periodic timer except blink timer that is on by default.
> 
> Like I said, I firmly believe that most Emacs users have many defaults
> overridden by customizations.  Two popular timers that come to my mind
> are display-time and jit-stealth.

To be sure we would have to make a poll.  My experience differs from yours.

> 
>> Also, why are you against reducing Emacs CPU-usage?
> 
> ??? Who said I'm against it?  I just think that this particular change
> will have almost no effect on Emacs CPU usage in any real-life
> session.

Duly noted.

	Jan D.

Re: Blink cursor changes, possible W32 breakage.

[Miles Bader]

Eli Zaretskii <eliz@gnu.org> writes:
>> What would those timers be for then?  I can't find a single periodic
>> timer except blink timer that is on by default.
>
> Like I said, I firmly believe that most Emacs users have many defaults
> overridden by customizations.  Two popular timers that come to my mind
> are display-time and jit-stealth.

display-time fires once a minute, which is much better than twice a
second...

If jit-lock timers are firing too often, that could certainly be fixed
too, as there's nothing inherent about that which requires frequently
firing timers when idle (or even when active, if all jit-locking has
been completed and jit-lock'd buffers haven't changed)...

It seems sense to fix such things, even if the _immediate_ benefit
is limited because of remaining issues.  One needn't do them all at
once, and each fixed issue makes things easier in the future.

-miles

-- 
The key to happiness
 is having dreams.      [from a fortune cookie]

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Miles Bader <miles@gnu.org>
> Cc: Jan Djärv <jan.h.d@swipnet.se>,  emacs-devel@gnu.org
> Date: Fri, 19 Jul 2013 11:12:18 +0900
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> >> What would those timers be for then?  I can't find a single periodic
> >> timer except blink timer that is on by default.
> >
> > Like I said, I firmly believe that most Emacs users have many defaults
> > overridden by customizations.  Two popular timers that come to my mind
> > are display-time and jit-stealth.
> 
> display-time fires once a minute, which is much better than twice a
> second...

Mine fires every 5 seconds (because I want to see the CPU load numbers
up-to-date).

> If jit-lock timers are firing too often, that could certainly be fixed
> too, as there's nothing inherent about that which requires frequently
> firing timers when idle (or even when active, if all jit-locking has
> been completed and jit-lock'd buffers haven't changed)...
> 
> It seems sense to fix such things, even if the _immediate_ benefit
> is limited because of remaining issues.  One needn't do them all at
> once, and each fixed issue makes things easier in the future.

I'm all for doing all that, and more, to minimize CPU usage when Emacs
is idle.  My point was that _without_ a thorough fixing of at least
the most popular timer-based features, just turning off blinking will
not solve the issue at hand for all but the very basic setups.

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

> If jit-lock timers are firing too often, that could certainly be fixed
> too, as there's nothing inherent about that which requires frequently
> firing timers when idle (or even when active, if all jit-locking has
> been completed and jit-lock'd buffers haven't changed)...

Jit lock doesn't run any timers by default, AFAIK, and I expect that
fairly few users use the features that require timers (jit-lock-stealth
and jit-lock-defer).


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

> I'm all for doing all that, and more, to minimize CPU usage when Emacs
> is idle.  My point was that _without_ a thorough fixing of at least
> the most popular timer-based features, just turning off blinking will
> not solve the issue at hand for all but the very basic setups.

I'm pretty sure that the blinking cursor was by far the main problem.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Miles Bader <miles@gnu.org>, jan.h.d@swipnet.se, emacs-devel@gnu.org
> Date: Fri, 19 Jul 2013 05:33:11 -0400
> 
> > I'm all for doing all that, and more, to minimize CPU usage when Emacs
> > is idle.  My point was that _without_ a thorough fixing of at least
> > the most popular timer-based features, just turning off blinking will
> > not solve the issue at hand for all but the very basic setups.
> 
> I'm pretty sure that the blinking cursor was by far the main problem.

I'm pretty sure it is not.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: Eli Zaretskii <eliz@gnu.org>,
>         Jan Djärv
>  <jan.h.d@swipnet.se>,
>         emacs-devel@gnu.org
> Date: Fri, 19 Jul 2013 05:32:14 -0400
> 
> > If jit-lock timers are firing too often, that could certainly be fixed
> > too, as there's nothing inherent about that which requires frequently
> > firing timers when idle (or even when active, if all jit-locking has
> > been completed and jit-lock'd buffers haven't changed)...
> 
> Jit lock doesn't run any timers by default

Yes, and neither does "emacs -Q".  Like I said: we've just made 
"emacs -Q" battery-friendly.

> AFAIK, and I expect that fairly few users use the features that
> require timers (jit-lock-stealth and jit-lock-defer).

I expect most of them do use timer-dependent features all the time.

Re: Blink cursor changes, possible W32 breakage.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm pretty sure that the blinking cursor was by far the main problem.
>
> I'm pretty sure it is not.

If you describe a method for checking the existence and firing frequency
of timers, we could check and report results.

Re: Blink cursor changes, possible W32 breakage.

[Lars Magne Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I'm pretty sure that the blinking cursor was by far the main problem.
>
> I'm pretty sure it is not.

I've done an strace of various Emacs sessions, and it seems like without
the cursor blinking, Emacs stays pretty quiet.  The main other offender
seems to be the gnutls polling code, apparently.  But I'm not quite sure
of that.  It's something that's triggering when there are open network
connections, but I haven't tracked down what, exactly.

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 19 Jul 2013 12:50:24 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I'm pretty sure that the blinking cursor was by far the main problem.
> >
> > I'm pretty sure it is not.
> 
> If you describe a method for checking the existence and firing frequency
> of timers, we could check and report results.

Does anyone really care?

Anyway, look at timer-list and timer-idle-list.  There are also async
timers (see atimer.c), but I think those are only visible from C, so
put a breakpoint in run_timers and see when it breaks.

Re: Blink cursor changes, possible W32 breakage.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> If you describe a method for checking the existence and firing frequency
>> of timers, we could check and report results.
>
> Does anyone really care?

That's the topic of this thread.

> Anyway, look at timer-list and timer-idle-list.  There are also async
> timers (see atimer.c), but I think those are only visible from C, so
> put a breakpoint in run_timers and see when it breaks.

Thanks.

On the GNU/Linux machine I'm writing this message, C-h v shows this:

timer-list is a variable defined in `C source code'.
Its value is shown below.

Documentation:
List of active absolute time timers in order of increasing time.

Value: ([nil 20969 10565 915710 nil password-cache-remove
      ("auth-source-magic (:max 1 :host (\"news.gmane.org\" \"news.gmane.org\") :port (\"119\" \"nntp\" \"nntp\" \"563\" \"nntps\" \"snews\"))")
      nil 306000]
 [nil 20969 10565 919267 nil password-cache-remove
      ("auth-source-magic (:port 110 :user <removed> :host <removed> :max 1)")
      nil 623000]
 [nil 20969 10566 330944 nil password-cache-remove
      ("auth-source-magic (:port 110 :user <removed> :host <removed> :max 1)")
      nil 87000]
 [nil 20969 12911 430882 nil password-cache-remove
      ("auth-source-magic (:max 1 :host (\"news.sunsite.dk\" \"news.sunsite.dk\") :port (\"119\" \"nntp\" \"nntp\" \"563\" \"nntps\" \"snews\"))")
      nil 504000])


(I edited out some personal information.)

Those timers remain after quitting Gnus.

timer-idle-list contains

 ([t 0 0 125000 t show-paren-function nil idle 0]
 [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])


On Windows machine, timer-list is empty (I don't run Gnus there.)
timer-idle-list is the same as in the GNU/Linux machine:

([t 0 0 125000 t show-paren-function nil idle 0]
 [nil 0 0 500000 t jit-lock-context-fontify nil idle 0])

Right now I have no time for running a gdb session for monitoring
run_timers. I'll do if there is interest on seeing the results.

This is some state information taken from M-x report-emacs-bug on the
GNU/Linux machine. As you can see, it is far from being emacs -Q :


Configured using:
 `configure --without-toolkit-scroll-bars --with-x-toolkit=lucid'

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Message

Minor modes in effect:
  shell-dirtrack-mode: t
  gnus-message-citation-mode: t
  mml-mode: t
  TeX-PDF-mode: t
  show-paren-mode: t
  diff-auto-refine-mode: t
  flx-ido-mode: t
  ido-everywhere: t
  evil-mode: t
  evil-local-mode: t
  global-undo-tree-mode: t
  undo-tree-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  auto-fill-function: message-do-auto-fill
  abbrev-mode: t

Load-path shadows:
~/elisp/magit/magit hides /usr/local/share/emacs/site-lisp/magit
~/elisp/magit/.dir-locals hides /usr/local/share/emacs/24.3.50/lisp/gnus/.dir-locals
~/elisp/evil/lib/ert hides /usr/local/share/emacs/24.3.50/lisp/emacs-lisp/ert

Features:
(shadow emacsbug calculator face-remap gnus-dup vc-annotate find-dired
ibuf-ext ibuffer arc-mode archive-mode org-element mule-util cal-move vc
vc-dispatcher pcmpl-unix shr-color color shr solar cal-dst gnus-fun
mailalias cc-langs cc-mode cc-fonts cc-guess cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs browse-url tabify zone view
org-indent org-wl org-w3m org-vm org-rmail org-mhe org-mew org-irc
org-jsinfo org-infojs org-html org-exp ob-exp org-exp-blocks org-agenda
org-info org-gnus org-docview org-bibtex bibtex org-bbdb jka-compr shell
ses unsafep flow-fill qp canlock dabbrev nnir misearch multi-isearch
sort smiley gnus-cite mm-archive mail-extr gnus-bcklg gnus-async gnus-ml
pop3 nndraft nnmh nnml nnfolder parse-time netrc network-stream starttls
tls gnus-agent gnus-srvr gnus-score score-mode nnvirtual gnus-msg
gnus-art mm-uu mml2015 mm-view mml-smime smime dig mailcap nntp
gnus-cache gnus-sum nnoo gnus-group gnus-undo nnmail mail-source
smtpmail sendmail gnus-start gnus-spec gnus-int gnus-range message
rfc822 mml mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mailabbrev gmm-utils mailheader gnus-win gnus
gnus-ems nnheader mail-utils em-unix em-term term disp-table ehelp
electric em-script em-prompt em-ls em-hist em-pred em-glob em-dirs
em-cmpl em-basic em-banner em-alias esh-var esh-io esh-cmd esh-opt
esh-ext esh-proc esh-arg eldoc esh-groups eshell esh-module esh-mode
esh-util cus-edit cus-start cus-load sh-script smie executable crm debug
whitespace etags-select etags org-crypt org ob-tangle ob-ref ob-lob
ob-table org-footnote org-src ob-comint ob-keys org-pcomplete pcomplete
org-list org-faces org-entities noutline outline org-version
ob-emacs-lisp ob org-compat org-macs ob-eval org-loaddefs format-spec
find-func cal-menu calendar cal-loaddefs preview prv-emacs info reporter
desktop latex tex-style tex-buf tex tex-site auto-loads lp0-mode paren
uniquify paredit-menu server yasnippet dropdown-list help-mode psvn
wid-edit pp elp ediff-merg ediff-wind ediff-diff ediff-mult ediff-help
ediff-init ediff-util dired vc-git magit-cherry magit-bisect
magit-key-mode magit grep compile comint ansi-color diff-mode log-edit
easymenu pcvs-util add-log epa epg epg-config flx-ido flx ido
ace-jump-mode evil-paredit paredit evil evil-integration warnings
evil-maps evil-commands ffap thingatpt url-parse auth-source eieio
byte-opt bytecomp byte-compile cconv eieio-core gnus-util time-date
mm-util mail-prsvr password-cache url-vars evil-types evil-search
evil-ex evil-macros evil-repeat evil-states evil-core evil-common
undo-tree derived easy-mmode cl-macs gv diff cl cl-loaddefs cl-lib
windmove rect evil-digraphs evil-vars ring edmacro kmacro
solarized-dark-theme solarized nadvice advice help-fns tooltip
ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer loaddefs button faces cus-face macroexp files text-properties
overlay sha1 md5 base64 format env code-pages mule custom widget
hashtable-print-readable backquote make-network-process gfilenotify
dynamic-setting system-font-setting font-render-setting x-toolkit x
multi-tty emacs)

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Fri, 19 Jul 2013 14:02:20 +0200
> 
> On the GNU/Linux machine I'm writing this message, C-h v shows this:

Thanks.

But I think this whole line of approaching this subject is
fundamentally wrong.

The issue eventually boils down to this: do we want Emacs to be
friendly to laptop batteries, or do we want it not to blink the
cursor?  If the latter, then making blink-cursor off by default is all
we need.  No need for binding frame-focus events or anything like
that.

By contrast, if we want the former, then we need an _infrastructure_
that would make it easy to stop all or just some of the timers from
firing when Emacs is idle, or doesn't have focus, or the machine runs
on batteries, or whatever else condition is deemed appropriate.  It
doesn't matter how many users really run such timers, because even if
there's just one user with just one such timer, the fact that Emacs is
running that timer when that user's laptop is on batteries will be a
bug for that single user of that one timer.

Re: Blink cursor changes, possible W32 breakage.

[Thien-Thi Nguyen]

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

() Eli Zaretskii <eliz@gnu.org>
() Fri, 19 Jul 2013 16:43:45 +0300

   The issue eventually boils down to this: do we want Emacs to be
   friendly to laptop batteries, or do we want it not to blink the
   cursor? 

My 2c: I would like Emacs to be as quiescent as possible, powerful on
demand, but otherwise unassuming.  My (old) computer struggles w/
recent Emacs as it is.  That said, i do not use Emacs w/o ~/.emacs;
"reasonable" required tweaks i would understand and condone.

-- 
Thien-Thi Nguyen
   GPG key: 4C807502
   (if you're human and you know it)
      read my lisp: (responsep (questions 'technical)
                               (not (via 'mailing-list)))
                     => nil

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> AFAIK, and I expect that fairly few users use the features that
>> require timers (jit-lock-stealth and jit-lock-defer).
> I expect most of them do use timer-dependent features all the time.

Why?


        Stefan


PS: jit-lock-defer is actually not in the same boat since it only uses
    an idle-timer, so it doesn't keep firing over and over again while
    Emacs is idle for long periods.

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

> By contrast, if we want the former, then we need an _infrastructure_
> that would make it easy to stop all or just some of the timers from
> firing when Emacs is idle, or doesn't have focus, or the machine runs
> on batteries, or whatever else condition is deemed appropriate.

AFAICT, most timers are already pretty friendly: all idle-timers are
friendly, so only the repeated non-idle timers are problematic.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sat, 20 Jul 2013 04:18:34 -0400
> Cc: Óscar Fuentes <ofv@wanadoo.es>, emacs-devel@gnu.org
> 
> > By contrast, if we want the former, then we need an _infrastructure_
> > that would make it easy to stop all or just some of the timers from
> > firing when Emacs is idle, or doesn't have focus, or the machine runs
> > on batteries, or whatever else condition is deemed appropriate.
> 
> AFAICT, most timers are already pretty friendly: all idle-timers are
> friendly, so only the repeated non-idle timers are problematic.

So you are saying that just turning off blink-cursor is good enough?
OK, then let's do that and stop talking about timers and stuff.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Date: Sat, 20 Jul 2013 04:16:24 -0400
> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org, miles@gnu.org
> 
> >> AFAIK, and I expect that fairly few users use the features that
> >> require timers (jit-lock-stealth and jit-lock-defer).
> > I expect most of them do use timer-dependent features all the time.
> 
> Why?

You didn't give any reasons for your assertions, either.

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> >> AFAIK, and I expect that fairly few users use the features that
>> >> require timers (jit-lock-stealth and jit-lock-defer).
>> > I expect most of them do use timer-dependent features all the time.
>> Why?
> You didn't give any reasons for your assertions, either.

No, indeed, but they're not activated unless the user asks for
it explicitly.  Also jit-lock-stealth used to be enabled by default but
was disabled because too many people found it problematic, so only those
people who don't care about high/excessive background CPU usage will
have it enabled.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> AFAICT, most timers are already pretty friendly: all idle-timers are
>> friendly, so only the repeated non-idle timers are problematic.
> So you are saying that just turning off blink-cursor is good enough?

I'm just saying that it's important to avoid constantly blinking the
cursor because it's the number 1 timer firing in an idle Emacs.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org, miles@gnu.org
> Date: Sat, 20 Jul 2013 18:40:42 -0400
> 
> >> >> AFAIK, and I expect that fairly few users use the features that
> >> >> require timers (jit-lock-stealth and jit-lock-defer).
> >> > I expect most of them do use timer-dependent features all the time.
> >> Why?
> > You didn't give any reasons for your assertions, either.
> 
> No, indeed, but they're not activated unless the user asks for
> it explicitly.

I don't see how this is relevant.  Are we going to tell users not to
enable features if they want Emacs to be friendly to the batteries?
That's not going to happen.

> Also jit-lock-stealth used to be enabled by default but was disabled
> because too many people found it problematic, so only those people
> who don't care about high/excessive background CPU usage will have
> it enabled.

JIT Stealth has a variable to limit the system load it imposes; mine
is set to 20%.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Sat, 20 Jul 2013 18:42:12 -0400
> 
> >> AFAICT, most timers are already pretty friendly: all idle-timers are
> >> friendly, so only the repeated non-idle timers are problematic.
> > So you are saying that just turning off blink-cursor is good enough?
> 
> I'm just saying that it's important to avoid constantly blinking the
> cursor because it's the number 1 timer firing in an idle Emacs.

If it's not the _only_ timer we care about, its being no. 1 is
immaterial, because we need a solution for the rest as well.

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> No, indeed, but they're not activated unless the user asks for
>> it explicitly.
> I don't see how this is relevant.

It's relevant because most optional features are turned off.

> Are we going to tell users not to enable features if they want Emacs
> to be friendly to the batteries?  That's not going to happen.

jit-lock-stealth is pretty clearly battery unfriendly.  It's in its nature.

>> Also jit-lock-stealth used to be enabled by default but was disabled
>> because too many people found it problematic, so only those people
>> who don't care about high/excessive background CPU usage will have
>> it enabled.
> JIT Stealth has a variable to limit the system load it imposes; mine
> is set to 20%.

Yes, we did try to make jit-lock-stealth work acceptably, but after many
attempts, we chose to turn it off instead because there's always some
situation where it consumes a lot more CPU than what you'd want.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

> If it's not the _only_ timer we care about, its being no. 1 is
> immaterial, because we need a solution for the rest as well.

No.  The problem depends on many factors, such as the frequency at which
it fires while Emacs is otherwise idle, as well as whether it's
a commonly used feature or not.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[martin rudalics]

 > ... they're not activated unless the user asks for
 > it explicitly.

`jit-lock-context-timer' is activated here though I never asked for it
"explicitly".

 > Also jit-lock-stealth used to be enabled by default but
 > was disabled because too many people found it problematic, so only those
 > people who don't care about high/excessive background CPU usage will
 > have it enabled.

I'm too silly to understand: Don't we talk about the case where Emacs
remains idle?  Shouldn't these timers trigger once only after that
happened?

martin

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: jan.h.d@swipnet.se, emacs-devel@gnu.org, miles@gnu.org
> Date: Sun, 21 Jul 2013 03:45:50 -0400
> 
> >> No, indeed, but they're not activated unless the user asks for
> >> it explicitly.
> > I don't see how this is relevant.
> 
> It's relevant because most optional features are turned off.

Don't we care about optional features anymore, if, when turned on,
they cause trouble?  Don't we want users to be able to turn those
optional features on without suffering adverse consequences that we
can prevent?

> > Are we going to tell users not to enable features if they want Emacs
> > to be friendly to the batteries?  That's not going to happen.
> 
> jit-lock-stealth is pretty clearly battery unfriendly.  It's in its nature.

Any program, when it works and burns CPU cycles, is battery
unfriendly.  The issue we are discussing here is whether it would be a
good idea to turn such features off under some conditions.

> Yes, we did try to make jit-lock-stealth work acceptably, but after many
> attempts, we chose to turn it off instead because there's always some
> situation where it consumes a lot more CPU than what you'd want.

Not here, it doesn't.

Re: Blink cursor changes, possible W32 breakage.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@IRO.UMontreal.CA>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Sun, 21 Jul 2013 03:46:52 -0400
> 
> > If it's not the _only_ timer we care about, its being no. 1 is
> > immaterial, because we need a solution for the rest as well.
> 
> No.  The problem depends on many factors, such as the frequency at which
> it fires while Emacs is otherwise idle, as well as whether it's
> a commonly used feature or not.

Are we going to fix bugs and misfeatures only for commonly used
features?  I thought any feature that has a bug or misfeature deserves
that it be fixed, and that how popular it is plays no real role in
that.

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> >> No, indeed, but they're not activated unless the user asks for
>> >> it explicitly.
>> > I don't see how this is relevant.
>> It's relevant because most optional features are turned off.
> Don't we care about optional features anymore, if, when turned on,
> they cause trouble?

jit-lock-stealth is a performance tradeoff, burning more CPU cycles in
the hope of sometimes providing better interactive behavior.

So "keeping Emacs running when it's apparently idle" is not "trouble".

> Don't we want users to be able to turn those optional features on
> without suffering adverse consequences that we can prevent?

I don't think we can prevent them for jit-lock-stealth.
We could try and detect when there's nothing more to font-lock and
disable the timer at that point.  But it's very far form the top of the
priority.

>> > Are we going to tell users not to enable features if they want Emacs
>> > to be friendly to the batteries?  That's not going to happen.
>> jit-lock-stealth is pretty clearly battery unfriendly.  It's in its nature.
> Any program, when it works and burns CPU cycles, is battery
> unfriendly.

jit-lock-stealth does "eager fontification", which implies doing
unnecessary work.  It's a form of speculation.  So it's not just like
"any program".

> The issue we are discussing here is whether it would be a
> good idea to turn such features off under some conditions.

Well, we already turn it off in all circumstances except those where the
user explicitly requests to turn it on, so I thiunk we cover the 99% of
the needs in this area.

>> Yes, we did try to make jit-lock-stealth work acceptably, but after many
>> attempts, we chose to turn it off instead because there's always some
>> situation where it consumes a lot more CPU than what you'd want.
> Not here, it doesn't.

You're just lucky not to hit the problematic cases.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> > If it's not the _only_ timer we care about, its being no. 1 is
>> > immaterial, because we need a solution for the rest as well.
>> No.  The problem depends on many factors, such as the frequency at which
>> it fires while Emacs is otherwise idle, as well as whether it's
>> a commonly used feature or not.
> Are we going to fix bugs and misfeatures only for commonly used
> features?

No, but they do get a higher priority.  I'm not sure exactly why you're
arguing about this.


        Stefan

Re: Blink cursor changes, possible W32 breakage.

[Stefan Monnier]

>> ... they're not activated unless the user asks for
>> it explicitly.
> `jit-lock-context-timer' is activated here though I never asked for it
> "explicitly".

Indeed context refontification is enabled by default, but that's only an
idle timer, so it shouldn't keep firing repeatedly while Emacs is idle.

>> Also jit-lock-stealth used to be enabled by default but
>> was disabled because too many people found it problematic, so only those
>> people who don't care about high/excessive background CPU usage will
>> have it enabled.
> I'm too silly to understand: Don't we talk about the case where Emacs
> remains idle?  Shouldn't these timers trigger once only after that
> happened?

No, the jit-lock-stealth code keeps on running for a potentially long
time after Emacs became idle (IIRC it uses a while-input-pending-p kind
of loop).  But yes, the timer only triggers once.


        Stefan