From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Feng Newsgroups: gmane.emacs.devel Subject: Re: [elpa] externals/exwm 0b8a373: Fix a `unread-command-events' issue for Emacs 24 Date: Fri, 15 Jul 2016 10:22:37 +0800 Message-ID: References: <20160715001351.14660.27588@vcs.savannah.gnu.org> <20160715001351.9FD2C22014B@vcs.savannah.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Trace: ger.gmane.org 1468549376 25897 80.91.229.3 (15 Jul 2016 02:22:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2016 02:22:56 +0000 (UTC) Cc: emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jul 15 04:22:56 2016 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 1bNsmC-00007r-Ou for ged-emacs-devel@m.gmane.org; Fri, 15 Jul 2016 04:22:52 +0200 Original-Received: from localhost ([::1]:57946 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNsmB-00056F-K7 for ged-emacs-devel@m.gmane.org; Thu, 14 Jul 2016 22:22:51 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:51107) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNsm5-000512-73 for emacs-devel@gnu.org; Thu, 14 Jul 2016 22:22:46 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bNsly-0007uY-UQ for emacs-devel@gnu.org; Thu, 14 Jul 2016 22:22:39 -0400 Original-Received: from mail-wm0-x243.google.com ([2a00:1450:400c:c09::243]:35499) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bNsly-0007uU-O4 for emacs-devel@gnu.org; Thu, 14 Jul 2016 22:22:38 -0400 Original-Received: by mail-wm0-x243.google.com with SMTP id i5so746438wmg.2 for ; Thu, 14 Jul 2016 19:22:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=nqyAW/131mYjNq//ocqwU+M686nWo5ls4MQ0DbS5p60=; b=LN0DG4I+rlIfs12jKWytXuOnQd4wFU68QNyOCWOqwfkMdq/w1veyHyVlivSY5sXip6 6h7KOwSbugqtpjmmhId0URUjydsOTbfMJqiV69NtqVib/UmkyJYSZIwERHn5dbeHO4wd ZWkrgGX7lNpSW9VW2C/weQLQHOzT9kX7sSvmqRQqTPWcQR28BoeuXNUU01mDC1t/uitm ImXDQCDeGwActcEwqa07nn4nGnASKlb9GxJEjaj+hxBMyQlGoYe9FC5QdpSTHZi4Xk0T c2vnwa2xLitU6zbR2aVi4tPhKDaaxKERoXnNaJuMo68XUNPzjH95xf21HceQQvqQrJ8Q YqCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=nqyAW/131mYjNq//ocqwU+M686nWo5ls4MQ0DbS5p60=; b=U7f6DsmC8NTO2AiYGfmbWkyIFIzaYfBI5P5ptWwIcQsPnMTD/sTCbUif1gSwuuMpvI 64jkxJjUPa6T/S5LVSCty0YtVVmYeH8Q5veGOOFP5giveCJRUyeOZJt3zS0JsHC4swfD 5lea28TBPgtzsoPShZ1khrP/kbPf7PvNrCAj8n+35y/OX6d8zqWus3AJ1rzjSk6/eN2j q4P3wPomQQ2O5CKfpLYkAG6HjPgYSOgaTL6OkWSMsIKHbokc1w7P/ESXuxGPqmNcuFaH AFdhG3n6BAdsKVJIk1NppZ1PMr00jGkGPHAnPX0LVvBhEuY3srrbBYq2ibbaUyuRKM/Q ZCjw== X-Gm-Message-State: ALyK8tLnCD8/EK8dr7MvsDYuZPZujFaHoz4ukyMynZUJflZlpFdJofNQ2keZ2N4QiBukptFLaYN6LfmlFx11Yg== X-Received: by 10.28.165.3 with SMTP id o3mr20734696wme.3.1468549358019; Thu, 14 Jul 2016 19:22:38 -0700 (PDT) Original-Received: by 10.194.97.20 with HTTP; Thu, 14 Jul 2016 19:22:37 -0700 (PDT) In-Reply-To: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a00:1450:400c:c09::243 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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" Xref: news.gmane.org gmane.emacs.devel:205696 Archived-At: >> My concern was that the function would get called very frequently (on >> every key event in certain circumstances) so I made them inline. > > I don't think "every key event" (human scale) can be "very frequently" > at the computer's scale. And in any case, the time to process the event > later on will completely dwarf this. > >> As for your the problem you pointed out, my understanding is that >> bytecodes for Emacs 24 and 25 are largely not compatible, at least for >> this package which heavily relies on EIEIO. So even if we can choose >> between the two functions at run time the compiled code still won't >> run correctly. > > Oh, indeed if it uses EIEIO it's quite possible that recompilation will > be needed anyway. Yes, performance is technically not an issue here. But considering that recompilation is always required, there's no need to change the code. >> The events are received directly from X server (rather than Emacs) in >> chronological order so I think it makes sense to append them to >> `unread-command-events', in case previous events added not processed >> timely. > > Say you have (X Y Z) in unread-command-events, and Emacs comes takes > X out and processes it. If during processing you push the new event > A at the end, that means it'll be processed in a different order than if > Y and Z had been received a bit later. > > The right choice depends on the nature of the event you're pushing (A) > and its relationship to the current event (X), so it has to be decided > on a case-by-case basis according to the specific details. > > So maybe that's indeed the behavior you want (and I don't know nearly > enough about the events you're manipulating to be able to tell), but > usually in my experience you want to push to the front. The key events are generated by the user and are received through a subprocess in a non-preemptive way, so they're always processed in a first-come, first-served fashion. `unread-command-events' is used as a FIFO here. >> Also there're related bugs with `unread-command-events' (bug#23980). >> Could you take a look? > > I'll take a look, Thanks! Chris