[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "whether the global keymap C-x 4 will be replaced by a command,"

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 

>> 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 
what is needed for `project-switch-project`.  I could try to generalize it
to support modification of arbitrary variables.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]