[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: Drew Adams
Subject: RE: "whether the global keymap C-x 4 will be replaced by a command,"
Date: Sun, 19 Jul 2020 15:28:49 +0000 (UTC)

> There are two closely related but distinct questions.
> 1. Whether Drew would like to use that facility to
>    make -other-window functions.

I hope I answered that clearly: No, I would not.

a. To me, the difficulty of, and the need to,
   automatically, programmatically create -other-*
   commands are non-problems.

   It's not difficult to create an -other-* command.

   When it's helpful to do so programmatically (e.g.
   to reduce repetitive code) I use (context-specific)
   Elisp macros to do so.  I do that quite a lot, in
   fact, but always context-specifically.

b. Beyond difficulty or need, it is, IMO, misguided
   to _automatically_ do that.  Such commands should
   be created only as needed, as decided by whoever
   wants them (user or library author).

There is neither a need nor a desire to systematically
have -other-* versions of all commands that display
something or otherwise use a window or frame.

My point was that for -other-* behavior I _do_ want
explicit commands.  And I don't want some blanket,
implicit, general "prefix command" behavior with no
explicit commands that I can bind as I like.

Saying I want explicit commands for -other-* behavior
does not mean that I want such behavior - or such
commands - everywhere and always.

There's nothing wrong with creating prefix commands.
I and others do that, and Emacs has some predefined.

What I object to is replacing the use of prefix keys,
which are bound to keymaps, with some general
mechanism that uses a prefix command.

And in particular, replacing prefix keys such as
`C-x' and `C-x 4', and their keymap bindings, with
some prefix command that simulates what they do,
especially in some blanket way, automatically
giving _everything_ an -other-* behavior.  Not
everything deserves/needs an -other-* behavior.

There is talk, wrt explicit -other-* commands, of
polluting the function/command namespace.  The
same thing can be said of the proposal, but even
more so, wrt a resultant plethora of -other-*

The proposal apparently makes `C-x 4' provide
-other-* behavior _generally_, far more than
what's available today using explicit keys bound
in `ctl-x-4-map'.

> 2. What to do about the standard C-x 4 commands,
>    with three options:
>    2a. Leave them as they are now.
>    2b. Use your proposed generator facility to make
>        a lot of -other-window functions.

I don't think that was proposed, at least initially.

It may have been offered as a kind of sop, to respond
(misguidedly) to my desire/need to have explicit
-other-* commands (e.g. to bind wherever one likes).

For my opinion on that, see above - no need.  There's
no problem defining -other-* commands, manually or
using macros.

>    2c. Make C-x 4 handle them all automatically.
> Your message talked about choosing between 2b and 2c,
> whereas I was suggesting that Drew could do 1.

reply via email to

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