From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Newsgroups: gmane.emacs.devel Subject: RE: while-no-input Date: Mon, 29 Nov 2004 15:30:51 +0100 Message-ID: <1B3ACCFD5694A94DBA4E231402B0E9ED57AEC2@mucmail1.sdm.de> NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Trace: sea.gmane.org 1101738695 16763 80.91.229.6 (29 Nov 2004 14:31:35 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 29 Nov 2004 14:31:35 +0000 (UTC) Cc: emacs-devel@gnu.org, storm@cua.dk Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Nov 29 15:31:28 2004 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1CYmYp-0006rc-00 for ; Mon, 29 Nov 2004 15:31:27 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CYmiD-0003LV-MR for ged-emacs-devel@m.gmane.org; Mon, 29 Nov 2004 09:41:09 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.33) id 1CYmhr-0003KP-7z for emacs-devel@gnu.org; Mon, 29 Nov 2004 09:40:47 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.33) id 1CYmhp-0003JQ-Dm for emacs-devel@gnu.org; Mon, 29 Nov 2004 09:40:45 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.33) id 1CYmhp-0003JG-5N for emacs-devel@gnu.org; Mon, 29 Nov 2004 09:40:45 -0500 Original-Received: from [192.76.162.229] (helo=world1.sdm.de) by monty-python.gnu.org with esmtp (Exim 4.34) id 1CYmYJ-0003Xz-CH; Mon, 29 Nov 2004 09:30:55 -0500 Original-Received: from localhost ([127.0.0.1] helo=world1.sdm.de) by world1.sdm.de (MTA) via esmtp id 1CYmYI-0001vF-O8; Mon, 29 Nov 2004 15:30:54 +0100 Original-Received: from mucns1.muc.sdm.de ([193.102.180.22]) by world1.sdm.de (MTA) via esmtp id 1CYmYG-0001v9-Hn; Mon, 29 Nov 2004 15:30:52 +0100 Original-Received: by mucns1.muc.sdm.de (MTA) via esmtp from localhost ([127.0.0.1] helo=sdmmail1.sdm.de) id 1CYmYG-0005st-GE; Mon, 29 Nov 2004 15:30:52 +0100 Original-Received: from mucmail1.sdm.de ([193.102.180.175]) by sdmmail1.sdm.de with Microsoft SMTPSVC(6.0.3790.0); Mon, 29 Nov 2004 15:30:51 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: while-no-input Thread-Index: AcTWHpe/qSH4jt32Rv6TCZVIE7hPagAAFJzw Original-To: , X-OriginalArrivalTime: 29 Nov 2004 14:30:51.0771 (UTC) FILETIME=[06FC44B0:01C4D620] X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:30488 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:30488 Stefan Monnier wrote: >> The only thing programs do to control quitting is to bind >> inhibit-quit on and off. That is not relevant to handling >> with-no-input, so I think=20 >=20 > Could you substantiate that claim? > AFAIK inhibit-quit is used to get more-or-less-atomic behavior in > places where it matters. while-no-input should very clearly obey > inhibit-quit since it also causes non-local exits at places where it > can't be predited (just like quit). > Don't forget that the code within while-no-input is usually code that > was not specifically designed for while-no-input (otherwise it would > already use input-pending-p instead). Hmm, are you sure about that?? IMHO the code within while-no-input can also be code which would use input-pending-p already, so my example with performing a VC-state-check for a set of files which i want to be interruptable by the user at EVERY timepoint.... with only input-pending-p i can only interrupt directly = before the next VC-state-check, because the call `vc-state' rsp. = `vc-recompute-state' is not interruptable unless by hitting quit...=20 But if i could encapsulate processing my set of files in your = while-no-input macro then it could be interrupted at EVERY timepoint, if i have = understood you right, because this would also interrupt the inner = state-check-function, wouldn't it? So i would do (while-no-input .... (unwind-protect ;; checvk the state for the set of files in BODYFORM ( ;; cleanup whatever is to clean up )) Have i understodd this right? >=20 > Here is another way to say the ame thing: of all the non-local exits > we have right now, `quit' is the only one that's asynchronous.=20 > `while-no-input' introduces another form of asynchronous signalling > and is thus much more like `quit' than like `throw'.