From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: Additional cleanup around xterm-mouse Date: Tue, 01 Dec 2020 10:21:40 -0500 Message-ID: References: <83o8jupnqd.fsf@gnu.org> <838savys2v.fsf@gnu.org> <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> <83mtz1moa5.fsf@gnu.org> <0ea60a4f2a7fb0698f84ac5957cafef3@finder.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="36954"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , Jared Finder To: Jared Finder via "Emacs development discussions." Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Dec 01 16:23:20 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kk7Uu-0009SE-34 for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Dec 2020 16:23:20 +0100 Original-Received: from localhost ([::1]:34086 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kk7Ut-0000EX-2M for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Dec 2020 10:23:19 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33130) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk7TP-00076r-Dv for emacs-devel@gnu.org; Tue, 01 Dec 2020 10:21:47 -0500 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:27298) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kk7TM-000453-Tl; Tue, 01 Dec 2020 10:21:46 -0500 Original-Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 44B6B100823; Tue, 1 Dec 2020 10:21:43 -0500 (EST) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5C24A10021D; Tue, 1 Dec 2020 10:21:41 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1606836101; bh=oZoz5wHQVrpo5v/wgDe4O0wlKBsdmd8OwllCJDPDsiI=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=nvYaJrdPQ4/84JB1NTaAzHSG8q+VmcKZhIotZ8xlaEqslJgvljTbQ9X2oM6MfyyuK ff8j4Uu5C0GDbf6sV1tRWGts+31x8dpTImEqcrWzIw3oPxDXsuE5AdQB3mx8S5l2Kg HzkFqEQfZjLH65MURMYA8l+rt6Bq9ovB0a7NCbN+iF6RfBCe7ZVghxrwUHjd7m/SWC jd2GvGJxUwTOgJ5URdIwgkq9dbb8fetdJE4OyQGZ6Jn1j4tlWsYSVDMhXQJJWSmMPa WoPpU6gLP0I1JQfBFahl5U5zcBUEOa7F+OoyMFbPZz4+Xs5/9VBP5+8n/ewOjQid33 /gyj+g4PKjgow== Original-Received: from alfajor (69-165-136-52.dsl.teksavvy.com [69.165.136.52]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 1FFE01200BF; Tue, 1 Dec 2020 10:21:41 -0500 (EST) In-Reply-To: <0ea60a4f2a7fb0698f84ac5957cafef3@finder.org> (Jared Finder via's message of "Mon, 30 Nov 2020 23:36:23 -0800") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:260125 Archived-At: > I'm about 33% through analyzing read-key and have already found the > following differences: > > * read-key resets this-command-keys, read-event appends to it. I think this is a misfeature of `read-key`. I believe the better fix is to introduce a new function which is like `read-key-sequence` but with fewer side effects and on top of which we would re-implement `read-key` and `read-key-sequence`. By "fewer side effects", I mean that it should return a set of data: - the key-sequence read. - the corresponding list of undecoded input-events (instead of modifying this-command-keys). - the command that was found in the keymaps and which made the function decide that this key sequence was complete (instead of setting read_key_sequence_cmd). - maybe more... > * read-key does not return switch-frame events as they happen, > read-event does. I think this is what we want. BTW, related to that, there is `read-char` which I believe can (almost?) always be replaced with `read-key`. Stefan