Re: [gareth.jones@stud.man.ac.uk: Re: pop3-read-response not robust in the presence of timers]

Re: [gareth.jones@stud.man.ac.uk: Re: pop3-read-response not robust in the presence of timers]

[Richard Stallman]

    Since this is mainly a problem connected to `accept-process-output',
    would it make sense to just add `save-buffer-excursion' or the
    like to that function?  Does it ever make sense for
    `accept-process-output' to allow the current buffer to be changed?

That is an interesting question.  I think this user wants to invoke
Gnus from a timer and wants it to switch buffers.  But perhaps it only
needs to switch buffers in some windows; perhaps it would be ok to
preserve the current buffer.

However, accept-process-output is not the only function that allows
timers to run.  So do read-event and read-key-sequence.  It would
be unnatural for only accept-process-output to preserve the current
buffer.  We would want to change them all.  That is somewhat more
radical.  Still, it might be an improvement.

Re: [gareth.jones@stud.man.ac.uk: Re: pop3-read-response not robust in the presence of timers]

[Lars Magne Ingebrigtsen]

Richard Stallman <rms@gnu.org> writes:

> That is an interesting question.  I think this user wants to invoke
> Gnus from a timer and wants it to switch buffers.  But perhaps it only
> needs to switch buffers in some windows; perhaps it would be ok to
> preserve the current buffer.
>
> However, accept-process-output is not the only function that allows
> timers to run.  So do read-event and read-key-sequence.  It would
> be unnatural for only accept-process-output to preserve the current
> buffer.  We would want to change them all.  That is somewhat more
> radical.  Still, it might be an improvement.

The ramifications for altering `read-event' and `read-key-sequence'
are a bit out of my scope, but I can't (at the moment) think of any
instances where it would be natural for the current buffer to be one
thing before they are called and another afterwards.

One could also approach this from the opposite side -- slapping (the
equivalent of) `save-buffer-excursion' around the timer functions
(and possibly also `after-change-functions' and all those other
functions that get run "asynchronously").

-- 
(domestic pets only, the antidote for overdose, milk.)
   larsi@gnus.org * Lars Magne Ingebrigtsen

Re: [gareth.jones@stud.man.ac.uk: Re: pop3-read-response not robust in the presence of timers]

[Richard Stallman]

    One could also approach this from the opposite side -- slapping (the
    equivalent of) `save-buffer-excursion' around the timer functions

That would be one way to implement it for all the functions that can
run timers, including accept-process-output, read-event and
read-key-sequence.  Still, the question is, is it ok to make the change
that timers can't change the current buffer.

Can anyone think of a situation where this would be a problem?  Would
someone like to look through the code base and see if any timer needs
to change the current buffer?

Re: [gareth.jones@stud.man.ac.uk: Re: pop3-read-response not robust in the presence of timers]

[Kai Großjohann]

Richard Stallman <rms@gnu.org> writes:

>     One could also approach this from the opposite side -- slapping (the
>     equivalent of) `save-buffer-excursion' around the timer functions
>
> That would be one way to implement it for all the functions that can
> run timers, including accept-process-output, read-event and
> read-key-sequence.

I think Lars' suggestion was to slap the functions that are run from
the timers, instead of the functions that run the timers.

So you take a sharp look at the foo function which is run from a
timer.  You see that foo doesn't need to buffer changed, so you slap
it.  Bad foo!  8-)
-- 
file-error; Data: (Opening input file no such file or directory ~/.signature)

Re: [gareth.jones@stud.man.ac.uk: Re: pop3-read-response not robust in the presence of timers]

[Richard Stallman]

    >     One could also approach this from the opposite side -- slapping (the
    >     equivalent of) `save-buffer-excursion' around the timer functions
    >
    > That would be one way to implement it for all the functions that can
    > run timers, including accept-process-output, read-event and
    > read-key-sequence.

    I think Lars' suggestion was to slap the functions that are run from
    the timers, instead of the functions that run the timers.

That is more or less what I originally proposed, I think.
The reason I think Lars meant changing the C code is the words
"the equivalent of".

Anyway, regardless of what Lars had in mind, the idea of making the C
code to run timers also preserve the current buffer is an idea
worth considering.