From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: David Kastrup Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] Let input queue deal gracefully with up-events Date: Wed, 28 Jan 2015 23:55:10 +0100 Message-ID: <878ugmplbl.fsf@fencepost.gnu.org> References: <1422451883-6530-1-git-send-email-dak@gnu.org> <87d25yptv9.fsf@fencepost.gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1422485747 21981 80.91.229.3 (28 Jan 2015 22:55:47 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 28 Jan 2015 22:55:47 +0000 (UTC) Cc: emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Jan 28 23:55:47 2015 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 1YGbWU-0006Uu-Hy for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2015 23:55:46 +0100 Original-Received: from localhost ([::1]:56841 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGbWU-0003VQ-3y for ged-emacs-devel@m.gmane.org; Wed, 28 Jan 2015 17:55:46 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:59751) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGbWP-0003U5-Ma for emacs-devel@gnu.org; Wed, 28 Jan 2015 17:55:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YGbWO-0002v2-JP for emacs-devel@gnu.org; Wed, 28 Jan 2015 17:55:41 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:39250) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGbWO-0002ux-AG for emacs-devel@gnu.org; Wed, 28 Jan 2015 17:55:40 -0500 Original-Received: from localhost ([127.0.0.1]:46421 helo=lola) by fencepost.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YGbWE-0001SO-Ow; Wed, 28 Jan 2015 17:55:31 -0500 Original-Received: by lola (Postfix, from userid 1000) id 00EF8DF6AB; Wed, 28 Jan 2015 23:55:10 +0100 (CET) In-Reply-To: (Stefan Monnier's message of "Wed, 28 Jan 2015 17:14:25 -0500") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:181950 Archived-At: Stefan Monnier writes: >> How else would you want to call the key release from a piano keyboard? >> It is basically auxiliary information that can often be discarded: the >> key press event is much more important when using a piano keyboard. > > I see, that makes sense. Well, at least there does not seem to be much of a point of Emacs having only half-baked support of "up-" with optional segfaults when the event queue is writeable for program-generated events. While I want to add native Midi support eventually (it will make the timing info have much less jitter and should make portability to Windows etc easier), this would require the same sort of changes anyway, and so will other attempts at playing with synthetic key events. Discarding unbound up-events without error like down-events are currently discarded is, of course, a somewhat arbitrary design decision. However, if up-xxx is a modified version of xxx, chances are that its state is comparable to down-xxx. For Midi, I am still vacillating between using xxx/up-xxx or down-xxx/up-xxx. The former (where an unbound xxx leads to a complaint and an unbound up-xxx is silently discarded) actually corresponds pretty well with the normal semantics expected from a keyboard and would probably also operate nicer in connection with M-x local-set-key RET. My first approach was not messing with Emacs current modifier handling at all and using xxx-down for keypress and xxx for keyrelease. But that was not really satisfactory since then M-x local-set-key RET binds the keyrelease if you press a key. Pre-stuffing the modifier caches is also only half-satisfactory since if you then press a piano key, type C-x @ m and release the key again, Emacs will still emacs_abort (since the modifier cache was not pre-filled for M-up-xxx). So at least in the long run, I think it makes good sense to make the keyboard-queue backend not complain about data that could not have originated from the keyboard-queue frontend. It's not like the crashes and inconsistencies serve any useful purpose. Arguably, even if some problem is caused by unexpected things happening in the keyboard-queue frontend, you may be better served with the keyboard-queue backend delivering a quite descriptive and printable strange event rather than crashing: after all, the actual program location that could have _generated_ the data is no longer connected with the call stack when emacs_abort is called. -- David Kastrup