From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jason Rumney Newsgroups: gmane.emacs.devel Subject: Re: Emacs does not listen on w32 Date: Mon, 14 Apr 2008 21:47:03 +0100 Message-ID: <4803C2C7.1050208@gnu.org> References: <4800D965.9080202@gmail.com> <480208C8.3030401@gnu.org> <480212F7.7090409@gmail.com> <4802249D.2060909@gmail.com> <480271D2.7040304@gmail.com> <4802FD64.1080602@gmail.com> <48038487.3060201@gmail.com> <4803B6A5.4030201@gnu.org> <4803C09F.5000200@gmail.com> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1208206086 8336 80.91.229.12 (14 Apr 2008 20:48:06 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 14 Apr 2008 20:48:06 +0000 (UTC) Cc: Juanma Barranquero , Eli Zaretskii , Stefan Monnier , emacs-devel@gnu.org To: "Lennart Borgman (gmail)" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Apr 14 22:48:36 2008 connect(): Connection refused Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1JlVb4-0004iC-Le for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 22:48:14 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlVaQ-00006A-D3 for ged-emacs-devel@m.gmane.org; Mon, 14 Apr 2008 16:47:34 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1JlVaM-00005g-1Z for emacs-devel@gnu.org; Mon, 14 Apr 2008 16:47:30 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1JlVaL-00005T-Gb for emacs-devel@gnu.org; Mon, 14 Apr 2008 16:47:29 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1JlVaL-00005Q-Aw for emacs-devel@gnu.org; Mon, 14 Apr 2008 16:47:29 -0400 Original-Received: from mk-outboundfilter-4.mail.uk.tiscali.com ([212.74.114.32]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1JlVaG-0004hH-O3; Mon, 14 Apr 2008 16:47:24 -0400 Original-X-Trace: 59319964/mk-outboundfilter-2.mail.uk.tiscali.com/F2S/$ACCEPTED/freedom2Surf-customers/83.67.23.108 X-SBRS: None X-RemoteIP: 83.67.23.108 X-IP-MAIL-FROM: jasonr@gnu.org X-IP-BHB: Once X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0FAN5fA0hTQxds/2dsb2JhbACBXqlY X-IP-Direction: IN Original-Received: from i-83-67-23-108.freedom2surf.net (HELO wanchan.jasonrumney.net) ([83.67.23.108]) by smtp.f2s.tiscali.co.uk with ESMTP; 14 Apr 2008 21:47:22 +0100 Original-Received: from [192.168.249.27] (chiko.jasonrumney.net [192.168.249.27]) by wanchan.jasonrumney.net (Postfix) with ESMTP id 6282449; Mon, 14 Apr 2008 21:47:25 +0100 (BST) User-Agent: Thunderbird 2.0.0.12 (Windows/20080213) In-Reply-To: <4803C09F.5000200@gmail.com> X-Enigmail-Version: 0.95.6 OpenPGP: id=8086879D X-detected-kernel: by monty-python.gnu.org: Genre and OS details not recognized. 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:95212 Archived-At: Lennart Borgman (gmail) wrote: > I do not understand what you mean here. Does the lisp thread look for > new messages when it is looping? (I think it should.) It reads the message queue at the normal points where normal keyboard input is read (not Ctrl-G, that is handled specially). You have to call specific functions in your lisp loop to arrange for it to happen inside your loop. You might do that if you expect your loop to take a long time, but probably not if it is an infinite loop because of a bug. > If it does not then we can't do any useful after a SendMessage with > timeout either, or can we? If we used SendMessage, then the system would detect that we aren't responding to that message after its timeout.