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: 05 Nov 2002 00:53:35 +0100 Sender: emacs-devel-admin@gnu.org Message-ID: <5xadkoriww.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> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1036451310 8552 80.91.224.249 (4 Nov 2002 23:08:30 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 4 Nov 2002 23:08:30 +0000 (UTC) Cc: Richard Stallman , 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 188qKZ-0002Df-00 for ; Tue, 05 Nov 2002 00:08:27 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.12 #1 (Debian)) id 188qSJ-0001LZ-00 for ; Tue, 05 Nov 2002 00:16:27 +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 188qJN-0002jv-00; Mon, 04 Nov 2002 18:07:13 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 188q6g-0006Uo-00 for emacs-devel@gnu.org; Mon, 04 Nov 2002 17:54:06 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 188q6a-0006Ov-00 for emacs-devel@gnu.org; Mon, 04 Nov 2002 17:54:03 -0500 Original-Received: from mail.filanet.dk ([195.215.206.179]) by monty-python.gnu.org with esmtp (Exim 4.10) id 188q6Z-0006Ja-00; Mon, 04 Nov 2002 17:53:59 -0500 Original-Received: from kfs2.cua.dk.cua.dk (unknown [10.1.82.3]) by mail.filanet.dk (Postfix) with SMTP id B13327C017; Mon, 4 Nov 2002 22:53:52 +0000 (GMT) Original-To: "Stefan Monnier" In-Reply-To: <200211041455.gA4EtqF23410@rum.cs.yale.edu> Original-Lines: 65 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:9120 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:9120 "Stefan Monnier" writes: > > > Please don't ask me to spend more time on this. > > > I have lots of other work to do, and I've made the decision. > > But this decision is just wrong. > > I think it is right, so what can I say? > > How about rebuffing the arguments you excised ? > You're not really attempting to justify your position. Well, I can fully understand why Richard thinks that using signal is the wrong approach. That is the obvious conclusion one would make if only thinking about the "formal appearence" of the proposal, without thinking about the substance of the problem that it tries to solve. IMHO, Stefan's patch isn't ugly at all; actually, it is a pretty damn clever solution to a tricky problem! I can understand Stefan's frustration that the idea is rejected merely on the reason of "ugliness". 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. 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. 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. Therefore, the most obvious solution -- once you see it -- to implement while-no-input is to use the quit signal as an indication of pending user input. That way, the existing code to handle the quit signal will make while-no-input work transparently out of the box! In contrast, using throw/catch instead of Stefan's `annotated' quit signal _DOES_NOT_WORK_ 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! So although Richard may be right that signal is _formally_ the wrong vehicle for while-no-input, it is the only vehicle which will work without modifying the code we want to encapsulate. So Richard, whether you want it or not, you need to think some more about this issue to: - 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), - or admit that Stefan's signal quit approach (however ugly you think it is) is a valid approach which actually will do the job properly with the least amount of work -- and it's already done! -- Kim F. Storm http://www.cua.dk