emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Daniel Colascione
Subject: Re: Power: blink-cursor-mode is a pig
Date: Fri, 30 Dec 2011 01:20:45 -0800
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:8.0) Gecko/20111105 Thunderbird/8.0

On 12/30/11 1:10 AM, Eli Zaretskii wrote:
>> Date: Thu, 29 Dec 2011 15:54:50 -0800
>> From: Daniel Colascione <address@hidden>
>>
>> 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: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]