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: "whether the global keymap C-x 4 will be replaced by a command," Date: Thu, 16 Jul 2020 22:56:15 -0400 Message-ID: References: <83ft9woo68.fsf@gnu.org> <87wo377wxp.fsf_-_@mail.linkov.net> <83ft9um9op.fsf@gnu.org> <838sfmm54o.fsf@gnu.org> <87y2nkbah5.fsf@mail.linkov.net> <87blkfqd8q.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="10479"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Jul 17 04:57:09 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 1jwGYf-0002d7-NT for ged-emacs-devel@m.gmane-mx.org; Fri, 17 Jul 2020 04:57:09 +0200 Original-Received: from localhost ([::1]:40416 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jwGYe-00034u-E0 for ged-emacs-devel@m.gmane-mx.org; Thu, 16 Jul 2020 22:57:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51082) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwGXv-0002c6-VI for emacs-devel@gnu.org; Thu, 16 Jul 2020 22:56:23 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:18734) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jwGXt-0004dH-66; Thu, 16 Jul 2020 22:56:22 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id C560B80408; Thu, 16 Jul 2020 22:56:18 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0737281111; Thu, 16 Jul 2020 22:56:17 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1594954577; bh=HM46p1UPQq8BneOpTwIMsBSQfw6daUdR3/cNGFiKcT8=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=XhIO1fWwy83kvJU4i3/deRwQNkKEkzzYpxyLU6id2MHiy4Hc/wdBbdojT1eKHPbnv oZtWjWBc12HV21jusxWRlt2ypKMKhAqTanc8xqfEIpnXD0horVjOvuYC2bnlv6v8SM IsWItGajrjtJ1Npv4rt88QtYNNt4pt/geq5wWALbGgQI66nVE2LTYCF0x4Ina/Dnme MipsiMl1d5KL47M7oGCsZPH1Pt2YX7iwMN1oIeLLyFShCW4qpTkH4ZhEL/kSnGfuTN JmZ4sDBlBPeRLQcTU1jH5ajJoyj8Qen/MQ9lCifh+DemfESklQwhMuT3ZRSwpE3+0Z 8dRXRy+RIh6EQ== Original-Received: from asado (76-10-180-175.dsl.teksavvy.com [76.10.180.175]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 737B71203AB; Thu, 16 Jul 2020 22:56:16 -0400 (EDT) In-Reply-To: <87blkfqd8q.fsf@mail.linkov.net> (Juri Linkov's message of "Fri, 17 Jul 2020 01:57:57 +0300") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-detected-operating-system: by eggs.gnu.org: First seen = 2020/07/16 22:56:18 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] 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, URIBL_BLOCKED=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:253000 Archived-At: >>> Then it could bind `overriding-terminal-local-map` (instead of using >>> `set-transient-map`) >> Not sure what's the difference. > It could simplify implementation of commands that need to modify more variables, > e.g. both `overriding-terminal-local-map` and `display-buffer-overriding-action`. You mean you're interested in providing a generic way to "set some vars for the next command"? I can see why you'd want that, but: - It's not as uniform as it seems: `overriding-terminal-local-map` needs to be set while "reading" the next command but not while running it, whereas `display-buffer-overriding-action` needs to be set while running the next command and not while reading it. - `set-temporary-map` doesn't need to just "set" the var: it needs to modify it and then revert the modification (and handle the case where some other modification took place in the mean time). IOW we need some way to "add" and "remove" something from that var. Now, that probably applies to other vars, so it would indeed be good to provide some more generic support for that. >> This sounds like it might benefit from using a trick like the one I use >> in `mule-cmds--prefixed-command-pch` in order to let-bind >> `coding-system-for-read/write` around the call of the next command. > > It's surprising that such trick works without problems. And it seems it's exactly > what is needed for `project-switch-project`. I could try to generalize it > to support modification of arbitrary variables. Beware: let-binding a var like that can lead to undesired results if the command run within the let-binding wants to modify this var (the modification is typically lost) or make it buffer-local (the temporary let-bound value may "leak" outside of the let-binding). IOW, some such variables want to be let-bound but others prefer to be `setq`. Stefan