Intelligent handling of interrupted communication

Intelligent handling of interrupted communication

[Hrvoje Niksic]

Due to a bug on the newsserver here, articles are often being posted
for very long times -- say, half an hour.  Luckily, this condition is
handled when I press C-g after a few sedonds; the article still gets
posted to whatever group.  However, it is impossible to access the
newsserver afterwards (e.g. read another article) -- I have to
evaluate (nntp-close-server) manually after the C-g.  This is all
bearable -- after all, tin provides you with no exit but C-z + kill +
restart in that situation.

However, the latest slrn release, when I press C-g in the very same
situation, I get an "Error writing to server" error, and the following 
query in the minibuffer:

  Select one: R-epost, E-dit, C-ancel[1]

Personally, this is most cool.  With Gnus, C-g gives me just `Edit'.
Furthermore, the `Cancel' choice correctly handles reconnecting to the 
newsserver (no need for the equivalent of `M-: (nntp-close-server) RET'.


Aside from my very specific situation, I can think of a number of
cases where intelligent handling of interrupted communication with the
news server would come in very handy.  Since this is Emacs, all it
would take is an intelligent `quit' condition-case catcher.

Would it be consider useful enough for Gnus?  Would it be possible to
implement cleanly, given the current abstraction model?



[1]
Note: `Cancel' here has nothing to do with article canceling.

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
"Psychos _do not_ explode when sunlight hits them."

Re: Intelligent handling of interrupted communication

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Aside from my very specific situation, I can think of a number of
> cases where intelligent handling of interrupted communication with the
> news server would come in very handy.  Since this is Emacs, all it
> would take is an intelligent `quit' condition-case catcher.
> 
> Would it be consider useful enough for Gnus?  Would it be possible to
> implement cleanly, given the current abstraction model?

Yes, I think so.  We could just catch the `quit' in Message and close
the connection if it was found.

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

Re: Intelligent handling of interrupted communication

[Hrvoje Niksic]

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

> Hrvoje Niksic <hniksic@srce.hr> writes:
> 
> > Aside from my very specific situation, I can think of a number of
> > cases where intelligent handling of interrupted communication with the
> > news server would come in very handy.  Since this is Emacs, all it
> > would take is an intelligent `quit' condition-case catcher.
> > 
> > Would it be consider useful enough for Gnus?  Would it be possible to
> > implement cleanly, given the current abstraction model?
> 
> Yes, I think so.  We could just catch the `quit' in Message and close
> the connection if it was found.

Would this handle server types other than `nntp' correctly?

-- 
Hrvoje Niksic <hniksic@srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
`VI' - An editor used by those heretics that don't subscribe to
       the Emacs religion.

Re: Intelligent handling of interrupted communication

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > Yes, I think so.  We could just catch the `quit' in Message and close
> > the connection if it was found.
> 
> Would this handle server types other than `nntp' correctly?

Sure.  All backends supply `*-close-server'.  For most of them it's a
no-op, though.

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