From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] master 5b5f441: read_key_sequence: correct the handling of raw_keybuf in recursive calls Date: Wed, 22 Nov 2017 15:29:00 -0500 Message-ID: References: <20171120181209.23553.97060@vcs0.savannah.gnu.org> <20171120181210.7946F20416@vcs0.savannah.gnu.org> <20171120195918.GB3917@ACM> <20171120203004.GC3917@ACM> <20171122192522.GA4288@ACM> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1511382481 11499 195.159.176.226 (22 Nov 2017 20:28:01 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 22 Nov 2017 20:28:01 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) Cc: emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Nov 22 21:27:58 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eHbce-0002C4-36 for ged-emacs-devel@m.gmane.org; Wed, 22 Nov 2017 21:27:52 +0100 Original-Received: from localhost ([::1]:41197 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHbci-0003hw-3G for ged-emacs-devel@m.gmane.org; Wed, 22 Nov 2017 15:27:56 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53619) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHbc7-0003hZ-QX for emacs-devel@gnu.org; Wed, 22 Nov 2017 15:27:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eHbc5-0007Je-1b for emacs-devel@gnu.org; Wed, 22 Nov 2017 15:27:19 -0500 Original-Received: from chene.dit.umontreal.ca ([132.204.246.20]:60786) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eHbc4-0007Iz-R4 for emacs-devel@gnu.org; Wed, 22 Nov 2017 15:27:16 -0500 Original-Received: from lechazo.home (lechon.iro.umontreal.ca [132.204.27.242]) by chene.dit.umontreal.ca (8.14.7/8.14.1) with ESMTP id vAMKREoL025362; Wed, 22 Nov 2017 15:27:15 -0500 Original-Received: by lechazo.home (Postfix, from userid 20848) id 1A569602B6; Wed, 22 Nov 2017 15:29:00 -0500 (EST) In-Reply-To: <20171122192522.GA4288@ACM> (Alan Mackenzie's message of "Wed, 22 Nov 2017 19:25:22 +0000") X-NAI-Spam-Flag: NO X-NAI-Spam-Level: X-NAI-Spam-Threshold: 5 X-NAI-Spam-Score: 0.2 X-NAI-Spam-Rules: 3 Rules triggered ATR_WMN=0.2, EDT_SA_DN_PASS=0, RV6164=0 X-NAI-Spam-Version: 2.3.0.9418 : core <6164> : inlines <6182> : streams <1771038> : uri <2538531> X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 132.204.246.20 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:220370 Archived-At: >> Right: the middle one corresponds to `read-key-sequence` which can be >> called from "anywhere" (i.e. Elisp). > That is surely not the problem. The problem would be if something > aborted a read_key_sequence, and somehow started another one without > going via command_loop_1. I was thinking more of: (progn (catch 'foo (read-key-sequence ...)) ... (this-single-command-raw-keys)) where a timer throws `foo` during read-key-sequence. Since this-single-command-raw-keys uses the raw_keybuf, it ends up dereferencing the "stale" pointer to the var that was local in read_key_sequence. >> > You have a point, here. Perhaps it would be better to get storage from >> > the Emacs heap rather than using the stack. >> I like using the stack, here, actually. > I thought about that. No, I mean, I like the fact that your code uses the stack. >> Maybe another option is to make raw_keybuf local to read_key_sequence, >> and to *copy* it into the global raw_keybuf_buffer just before exiting. > That's quite close to what I've done. The difficulty is in getting a > pointer to that local buffer for use by the menu handling code. Hmm... could you show me that menu handling code you're referring to? The only user I can see of raw_keybuf (outside of local uses within read_key_sequence) is this-single-command-raw-keys, so maybe I'm missing something. >> PS: Of course, even better would be to provide another way to get what >> `this-single-command-raw-keys` returns, so we don't need to use a global >> variable for it. E.g. have `read-key-sequence` return both the key >> sequence and the raw key sequence. But we'd still have to support >> `this-single-command-raw-keys` for the foreseeable future anyway. > I don't think that idea would fly. Most uses of `read-key-sequence' > aren't going to be interested in the raw events. [ This is really a side-discussion about a better solution for the long-term, but we need to solve the current problem regardless. ] I was thinking of adding a new function read-raw-key-sequence which returns both the normal and the raw key sequences, with the hope that all users of this-single-command-raw-keys could eventually be changed to make use of that new function instead. Stefan