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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

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

Sean Whitton
Hello Richard,

On Fri 17 Jul 2020 at 09:57PM -04, Richard Stallman wrote:

> Maybe it would be possible to make a function that would generate
> an "other-window" version of an existing command, by making code to call
> that command.

This is why my original patch which partly prompted this discussion did
(bug#42210), but the feedback I got was that it would be better to avoid
cluttering the function symbol namespace with lots of -other-window
commands.

--
Sean Whitton

Reply | Threaded
Open this post in threaded view
|

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

Drew Adams
Read your post quickly.  Apologies if this is
off the mark.

Would the use of the fallback behavior be optional,
i.e., choosable by users (e.g. opt-in)?

Would it affect command (and key) discovery, e.g.,
giving a (false) impression that such-and-such an
other-* behavior, for which there is no explicit
command and no explicit key binding, but which is
available only via your fallback, is in fact a
real command/key?

Would a user be able to somehow reify/manifest
the fallback behavior as an actual other-*
command, which s?he could then bind to a key?

Generally, is the fallback thingy only a plus, as
opposed to being a possible substitute for what
we do now?

It bothers me that you might see it as an eventual
replacement, since it doesn't seem to offer the
same things.  Speaking of "backward compatible"
doesn't inspire confidence that it would be only
an optional plus, and not, e.g., a trojan horse.