unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: rms@gnu.org, Sean Whitton <spwhitton@spwhitton.name>
Cc: emacs-devel@gnu.org
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)	[thread overview]
Message-ID: <6e548da3-61ee-4c98-8f14-c2987caadbdf@default> (raw)
In-Reply-To: <E1jwz3r-0003Wq-D1@fencepost.gnu.org>

> 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-*
behavior.

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	other threads:[~2020-07-19 15:28 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <E1juSI3-0005ai-6j@fencepost.gnu.org>
     [not found] ` <83ft9woo68.fsf@gnu.org>
2020-07-13  2:52   ` "whether the global keymap ‘C-x 4’ will be replaced by a command," Richard Stallman
2020-07-13 23:58     ` "whether the global keymap C-x 4 " Juri Linkov
2020-07-14  4:19       ` Drew Adams
2020-07-14  5:55       ` Stefan Monnier
2020-07-14 14:41         ` Drew Adams
2020-07-14 14:48           ` Stefan Monnier
2020-07-14 15:28             ` Drew Adams
2020-07-14 15:35           ` John Yates
2020-07-14 14:51         ` Eli Zaretskii
2020-07-14 15:15           ` Stefan Monnier
2020-07-14 16:29             ` Eli Zaretskii
2020-07-15  4:06               ` Stefan Monnier
2020-07-15 14:16                 ` Eli Zaretskii
2020-07-15 23:54                 ` Juri Linkov
2020-07-16  4:07                   ` Stefan Monnier
2020-07-16 22:57                     ` Juri Linkov
2020-07-17  2:56                       ` Stefan Monnier
2020-07-17  0:56                 ` Richard Stallman
2020-07-14 22:27         ` Juri Linkov
2020-07-14 22:55           ` Drew Adams
2020-07-15  4:06           ` Stefan Monnier
2020-07-16  3:21           ` Richard Stallman
2020-07-16 15:05             ` Eli Zaretskii
2020-07-16 23:05             ` Juri Linkov
2020-07-17  2:10               ` Drew Adams
2020-07-18  1:57                 ` Richard Stallman
2020-07-18 16:23                   ` Sean Whitton
2020-07-18 17:00                     ` Drew Adams
2020-07-19  2:28                     ` Richard Stallman
2020-07-19 15:28                       ` Drew Adams [this message]
2020-07-21  0:22                       ` Sean Whitton
2020-07-18  1:54               ` Richard Stallman
2020-07-18 23:21                 ` Juri Linkov
2020-07-19  0:11                   ` Drew Adams
2020-07-19  3:38                   ` Stefan Monnier
2020-07-19 22:07                     ` Juri Linkov
2020-07-20  3:09                       ` Stefan Monnier
2020-07-20 20:50                         ` Juri Linkov
2020-07-20  2:39                   ` Richard Stallman
2020-07-20  3:13                   ` Stefan Monnier
2020-07-15  3:32         ` Richard Stallman
2020-07-19 13:00           ` Barry Fishman
2020-07-19 15:38             ` Drew Adams
2020-07-19 16:20               ` Barry Fishman
2020-07-19 17:45                 ` Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=6e548da3-61ee-4c98-8f14-c2987caadbdf@default \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=rms@gnu.org \
    --cc=spwhitton@spwhitton.name \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).