From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.devel Subject: Re: C-g while exiting the minibuffer Date: Sat, 30 Nov 2013 13:16:47 +0100 Message-ID: <5299D72F.7060902@gmx.at> References: <52977725.50800@gmx.at> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1385813840 30896 80.91.229.3 (30 Nov 2013 12:17:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 30 Nov 2013 12:17:20 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Nov 30 13:17:22 2013 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VmjUA-0002X1-Cw for ged-emacs-devel@m.gmane.org; Sat, 30 Nov 2013 13:17:22 +0100 Original-Received: from localhost ([::1]:51781 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmjU9-0002Ie-TZ for ged-emacs-devel@m.gmane.org; Sat, 30 Nov 2013 07:17:21 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmjTn-0001wV-FJ for emacs-devel@gnu.org; Sat, 30 Nov 2013 07:17:06 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VmjTg-0002fb-5i for emacs-devel@gnu.org; Sat, 30 Nov 2013 07:16:59 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:63412) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VmjTf-0002eY-Rr for emacs-devel@gnu.org; Sat, 30 Nov 2013 07:16:52 -0500 Original-Received: from [62.47.61.47] ([62.47.61.47]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MZTP3-1W2tJv3g7B-00LCV7 for ; Sat, 30 Nov 2013 13:16:51 +0100 In-Reply-To: X-Provags-ID: V03:K0:ceHE89NEwZiQGCGIAzCLstp11dqEerplpz4TEgPwMa5psH5b14P 92x+j5MfTCpJCmVZwAIQeRk4A2iCXTrwqgPH374uLMelLpPdRINcZ7tgKTwA9JaYCL1cYOg +anNqldBgZxDTBppsnPiMwILLqr4TZZAIFq8BjAcbdbXwAeWM7vPjmbuafc5PQxpPGcW98M rgH2RZBWlmyoUrhExHRTw== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.4.x-2.6.x [generic] X-Received-From: 212.227.17.22 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:165934 Archived-At: > But the problem remains of what to do with a C-g interrupting a unwind > form: in the case of an Fset_window_configuration in an unwind form, the > intention is to make that "no matter what happens, we end up recovering > the original state", but a C-g at the wrong time will break this promise. I'm afraid that C-g at the wrong time might produce an inconsistent state which IMO seems more fatal than a non-original state. > - we used to have a "DOLIST" kind of macro which did the hare/tortoise > thing in lisp.h. Not sure what happened to it, but I'd rather use > such a macro then duplicate the corresponding code wherever we have > such a loop. Agreed. > - checking cycles here gives us no guarantee since the caller can do > > (set-window-prev-buffers w bufs) > (setcdr bufs bufs) > > and you again end up with a cycle in your window-prev-buffers. Right. So we'd need a safe implementation of delq and I wouldn't know how to do that reasonably via DOLIST. I'd rather use a simple routine to find out whether the original argument list of delq is infinite (if we think this could be a real problem). martin