From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Severe lossage from unread-command-events Date: Thu, 06 Aug 2015 19:21:06 +0300 Message-ID: <83fv3ws80d.fsf@gnu.org> References: <87egjh4u1h.fsf@fencepost.gnu.org> <83pp30sd5l.fsf@gnu.org> <87k2t831gf.fsf@fencepost.gnu.org> <83io8ssakw.fsf@gnu.org> <87bnek2ze3.fsf@fencepost.gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1438878097 28625 80.91.229.3 (6 Aug 2015 16:21:37 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 6 Aug 2015 16:21:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: David Kastrup Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Aug 06 18:21:28 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 1ZNNv2-0000Rs-7K for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 18:21:24 +0200 Original-Received: from localhost ([::1]:45843 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNNv1-00089W-Ha for ged-emacs-devel@m.gmane.org; Thu, 06 Aug 2015 12:21:23 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57797) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNNuy-00089J-7o for emacs-devel@gnu.org; Thu, 06 Aug 2015 12:21:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZNNux-0006IU-Bc for emacs-devel@gnu.org; Thu, 06 Aug 2015 12:21:20 -0400 Original-Received: from mtaout21.012.net.il ([80.179.55.169]:46790) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZNNur-0006FW-MA; Thu, 06 Aug 2015 12:21:13 -0400 Original-Received: from conversion-daemon.a-mtaout21.012.net.il by a-mtaout21.012.net.il (HyperSendmail v2007.08) id <0NSO00D004VDNT00@a-mtaout21.012.net.il>; Thu, 06 Aug 2015 19:21:12 +0300 (IDT) Original-Received: from HOME-C4E4A596F7 ([87.69.4.28]) by a-mtaout21.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0NSO00D6C5FBN240@a-mtaout21.012.net.il>; Thu, 06 Aug 2015 19:21:12 +0300 (IDT) In-reply-to: <87bnek2ze3.fsf@fencepost.gnu.org> X-012-Sender: halo1@inter.net.il X-detected-operating-system: by eggs.gnu.org: Solaris 10 X-Received-From: 80.179.55.169 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:188509 Archived-At: > From: David Kastrup > Cc: emacs-devel@gnu.org > Date: Thu, 06 Aug 2015 17:46:28 +0200 > > Eli Zaretskii writes: > > > To see what's going on, I instrumented the code with special > > printouts, and clearly saw that we only record the events that are > > taken from unread-command-events in one of two possible places in the > > code, where we have fragments such as this one: > > > > if (CONSP (Vunread_command_events)) > > { > > [...] > > c = XCAR (Vunread_command_events); > > Vunread_command_events = XCDR (Vunread_command_events); > > > > One such fragment is at the beginning of read_char, around line 2430 > > of keyboard.c -- the events taken there are not recorded, because we > > jump over the code that records them. > > That's bad because that sounds _intentional_. I thought about that, and tried to find any reason why such an intention would be valid, but couldn't. The comments therein mention read_char_x_menu_prompt, but that function only records the first event, and pushes all the rest onto unread-command-events. If someone who reads this knows why these events were not recorded, let them speak up now, or forever hold their peace. > So my suspicion is that this change might result in problems that the > old code arrangement was intended to avoid. But one will probably not > get new input on this without trying. Indeed. It could be that we will find something, but the current situation is clearly unsatisfactory, and has to be fixed. If the fix uncovers other problems, we will have to solve them as well, but without regressing back to what we have now.