bug#25606: [DRAFT PATCH 2/2] Signal list cycles in ‘length’ etc.

[Eli Zaretskii]

> Cc: 25606@debbugs.gnu.org
> From: Paul Eggert <eggert@cs.ucla.edu>
> Date: Thu, 2 Feb 2017 15:01:16 -0800
> 
> On 02/02/2017 09:28 AM, Eli Zaretskii wrote:
> 
> > could we please have tests for these functions?
> Good point, I'll look into adding some.

Thanks.

> > I think we shouldn't second-guess users this way, and
> > should always leave them the possibility of interrupting a possibly
> > prolonged calculation.
> 
> Sure, but we shouldn't insert maybe_quit calls after every nanosecond's 
> worth of computation; that'd be overkill and would slow down Emacs 
> unnecessarily.

No, not that frequently, I agree.  So perhaps rarely_quit is a better
possibility in these places.

But in general, data structures on which these primitives work could
be rather large, and processing them could take a tangible amount of
time.  Moreover, on a memory-starved system or a system under heavy
computational load, the processing could take a long elapsed time even
if the CPU time used by Emacs is very small.  Users get annoyed by
elapsed time, because that's what they perceive.  So making these
uninterruptible except in case of glaring bugs sounds like losing a
valuable fire escape to me.

> We should insert a maybe_quit call only when Emacs may have done
> enough computation that it would be annoying if the user typed C-g
> and Emacs did not respond for that period of time.

Sure.  But do we have a reliable device to measure this quantity?
Once again, the elapsed time tends to annoy users regardless of the
real computational resources used by Emacs.

IOW, the removal is probably justified for 90% of use cases, maybe
even more, but it could be a problem for a small fraction of use
cases.  And since quitting is a kind of zero-level troubleshooting in
Emacs, I think we should be biased towards those rare cases here.