From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: storm@cua.dk (Kim F. Storm) Newsgroups: gmane.emacs.devel Subject: Re: last try (was: while-no-input) Date: 06 Nov 2002 10:45:34 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5xbs53uj41.fsf@kfs2.cua.dk> 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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036573878 32151 80.91.224.249 (6 Nov 2002 09:11:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 6 Nov 2002 09:11:18 +0000 (UTC) Cc: storm@cua.dk, 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 189MCv-0008Jw-00 for ; Wed, 06 Nov 2002 10:10:41 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 189MLL-0004gM-00 for ; Wed, 06 Nov 2002 10:19:23 +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 189M2x-000257-00; Wed, 06 Nov 2002 04:00:23 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 189Loj-00035J-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 03:45:41 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 189Loh-000358-00 for emacs-devel@gnu.org; Wed, 06 Nov 2002 03:45:40 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10) id 189Log-00034s-00; Wed, 06 Nov 2002 03:45:39 -0500 Original-Received: from kfs2.cua.dk.cua.dk (kfs2.local.filanet.dk [192.168.1.182]) by mail.filanet.dk (Postfix) with SMTP id D27FD7C018; Wed, 6 Nov 2002 08:45:36 +0000 (GMT) Original-To: rms@gnu.org In-Reply-To: Original-Lines: 50 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 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:9173 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9173 Richard Stallman writes: > 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? No, but I did look (briefly) at the relevant code. I looked at ange-ftp and it does indeed use unwind-protect in many places, but it also has this code: (condition-case ... (quit (delete-procss ...))). >From this I assumed that ange-ftp needed to be able to catch the quit signal to properly clean-up connections. However, looking at the code again, I must admit that I'm less sure now, whether going through that part of the code is really a good idea in case of user input! Only way to find out is to try it I guess... I also looked at tramp and it has neither unwind-protects, nor (condition-case ... quit ...), so I assumed that was quit-safe [whatever that is ...]. Maybe it works with both signal and throw -- maybe with neiter. > > If the code was written properly, it should not care which kind of > nonlocal exit is used. I see. > > - 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. Ok. Maybe I'll give it a try then... -- Kim F. Storm http://www.cua.dk