From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Michael Albinus Newsgroups: gmane.emacs.devel Subject: Re: read-event in batch mode Date: Tue, 04 Feb 2014 12:54:08 +0100 Message-ID: <878utrks9r.fsf@gmx.de> References: <831tzo74oz.fsf@gnu.org> <87txckgtbk.fsf@gmx.de> <83txck5hbe.fsf@gnu.org> <83ob2s5dot.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1391514862 7163 80.91.229.3 (4 Feb 2014 11:54:22 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 4 Feb 2014 11:54:22 +0000 (UTC) Cc: Stefan Monnier , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Feb 04 12:54:26 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WAea9-00071n-St for ged-emacs-devel@m.gmane.org; Tue, 04 Feb 2014 12:54:26 +0100 Original-Received: from localhost ([::1]:51974 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAea9-00021g-JH for ged-emacs-devel@m.gmane.org; Tue, 04 Feb 2014 06:54:25 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55844) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAea2-00021Y-4c for emacs-devel@gnu.org; Tue, 04 Feb 2014 06:54:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WAeZw-00010T-9r for emacs-devel@gnu.org; Tue, 04 Feb 2014 06:54:18 -0500 Original-Received: from mout.gmx.net ([212.227.17.21]:51966) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WAeZw-00010J-05 for emacs-devel@gnu.org; Tue, 04 Feb 2014 06:54:12 -0500 Original-Received: from detlef.gmx.de ([93.209.89.230]) by mail.gmx.com (mrgmx002) with ESMTPS (Nemesis) id 0ML72n-1WAvh50wwD-000Il5 for ; Tue, 04 Feb 2014 12:54:10 +0100 In-Reply-To: <83ob2s5dot.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 31 Jan 2014 18:16:50 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) X-Provags-ID: V03:K0:xucKa0LBUX45uYEQMmePoP4lNcM6gCige6/yKJSguQAptQLAbwL 5MD+4MDkmxBUeVoDxZD5BeT1AcMsGfSDfixMnL+k5wtjuHr2yyHjYplvKHPc3Z2AakgU0zo SzPMs2lZMzuKC74mEMTaNba/3kOG4r0eSrVy9eQFXUdJhv4bUy/mkop7hbavRVssmlASKrs lWtoW1B7tKVvq58Atxw9Q== X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x [generic] X-Received-From: 212.227.17.21 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:169382 Archived-At: Eli Zaretskii writes: >> > The "keyboard buffer" is a misnomer: that's actually the Emacs event >> > queue, where all kinds of events end up, and from which they are read >> > and processed. Why is it a good idea to have more than one event >> > queue? >> >> Because some events should be processed in a particular order and others >> in a different order. They correspond to different "threads" of >> execution. The "keyboard buffer" normally corresponds to events coming >> from the user, so their relative ordering is very important and should >> not be changed. >> >> But D-Bus events or file-notification events may be triggered by >> processing that's completely independent/asynchronous from the user's >> actions, so they should be processed by Emacs without having to wait for >> previous user-events to be processed. > > We already have process_special_events that does what you describe, > just add more events to what it handles. Yes, that should work. But we would need more rearrangement, because process_special_events seems to be called only after kbd_buffer_get_event has returned already. During feature freeze, we shouldn't rearrange that code. For the time being I have extended the test in kbd_buffer_get_event, in order to read special events also when not linked with D-Bus. This should solve the problem also for the w32 case, I believe. Best regards, Michael.