From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: last try (was: while-no-input) Date: Tue, 05 Nov 2002 23:50:23 -0500 Sender: emacs-devel-admin@gnu.org Message-ID: References: <200210012119.g91LJW922045@rum.cs.yale.edu> <200210022143.g92LhXQ28321@rum.cs.yale.edu> <200210031553.g93FrwH31218@rum.cs.yale.edu> <200210041559.g94Fx9006880@rum.cs.yale.edu> <5xr8egzom4.fsf@kfs2.cua.dk> <200210240720.g9O7KxV11421@rum.cs.yale.edu> <5xelagp218.fsf@kfs2.cua.dk> <200210251344.g9PDi3W20508@rum.cs.yale.edu> <200210291945.g9TJjlU18481@rum.cs.yale.edu> <200210311803.g9VI3hM30498@rum.cs.yale.edu> <200211020407.gA2472v07516@rum.cs.yale.edu> <200211041455.gA4EtqF23410@rum.cs.yale.edu> <5xadkoriww.fsf@kfs2.cua.dk> Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org X-Trace: main.gmane.org 1036560699 17009 80.91.224.249 (6 Nov 2002 05:31:39 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 6 Nov 2002 05:31:39 +0000 (UTC) Cc: monnier+gnu/emacs@rum.cs.yale.edu, emacs-devel@gnu.org Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 189ImA-0004NF-00 for ; Wed, 06 Nov 2002 06:30:50 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 189IuV-0008Ej-00 for ; Wed, 06 Nov 2002 06:39:28 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 189Ih5-00059o-00; Wed, 06 Nov 2002 00:25:35 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189I94-0004ha-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 23:50:26 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189I91-0004h3-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 23:50:25 -0500 Original-Received: from fencepost.gnu.org ([199.232.76.164]) by monty-python.gnu.org with esmtp (Exim 4.10) id 189I91-0004gx-00 for emacs-devel@gnu.org; Tue, 05 Nov 2002 23:50:23 -0500 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.10) id 189I91-000580-00; Tue, 05 Nov 2002 23:50:23 -0500 Original-To: storm@cua.dk In-reply-to: <5xadkoriww.fsf@kfs2.cua.dk> (storm@cua.dk) Errors-To: emacs-devel-admin@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.emacs.devel:9158 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9158 However, the bad thing about this whole argument is that, as Stefan has clearly pointed out (without Richard actually arguing against that), using throw/catch _DOES_NOT_WORK_ for the specific problem that while-no-input is supposed to solve. It seemed to me that it would work. Let's see. The problem is that we need while-no-input to be able to encapsulate _UNMODIFIED_ code (such as ange-ftp and tramp) so that user input transparently "interrupts" (or quits) that code. Input should cause a nonlocal exit. Signals and throw are both nonlocal exits. Obviously, the code we need to encapsulate must already have been written to intercept the "quit" signal to be able to properly clean-up network connections etc. due to a keyboard-quit. The proper way to do this is with unwind-protect, and that handles both signals and throw the same way. In contrast, using throw/catch instead of Stefan's `annotated' quit signal _DOES_NOT_WORK_ You say this as if it were observed fact, but the reason you give since the code we really want to encapsulate, such as ange-ftp and tramp, is not written to expect a non-local exit due to non-quit events! is a theoretical supposition. Have you tried it? If the code was written properly, it should not care which kind of nonlocal exit is used. - either show us (in detail) how throw/catch can be used to achieve the described goals without having to modify ange-ftp and tramp (and every other package that may install file name handlers), There is no evidence they need modification, only speculation. And if it does need modification, the code probably was not written in the recommended way, and the modification is probably a good idea anyway.