From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jared Finder via "Emacs development discussions." Newsgroups: gmane.emacs.devel Subject: Re: Additional cleanup around xterm-mouse Date: Sun, 13 Dec 2020 16:36:38 -0800 Message-ID: References: <83o8jupnqd.fsf@gnu.org> <838savys2v.fsf@gnu.org> <3e3933d8ec1d5d3f6809385a8ac5f447@finder.org> <83mtz1moa5.fsf@gnu.org> <0ea60a4f2a7fb0698f84ac5957cafef3@finder.org> <83mtyxgzck.fsf@gnu.org> Reply-To: Jared Finder Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1160"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Roundcube Webmail/1.3.15 Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Dec 14 01:40:15 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 1kobuQ-0000Be-NI for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Dec 2020 01:40:14 +0100 Original-Received: from localhost ([::1]:50514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kobuP-0006q7-NU for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Dec 2020 19:40:13 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:33538) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kobr8-000359-8A for emacs-devel@gnu.org; Sun, 13 Dec 2020 19:36:50 -0500 Original-Received: from greenhill.hpalace.com ([2600:3c01::f03c:91ff:fe73:2daa]:37852) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kobr1-0004eh-F0; Sun, 13 Dec 2020 19:36:49 -0500 Original-Received: from mail.finder.org (greenhill.hpalace.com [IPv6:2600:3c01::f03c:91ff:fe73:2daa]) by greenhill.hpalace.com (Postfix) with ESMTPSA id 41C709C6; Mon, 14 Dec 2020 00:36:39 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=finder.org; s=2018; t=1607906199; bh=jK0b3fxIwECqKV5l3PGSfIe2gKd2Q6JCjr7vGLNknvk=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=kigSaT4lS642C44FTncxAvCDTzoIhBcIFv/TlfU8lcgKGMIl1L17Q+srCoQfrtPxp wrtF+cEwxLN9Jg9r8KKljRG3X/tyqU0y76gACKVjfDCh0bSClgRZRn/hxRg2NV8bJc pEucnuDvmsWYA5DsGsZSlf+2xxlEdGpmO0kyYbqQ+bSJcRQGbx/DxnL6N1mCWH5YkR e0AfND+KKZw///W2p06w8wgF82A6Yzqz32bFG1oVXmpg4PvOJ8ouPvqHRevabBKh0q 0R5jWcY+LouiBNK6CkAqe+HPiMPg+vHiJccF88LhV5gzoW58uRXyaYtDlOX1cVhQJW ANdzOf0QtLjTg== In-Reply-To: <83mtyxgzck.fsf@gnu.org> X-Sender: jared@finder.org Received-SPF: pass client-ip=2600:3c01::f03c:91ff:fe73:2daa; envelope-from=jared@finder.org; helo=greenhill.hpalace.com X-Spam_score_int: 12 X-Spam_score: 1.2 X-Spam_bar: + X-Spam_report: (1.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_SBL_CSS=3.335, SPF_HELO_NONE=0.001, T_SPF_TEMPERROR=0.01 autolearn=no 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:260779 Archived-At: On 2020-12-01 10:23 am, Eli Zaretskii wrote: >> Date: Mon, 30 Nov 2020 23:36:23 -0800 >> From: Jared Finder >> Cc: emacs-devel@gnu.org >> >> This makes sense to me. I agree that read-key is likely to currently >> behave different in some situations from read-event. Are these >> differences bugs that should be fixed or are they now features that >> can >> not be changed? > > I don't know. I think we need to discuss each difference separately. > >> 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. >> * read-key does not return switch-frame events as they happen, >> read-event does. > > Thank you for doing this. We should at least document these changes > in some place, and probably also discuss at least some of them. I went through the rest of the code path and did not find any other behavior differences. I do not fully understand the logic around downcasing unbound keys (I think this is every key during read-key). However, I believe this doesn't matter as dont_downcase_last will be true from calls to read-key. -- MJF