From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Juri Linkov Newsgroups: gmane.emacs.bugs Subject: bug#63648: 29.0.90; project.el: with switch-use-entire-map, switch-project errors on non-project commands Date: Thu, 31 Aug 2023 19:36:29 +0300 Organization: LINKOV.NET Message-ID: <86wmxb2qvh.fsf@mail.linkov.net> References: <86wn10e1wl.fsf@mail.linkov.net> <482a1ebc-165c-a0a4-98c0-5c404d1b1d0d@gutov.dev> <86jzwyxnxb.fsf@mail.linkov.net> <86o7m91z22.fsf@mail.linkov.net> <86pm6py6k4.fsf@mail.linkov.net> <86bki9y68h.fsf@mail.linkov.net> <86cz2f7bvo.fsf@mail.linkov.net> <86353axu48.fsf@mail.linkov.net> <87o7jfi00b.fsf@catern.com> <86msyhwrrg.fsf@mail.linkov.net> <86y1hs4kkg.fsf@mail.linkov.net> <86h6of66o3.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="17522"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) Cc: Spencer Baugh , 63648@debbugs.gnu.org, sbaugh@catern.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Aug 31 18:44:15 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1qbkmE-0004Nd-NE for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 31 Aug 2023 18:44:14 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qbklx-0008Ky-FV; Thu, 31 Aug 2023 12:43:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qbklu-00084f-9x for bug-gnu-emacs@gnu.org; Thu, 31 Aug 2023 12:43:54 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qbklu-0000Jd-0h for bug-gnu-emacs@gnu.org; Thu, 31 Aug 2023 12:43:54 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qbkm1-0002vd-SX for bug-gnu-emacs@gnu.org; Thu, 31 Aug 2023 12:44:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Juri Linkov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 31 Aug 2023 16:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63648 X-GNU-PR-Package: emacs Original-Received: via spool by 63648-submit@debbugs.gnu.org id=B63648.169350020111199 (code B ref 63648); Thu, 31 Aug 2023 16:44:01 +0000 Original-Received: (at 63648) by debbugs.gnu.org; 31 Aug 2023 16:43:21 +0000 Original-Received: from localhost ([127.0.0.1]:56935 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbklM-0002uY-W6 for submit@debbugs.gnu.org; Thu, 31 Aug 2023 12:43:21 -0400 Original-Received: from relay6-d.mail.gandi.net ([217.70.183.198]:34159) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qbklJ-0002u6-KU for 63648@debbugs.gnu.org; Thu, 31 Aug 2023 12:43:18 -0400 Original-Received: by mail.gandi.net (Postfix) with ESMTPSA id 3D8EAC0003; Thu, 31 Aug 2023 16:43:00 +0000 (UTC) In-Reply-To: (Dmitry Gutov's message of "Thu, 31 Aug 2023 14:13:46 +0300") X-GND-Sasl: juri@linkov.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:268832 Archived-At: >>> - Unfortunately, using default-directory instead of the specialized >>> variable which we added lately (project-current-directory-override) >>> brings back the bug it was added for: https://debbugs.gnu.org/58784. The >>> switch to a different design didn't fix the problem of the temporary >>> binding for d-d in the buffer which is current when the command is >>> executed. So adding the next-default-directory variable might not be the >>> best idea after all. But the advice thingy can set a binding for any >>> variable, including the *-override one. >> I didn't test yet the cases from bug#58784. So this might require more >> changes. > > We tried to make the default-directory binding work with a couple of > different changes - it didn't work out. The problem is that let-binding overrides the buffer-local value: ``` (let ((default-directory "/tmp/")) (list default-directory (buffer-local-value 'default-directory (current-buffer)))) => ("/tmp/" "/tmp/") ``` Here is the shortest test case: 'C-x p p C-b' shows buffers from two projects when using let-binding for default-directory, because 'project-buffers' relies on (buffer-local-value 'default-directory buf) This could be fixed by adding special-handling of the default-directory for the current buffer in 'project-buffers'. >>> - I also managed to get into some transient state where some chars were >>> doing one thing (their usual bindings), and some - invoked project >>> commands instead, with no apparent method of quitting that state. Maybe >>> I'll document it next time I see it. >> It would be nice to have a reproducible test case. >> But indeed chars in the project map invoke the project commands, >> and all other chars fall back to local/global keybindings. >> >>> - Using (project--keymap-prompt) for just a message call is cute, but >>> I personally like the "guardrails": if I accidentally type a wrong char >>> when choosing the command, I won't have to choose the other project >>> again. This is debatable, but both modes of operation are probably worth >>> keeping available (opinions welcome). >> This is easy to do with something like in 'y-or-n-p-map'. > > With setting that (or similar) keymap as a transient keymap? Something like this. >>> - Either way, with method with the advice should be useful for other >>> things, like project--other-place-command. >> It's not recommended to use advice in the core packages, >> maybe only for providing backward-compatibility with older versions. > > Sure, but it should also be permissible when there is no other way to do > a thing. > > OTOH, if we're talking about new features in core, we could have > a next-command-variables-alist, where we'd bind any variables that we would > want. Such generalization could be added later. > A general question regarding this approach, for me, is: is a "prefix > command" a real command? It's a real command that prepares some transient values for the next command. Most existing prefix commands have no problems because they modify global values. But 'default-directory' is the first buffer-local variable used for the next command, therefore it requires special-handling. Too bad that 'default-directory' is not a function. > And would they "swallow" these prepared variable bindings too early? The scope of the modified variable depends on concrete needs. For example, set-transient-map restores its old value in pre-command-hook, but display-buffer-override-next-command does this in post-command-hook.