GNU bug report logs - #57684
locked narrowing breaks existing code without an apparent way to repair

Previous Next

Full log

Message #41 received at 57684 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Pogonyshev <pogonyshev <at> gmail.com>
Cc: gregory <at> heytings.org, larsi <at> gnus.org, 57684 <at> debbugs.gnu.org
Subject: Re: bug#57684: locked narrowing breaks existing code without an
 apparent way to repair
Date: Wed, 14 Sep 2022 14:57:11 +0300

> From: Paul Pogonyshev <pogonyshev <at> gmail.com>
> Date: Wed, 14 Sep 2022 11:45:01 +0200
> Cc: Gregory Heytings <gregory <at> heytings.org>, Lars Ingebrigtsen <larsi <at> gnus.org>, 57684 <at> debbugs.gnu.org
> 
> By the way, it would really be nice if Emacs could do something about hangs irrespective of what causes
> that. Even if Elisp code is buggy, Emacs itself should never allow it to fall into an infinite loop and stop
> responding to C-g, leaving full restart as the only way out.

I think that's impossible in general, unless we restrict what Lisp
programs can do.  Every programming language can be used to write a
buggy program.

However, it should be possible to prevent some cases of such
problematic behavior, certainly so when the infloop is caused by our
bug.  But for that we need to know the details of the specific case in
order to investigate.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.