From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chong Yidong Newsgroups: gmane.emacs.devel Subject: Re: a bug of read-passwd Date: Mon, 24 Jul 2006 00:54:19 -0400 Message-ID: <87vepn61s4.fsf@stupidchicken.com> References: <877j2etda5.fsf@stupidchicken.com> <20060719.094900.73654343.kazu@iij.ad.jp> <20060721.095708.119557783.kazu@iij.ad.jp> <874pxau66i.fsf@stupidchicken.com> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1153716890 24915 80.91.229.2 (24 Jul 2006 04:54:50 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 24 Jul 2006 04:54:50 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jul 24 06:54:49 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1G4sSo-0006yn-FI for ged-emacs-devel@m.gmane.org; Mon, 24 Jul 2006 06:54:42 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4sSn-0003Iy-V2 for ged-emacs-devel@m.gmane.org; Mon, 24 Jul 2006 00:54:42 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1G4sSW-0003CK-Hs for emacs-devel@gnu.org; Mon, 24 Jul 2006 00:54:24 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1G4sSV-0003Ax-OV for emacs-devel@gnu.org; Mon, 24 Jul 2006 00:54:23 -0400 Original-Received: from [18.72.1.2] (helo=south-station-annex.mit.edu) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1G4sTW-0006Tr-G3; Mon, 24 Jul 2006 00:55:26 -0400 Original-Received: from central-city-carrier-station.mit.edu (CENTRAL-CITY-CARRIER-STATION.MIT.EDU [18.7.7.72]) by south-station-annex.mit.edu (8.13.6/8.9.2) with ESMTP id k6O4sMAa003574; Mon, 24 Jul 2006 00:54:22 -0400 (EDT) Original-Received: from outgoing-legacy.mit.edu (OUTGOING-LEGACY.MIT.EDU [18.7.22.104]) by central-city-carrier-station.mit.edu (8.13.6/8.9.2) with ESMTP id k6O4sLwC008621; Mon, 24 Jul 2006 00:54:22 -0400 (EDT) Original-Received: from cyd (SYDNEYPACIFIC-FOUR-FIFTEEN.MIT.EDU [18.95.6.160]) ) by outgoing-legacy.mit.edu (8.13.6/8.12.4) with ESMTP id k6O4sKDD010733; Mon, 24 Jul 2006 00:54:20 -0400 (EDT) Original-Received: from cyd by cyd with local (Exim 3.36 #1 (Debian)) id 1G4sSR-0001RG-00; Mon, 24 Jul 2006 00:54:19 -0400 Original-To: rms@gnu.org In-Reply-To: (Richard Stallman's message of "Sat, 22 Jul 2006 00:39:06 -0400") User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux) X-Spam-Score: 1.47 X-Scanned-By: MIMEDefang 2.42 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: news.gmane.org gmane.emacs.devel:57522 Archived-At: Richard Stallman writes: > One solution is to set up a mechanism for the sit-for timer > to determine that it has been called inside a filter. > Then it needs to be able to set up for a certain function to be > called when the filter returns. > > Another solution would be, don't use a timer. > read-event works by calling wait_reading_process_output. > It should be feasible to give it a new argument > which specifies a maximum time delay. OK, I looked into this. I think that fixing read-event to give it a new argument specifying a max delay turns out to be not simple to implement. (The detailed situation is this: the old sit-for called wait_reading_process_output for a given duration, but that's problematic since wait_reading_process_output can return due to fake events. The new sit-for solves this by calling read-event, which relies on read_char, which loops calling wait_reading_process_output with zero duration and discarding fake events [using kbd_buffer_get_event, which does some complicated processing to figure out if the event is fake or not]. The new sit-for interrupts this loop using a timer. If we want to hack read_char to accept a new arg specifying the max delay, there would be two sets of timing code: inside read_char, and inside wait_reading_process_output. This is very inelegant.) Another possibility is to implement a `inhibit-timers' variable and set it to t by default inside filter functions (similar to how `inhibit-quit' is bound to t in filter functions.) This is probably easier to implement. What do you think?