Should timers run in the initial frame?

Should timers run in the initial frame?

[Adam Porter]

Hi,

I've learned that Emacs timers run in the context of whichever frame
was most recently active.  This is typically fine, but I've found a
situation in which this may cause problems.

In my new frame-purpose.el package, the buffer-list function is
overridden to only return buffers in the current frame (when
frame-purpose-mode is active, and the frame has a predicate defined in
its parameter list).  This makes it easy to have "purposeful" frames,
because in so-configured frames, commands like ibuffer will only
display buffers matching the configured predicate.

This seems to work fine, but I have noticed that buffer-list gets
called quite often in timers (at least, in my config).  Some of those
timers may do important work, like automatically saving buffers,
network-related tasks that depend on buffers, etc.

So when frame-purpose-mode is active, and the current Emacs frame is a
"purposeful" frame (i.e. not the frame Emacs initially opened, which
has no predicate configured), any timers that fire which iterate over
the result of buffer-list will not see all buffers in the Emacs
process, but only ones matching the frame's predicate.  Thankfully,
real-auto-save-mode (which I use) keeps its own internal list of
buffers, rather than calling buffer-list each time its timer fires.
But I would guess that there are a variety of packages which do
iterate over buffer-list on a timer.

So, I wonder: would it be good if timers ran in the context of the
initially opened Emacs frame, rather than in whichever frame was most
recently active?

Of course, this is likely not a problem for anyone who's not using
frame-purpose.el, i.e. nearly all Emacs users.  However, this might
make Emacs a bit more robust and allow packages like frame-purpose.el
to customize behavior more safely.

Thanks,
Adam

Re: Should timers run in the initial frame?

[Stefan Monnier]

> So, I wonder: would it be good if timers ran in the context of the
> initially opened Emacs frame, rather than in whichever frame was most
> recently active?

Elisp code has a lot of context, and which context needs to be saved
depends on ...hmm... context.

I don't think it can break anything to do what you suggest, but it's
a slippery slope: we could also try and preserve the current buffer,
selected window, ...

The specific problem in your case is that the change your package
imposes on buffer-list is pretty drastic (the original semantics of
buffer-list is to return *all* buffers) and inevitably introduces bugs
(e.g. some buffer-local minor modes use a global timer shared between
all buffers (and relying buffer-list for that), so you'd need to either
restore the original buffer-list for those particular uses, or advise
those minor modes such that use a "frame-purpose-local" variable instead
of a global variable for the timer).

So I think it makes more sense to add this particular workaround in your
package (e.g. by advising timer-set-function).


        Stefan

Re: Should timers run in the initial frame?

[Daniel Colascione]

On 06/11/2018 08:42 AM, Stefan Monnier wrote:
>> So, I wonder: would it be good if timers ran in the context of the
>> initially opened Emacs frame, rather than in whichever frame was most
>> recently active?
> 
> Elisp code has a lot of context, and which context needs to be saved
> depends on ...hmm... context.
> 
> I don't think it can break anything to do what you suggest, but it's
> a slippery slope: we could also try and preserve the current buffer,
> selected window, ...
> 
> The specific problem in your case is that the change your package
> imposes on buffer-list is pretty drastic (the original semantics of
> buffer-list is to return *all* buffers)

I suppose we could expose running_asynch_code to lisp so that modes like 
the OP's would know to turn off some of their customization.