|
From: | Juri Linkov |
Subject: | Re: "whether the global keymap C-x 4 will be replaced by a command," |
Date: | Fri, 17 Jul 2020 01:57:57 +0300 |
User-agent: | Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (x86_64-pc-linux-gnu) |
>> 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`. >> and also bind `display-buffer-overriding-action` >> (instead of using `display-buffer-override-next-command`). > > Neither do I understand what's better about "bind > `display-buffer-overriding-action`" compared to using > `display-buffer-override-next-command`. For simplicity as well. And for uniformity of modifying the environment of the next command the same way for different variables. >> This will also solve the problem of setting `default-directory` >> for `C-x p p` (project-switch-project). As explained in >> https://debbugs.gnu.org/41890#196 >> currently it's not possible to bind the value of `default-directory` >> for the next command, but with a closure the variable binding will have >> the effect during the next command. > > 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.
[Prev in Thread] | Current Thread | [Next in Thread] |