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

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

What would it mean to replace that keymap with a command?

What would that change for users?
Would that make help commands give less useful results for C-x 4 C-f and so on?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Juri Linkov]

> What would it mean to replace that keymap with a command?
>
> What would that change for users?
> Would that make help commands give less useful results for C-x 4 C-f and so on?

It's easy to answer your questions by just loading the package
other-frame-window.el from GNU ELPA, enabling other-frame-window-mode,
and seeing how it works.

By default, it uses 'C-x 7' for the other-window prefix
to support such keysequences as 'C-x 7 C-f'.

Trying to type 'C-h k C-x 7 C-f' ends the keysequence after
'C-h k C-x 7' and displays the help for the other-window command.

This means that after binding the current ctl-x-4-map in Emacs core
to the other-window command, 'C-h k C-x 4' will display the help for
that command, not for the whole sequence 'C-h k C-x 4 C-f'.

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

[Drew Adams]

> Trying to type 'C-h k C-x 7 C-f' ends the keysequence after
> 'C-h k C-x 7' and displays the help for the other-window command.
> 
> This means that after binding the current ctl-x-4-map in Emacs core
> to the other-window command, 'C-h k C-x 4' will display the help for
> that command, not for the whole sequence 'C-h k C-x 4 C-f'.

That's unfortunate.  `C-x 4 C-f' is presumably still
a key binding (?).  It should be, at least.  And as
such `C-h k' should tell you directly what it's
bound to etc.  We already have `C-x 4 C-h' to show
us all of the `C-x 4' bindings.

Sounds, so far, like a step backward.  Why?

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

[Stefan Monnier]

> This means that after binding the current ctl-x-4-map in Emacs core
> to the other-window command, 'C-h k C-x 4' will display the help for
> that command, not for the whole sequence 'C-h k C-x 4 C-f'.

I don't think we can/should make `C-h k` read all of `C-x 4 C-f`, indeed.
But maybe we could make the following work: `C-x 4 C-h k C-f`.


        Stefan

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

[Drew Adams]

> > This means that after binding the current ctl-x-4-map in Emacs core
> > to the other-window command, 'C-h k C-x 4' will display the help for
> > that command, not for the whole sequence 'C-h k C-x 4 C-f'.
> 
> I don't think we can/should make `C-h k` read all of `C-x 4 C-f`,
> indeed.  But maybe we could make the following work:
> `C-x 4 C-h k C-f`.

Quelle horreur !

Farther & farther from Occam - more & more complex.
For what gain?  Don't multiply things unnecessarily.

https://en.wikipedia.org/wiki/Occam%27s_razor

This _looks_ like a solution that's looking for
a problem to solve.  Evidence to the contrary?

We already have `C-x 4 C-h', which shows you
every `C-x 4' key sequence and its command, with
a link to its doc.  Que demande le peuple ?

Global Bindings Starting With C-x 4:
key             binding
---             -------

C-x 4 C-f       find-file-other-window
C-x 4 C-o       display-buffer
C-x 4 .         xref-find-definitions-other-window
C-x 4 0         kill-buffer-and-window
C-x 4 a         add-change-log-entry-other-window
C-x 4 b         switch-to-buffer-other-window
C-x 4 c         clone-indirect-buffer-other-window
C-x 4 d         dired-other-window
C-x 4 f         find-file-other-window
C-x 4 m         compose-mail-other-window
C-x 4 r         find-file-read-only-other-window

And we already have `C-h k C-x 4 C-f'.  `C-h k'
just _works_ -- for any key sequence.

It ain't broke; please don't fix it.  There are
many other things to work on - real, not imaginary,
problems.

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

[Stefan Monnier]

>> > This means that after binding the current ctl-x-4-map in Emacs core
>> > to the other-window command, 'C-h k C-x 4' will display the help for
>> > that command, not for the whole sequence 'C-h k C-x 4 C-f'.
>> 
>> I don't think we can/should make `C-h k` read all of `C-x 4 C-f`,
>> indeed.  But maybe we could make the following work:
>> `C-x 4 C-h k C-f`.
>
> Quelle horreur !
>
> Farther & farther from Occam - more & more complex.

I don't see what's more or less complex about it.
With other-frame-window `C-x 4` is a (prefix) command.
So just like `C-h k C-u` gives you help about the `C-u` binding,
`C-h k C-x 4` naturally gives you help about the `C-x 4` binding.

So if you're interested in the `C-f` binding available after you hit
`C-x 4`, it's only natural to use `C-x 4 C-h k C-f` (and not only it's
natural, but it's the only sane option unless we break the `C-h k C-x 4`
case).

> We already have `C-x 4 C-h', which shows you
> every `C-x 4' key sequence and its command, with
> a link to its doc.  Que demande le peuple ?

You're talking about the current `C-x 4` which is a keymap.
I'm talking about the case when we've change `C-x 4` to be a prefix
command, as provided by other-frame-window.


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Tue, 14 Jul 2020 01:55:10 -0400
> Cc: Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> 
> > This means that after binding the current ctl-x-4-map in Emacs core
> > to the other-window command, 'C-h k C-x 4' will display the help for
> > that command, not for the whole sequence 'C-h k C-x 4 C-f'.
> 
> I don't think we can/should make `C-h k` read all of `C-x 4 C-f`, indeed.

I think that would be a step back.  Is it indeed not possible to keep
the existing behavior regarding prefixed commands?

> But maybe we could make the following work: `C-x 4 C-h k C-f`.

How would the user remember when to start with C-h and when to type it
in the middle of a key sequence?

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

[Stefan Monnier]

>> But maybe we could make the following work: `C-x 4 C-h k C-f`.
> How would the user remember when to start with C-h and when to type it
> in the middle of a key sequence?

`C-x 4 C-f` would run 2 commands, just like `C-u C-f`, so just like you can't
do `C-x k C-u C-f` (because the `C-x k` stops after `C-u`).

So all the user needs to know is that `C-x 4` is a command and not s keymap.

BTW, we have th same problem with `C-x e e`: I can't do `C-x k C-x e e`
because `C-x k` stops after `C-x e`.  So for the same reason it would be
good to make it possible to do `C-x e C-x k e` to find out what `e` is
really bound to.


        Stefan

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

[Drew Adams]

> >> I don't think we can/should make `C-h k` read all of `C-x 4 C-f`,
> >> indeed.  But maybe we could make the following work:
> >> `C-x 4 C-h k C-f`.
> >
> > Farther & farther from Occam - more & more complex.
> 
> I don't see what's more or less complex about it.

It's a new exception.  And it breaks `C-x 4 C-h'.

And `C-x C-h'?  Does that have different behavior
from `C-x 4 C-h' now, or does that too get broken
the same way?

> With other-frame-window `C-x 4` is a (prefix) command.

"With `other-frame-window'".  Precisely.  That's
apparently the motivation behind this `C-x 4 C-h'
kludge.

A solution looking for a problem engenders the
need for a solution (introducing exceptions) for
a problem it's created.  As they say, "Now you've
got two problems...".

> So just like `C-h k C-u` gives you help about the `C-u` binding,
> `C-h k C-x 4` naturally gives you help about the `C-x 4` binding.

`C-u' is an exception, not the rule.  It's not
a prefix key: it's not bound to a keymap.  It's
bound only to a command.  `C-u' - like what you
want to do to `C-x 4' - uses `set-transient-map'.

You want to make `C-x 4' another such exception,
like `C-u', right?

Try `C-h k C-x'.  What does that do for you?
`C-h k' has always waited for (expected) a full
key sequence.  This is the case in general -
menu, mouse, keyboard, whatever.

(Not to mention that there are 3rd-party help
libraries that let you navigate up, down, and
around the keymap hierarchy, treating prefix
keys the way they are now.  Apparently `C-x 4'
will no longer be an ordinary prefix key, i.e.,
bound to a keymap.  So that will likely break
such help systems.)

> So if you're interested in the `C-f` binding available after you hit
> `C-x 4`, it's only natural to use `C-x 4 C-h k C-f` (and not only it's
> natural, but it's the only sane option unless we break the `C-h k C-x
> 4` case).

I disagree that it's "only natural".  Natural
is as natural does, and it's in the eye of the
beholder or practitioner.

I'd say it's only natural that `C-h k C-x 4 C-f'
does what it does.  `C-h k' reads a key sequence
and tells you what it's bound to - what it does.

> > We already have `C-x 4 C-h', which shows you
> > every `C-x 4' key sequence and its command, with
> > a link to its doc.  Que demande le peuple ?
> 
> You're talking about the current `C-x 4` which is a keymap.
> I'm talking about the case when we've change `C-x 4` to be a prefix
> command, as provided by other-frame-window.

Exactly.  I'm questioning that change.  I'd
like `C-x 4' to continue to be an ordinary
prefix key, i.e., bound to a keymap, and not
to become something exceptional.

That change offer what, that's worth tossing
the standard, longstanding behavior?  Please
answer the questions from the previous mail.
We already have `C-h' following a prefix key,
to give you info about it.  `C-h k' is for
info about a complete key sequence.

(And we already have 3rd-party libraries that
let you explore the keymap hierarchy in detail,
and they typically work by handling real prefix
keys, bound to real keymaps.)

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

[John Yates]

> Quelle horreur !

Absolument!

> Que demande le peuple ?

De la brioche.

/john

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: juri@linkov.net,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Tue, 14 Jul 2020 11:15:53 -0400
> 
> >> But maybe we could make the following work: `C-x 4 C-h k C-f`.
> > How would the user remember when to start with C-h and when to type it
> > in the middle of a key sequence?
> 
> `C-x 4 C-f` would run 2 commands, just like `C-u C-f`, so just like you can't
> do `C-x k C-u C-f` (because the `C-x k` stops after `C-u`).

The problem with C-u is actually my long-time lament.  Making this
"spread" to more commands doesn't sound like progress to me.  What
advantages and exciting new features will this enable, that could
outweigh the downsides?

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

[Juri Linkov]

>> This means that after binding the current ctl-x-4-map in Emacs core
>> to the other-window command, 'C-h k C-x 4' will display the help for
>> that command, not for the whole sequence 'C-h k C-x 4 C-f'.
>
> I don't think we can/should make `C-h k` read all of `C-x 4 C-f`, indeed.
> But maybe we could make the following work: `C-x 4 C-h k C-f`.

Would it be more expected for `C-x 4 C-h k C-f` to show the help buffer
about `C-f` (forward-char) in another window?

The prefix `C-x 4` says "show the output of the next command in
another window" where the next command is `C-h k C-f`.

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

[Drew Adams]

> >> This means that after binding the current ctl-x-4-map in Emacs core
> >> to the other-window command, 'C-h k C-x 4' will display the help for
> >> that command, not for the whole sequence 'C-h k C-x 4 C-f'.
> >
> > I don't think we can/should make `C-h k` read all of `C-x 4 C-f`,
> indeed.
> > But maybe we could make the following work: `C-x 4 C-h k C-f`.
> 
> Would it be more expected for `C-x 4 C-h k C-f` to show the help buffer
> about `C-f` (forward-char) in another window?
> 
> The prefix `C-x 4` says "show the output of the next command in
> another window" where the next command is `C-h k C-f`.

Par exemple.  Good point.

Scratch a bit more, and I won't be surprised if we
stumble on other such dilemmas/surprises.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

If this change will make help commands fail to entirely work,
why do it?

On he other hand, if the change is a great big improvement, I suppose
we can create a mechanism to allow the help commands to work 100% with
this new command.  Please don't fail to make that work.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Monnier]

> The problem with C-u is actually my long-time lament.  Making this
> "spread" to more commands doesn't sound like progress to me.

It also affects `C-x RET c`, which is another standard prefix command.
I think we'll be better off making those prefix commands work well, than
keeping them half-working and then having to avoid introducing more
of them.

> What advantages and exciting new features will this enable, that could
> outweigh the downsides?

Prefix commands give structure to the space of key-bindings.
E.g. the new `C-x 4 4` prefix command makes almost all the special
`foo-other-window` commands (and their key bindings) redundant.

I think prefix commands are a powerful way to design the UI, making it
overall simpler.  I'm not sure if we want to go to something like Vi
(where `forward-word` is split into a `forward` command and a `by-word`
prefix command), but the principle of prefix command appears in
several places, even though it's rarely implemented with as much care as
`C-u` is.



        Stefan


PS: The active region is another similar "structuring tool".

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

[Stefan Monnier]

>>> This means that after binding the current ctl-x-4-map in Emacs core
>>> to the other-window command, 'C-h k C-x 4' will display the help for
>>> that command, not for the whole sequence 'C-h k C-x 4 C-f'.
>>
>> I don't think we can/should make `C-h k` read all of `C-x 4 C-f`, indeed.
>> But maybe we could make the following work: `C-x 4 C-h k C-f`.
>
> Would it be more expected for `C-x 4 C-h k C-f` to show the help buffer
> about `C-f` (forward-char) in another window?

Oh, right!


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: juri@linkov.net,  rms@gnu.org,  emacs-devel@gnu.org
> Date: Wed, 15 Jul 2020 00:06:14 -0400
> 
> > The problem with C-u is actually my long-time lament.  Making this
> > "spread" to more commands doesn't sound like progress to me.
> 
> It also affects `C-x RET c`, which is another standard prefix command.
> I think we'll be better off making those prefix commands work well, than
> keeping them half-working and then having to avoid introducing more
> of them.

What about the solution proposed by Richard: to program something
special for these cases, such that the user won't see any difference?

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

[Juri Linkov]

> Prefix commands give structure to the space of key-bindings.
> E.g. the new `C-x 4 4` prefix command makes almost all the special
> `foo-other-window` commands (and their key bindings) redundant.

It seems one of remaining major problems is how to make the most
frequently used key sequences for other-window commands shorter,
e.g. how to reduce `C-x 4 4 C-x C-f` to just `C-x 4 C-f`.

This suggests there is a need for a new general function that could be
used in a prefix command.  Such function should prepare the environment
for the next command to run it with modified variable bindings.

Currently I have no idea for implementation, but maybe it's possible
for a such function (and the prefix command where it's used) to
return a closure in which the next command should be invoked?

Then it could bind `overriding-terminal-local-map` (instead of using
`set-transient-map`) and also bind `display-buffer-overriding-action`
(instead of using `display-buffer-override-next-command`).

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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > Would it be more expected for `C-x 4 C-h k C-f` to show the help buffer
  > about `C-f` (forward-char) in another window?

For consistency, C-h k C-x 4 C-f should show the help for C-x 4 C-f.
That is find-file-other-window.

C-x 4 C-f is an important command -- don't break it!

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Monnier]

> Then it could bind `overriding-terminal-local-map` (instead of using
> `set-transient-map`)

Not sure what's the difference.

> 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`.

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


        Stefan

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

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Wed, 15 Jul 2020 23:21:15 -0400
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> C-x 4 C-f is an important command -- don't break it!

And likewise "C-x 4 f", IMO.

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

[Juri Linkov]

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

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

[Juri Linkov]

>   > Would it be more expected for `C-x 4 C-h k C-f` to show the help buffer
>   > about `C-f` (forward-char) in another window?
>
> For consistency, C-h k C-x 4 C-f should show the help for C-x 4 C-f.
> That is find-file-other-window.

A special handling of prefix commands could be added to the
implementation of 'C-h k'.

Then instead of saying that the command is 'find-file-other-window',
it could say: "the command is like 'find-file' but displays the buffer
in another window."

> C-x 4 C-f is an important command -- don't break it!

Its effect should remain the same (displaying the output buffer in
another window), but the command namespace will be cleaner by removing
duplicated commands with '-other-window' and '-other-frame' suffixes.

Also it should allow the users to add the effect of displaying the command
output buffer in another window to more commands easily, by just adding
a key binding to the existing non-window command in the 'C-x 4' keymap.

Anyway, before changing the 'C-x 4' keymap we could try this approach only
on project-specific submap 'C-x 4 p' to see how well it works.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > It also affects `C-x RET c`, which is another standard prefix command.

The effect of that modifier is totally uniform.  We should not think
of it as like a prefix command.  It is not similar to this issue.

A numeric argument is also a uniform modifier.  However, plain C-u is
a fishy halfway case.  Because we have made so many commands do
something different after C-u, semantically it makes sense, sort of,
to think of C-u WHATEVER as a different command from plain WHATEVER.
That is why that case is confusing.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Drew Adams]

> > C-x 4 C-f is an important command -- don't break it!
> 
> Its effect should remain the same (displaying the output buffer in
> another window), but the command namespace will be cleaner by removing
> duplicated commands with '-other-window' and '-other-frame' suffixes.

I _want_ separate commands.  They're wonderful.  Beautiful, handy, first-class citizens.

I want to be able to bind a same-window, other-window, or other-frame command to a simple key in this or that mode, depending on what the command does.  For some actions in the same mode I want the same-window command, for other actions I want the other-window command.  For some actions I might not want there to exist a (predefined) other-frame or other-window or same-window command.  Some actions make good sense only for one or two such manifestations.

You apparently see only a (neglible, IMO) upside to the changes being proposed/made.  I see also downsides.

The minor downside of defining multiple commands (same, other-win, other-frame) for the same basic action, and of thus having multiple such in the namespace, doesn't bother me at all.

And in fact, the presence of multiple such in the namespace is a plus in my eyes, not a minus.  A plus interactively and programmatically.

As usual, my somewhat defeatist, rearguard plea is to please, at a bare minimum, give users an easy way to 100% return to the situation ante, i.e., to undo such an "improvement", globally & comprehensively, as well as just for individual instances.

The goal should keep users foremost in mind.  It shouldn't be to simplify the implementation or the code maintenance, or to see how clever we can make the implementation.  It should be all about the users.

> Also it should allow the users to add the effect of displaying the
> command output buffer in another window to more commands easily, by just adding
> a key binding to the existing non-window command in the 'C-x 4' keymap.

As I said earlier: seems like a solution looking for a problem to solve.  I haven't heard of any real problem that will be solved.  Is there one?  What's the disease this cure is for?

> Anyway, before changing the 'C-x 4' keymap we could try this approach
> only on project-specific submap 'C-x 4 p' to see how well it works.

Please don't change `ctl-x-4-map' or any of the others.  If you must fiddle, please fiddle in a new, tiny sandbox off in a corner somewhere.

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

[Stefan Monnier]

>>> 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`.

You mean you're interested in providing a generic way to "set some vars
for the next command"?  I can see why you'd want that, but:
- It's not as uniform as it seems: `overriding-terminal-local-map` needs
  to be set while "reading" the next command but not while running it,
  whereas `display-buffer-overriding-action` needs to be set while
  running the next command and not while reading it.  
- `set-temporary-map` doesn't need to just "set" the var: it needs to
  modify it and then revert the modification (and handle the case where
  some other modification took place in the mean time).  IOW we need
  some way to "add" and "remove" something from that var.  Now, that
  probably applies to other vars, so it would indeed be good to provide some
  more generic support for that.

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

Beware: let-binding a var like that can lead to undesired results if the
command run within the let-binding wants to modify this var (the
modification is typically lost) or make it buffer-local (the temporary
let-bound value may "leak" outside of the let-binding).  IOW, some such
variables want to be let-bound but others prefer to be `setq`.


        Stefan

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > For consistency, C-h k C-x 4 C-f should show the help for C-x 4 C-f.
  > > That is find-file-other-window.

  > A special handling of prefix commands could be added to the
  > implementation of 'C-h k'.

  > Then instead of saying that the command is 'find-file-other-window',
  > it could say: "the command is like 'find-file' but displays the buffer
  > in another window."

That would address this issue.

  > > C-x 4 C-f is an important command -- don't break it!

  > Its effect should remain the same (displaying the output buffer in
  > another window), but the command namespace will be cleaner by removing
  > duplicated commands with '-other-window' and '-other-frame' suffixes.

I see.

That would handle C-x 4 C-f ok, but someone pointed out there is also
C-x 4 f.  People would not like it if that started to do C-x f in another
window.

So I think there needs to be a exception list, a way of defining a few
key sequences starting with C-x 4 so that they depart from the usual
rule and maintain backwards compatibility instead.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I want to be able to bind a same-window, other-window, or
  > other-frame command to a simple key in this or that mode,
  > depending on what the command does.  For some actions in the same
  > mode I want the same-window command, for other actions I want the
  > other-window command.

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.



-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

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

[Drew Adams]

> the feedback I got was that it would be better to
> avoid cluttering the function symbol namespace with
> lots of -other-window commands.

My feedback is that I _want_ separate other-window
(and other-frame) commands.  Explicit commands.

But _not_ in some general, apply-to-all-commands (or
all commands that show something in a window or select
a window).

I want such commands only when and where I want them,
and I want them bound to keys only when and where I
want such bindings.  I don't want something to create
such other-* commands willy nilly, automatically.

IOW, I want just what we have now:

. ability for anyone to explicitly define an other-*
  command

. ability for anyone to bind any same-* or other-*
  command to any key in any mode or other context.

. ability for anyone to _not_ have a given same-*
  or other-* command be bound in a given mode or
  context.

In Dired, for example, for some actions I want to
have _only_ a key that reuses the same window.  For
other actions I want to have _only_ a key that uses
another window - or another frame.  And for still
other actions I want to have keys for _both_, or
all 3, possibilities.

To me, it would be a step backward to treat any of
this stuff in some one-size-fits-all, blanket way:
either by automatically creating other-* commands
for everything, or by automatically creating
bindings for them.

Or by automatically creating the equivalent:
providing keys everywhere, for everything, that
provide other-* behavior without creating other-*
commands.  I want only keys that I or some mode
or other context has decided are the most useful
for that particular context.

I have no problem with the supposed "cluttering
[of] the function symbol namespace" from the
existence of separate other-* commands.

(Perhaps that's partly because I use a completion
framework that isn't bothered by the existence of
two commands `foo' and `foo-other-window' etc.)

To me, this "project" of replacing `C-x 4' by a
command is an anti-feature.  (Same for other
prefix keys.)

And again, though I've asked several times now,
I've seen _no_ description of anything useful that
this project aims to provide.  So far, it seems
only like a thought-to-be-clever solution that's
still looking for a problem to solve.

If the problem is _really_ only "cluttering [of]
the function symbol namespace", then that, to me
(just one user) is 100% a non-problem.

And IMO it's certainly not worth tossing out the
beautiful baby of simple prefix-key bindings to
keymaps with the supposedly too-cluttered-namespace
bathwater.

IMO, that bathwater itself is in fact clean &
clear.  It's a mountain stream, not dirty suds.

Just one opinion.

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

[Juri Linkov]

> So I think there needs to be a exception list, a way of defining a few
> key sequences starting with C-x 4 so that they depart from the usual
> rule and maintain backwards compatibility instead.

I propose the following design:

1. keep the existing 'C-x 4' bindings and other-window commands
   unchanged to maintain backwards compatibility;

2. add a catch-all fallback to ctl-x-4-map and bind it to the command
   invoked when an unbound key is typed after 'C-x 4'.

There are 2 possibilities what to do with an unbound key in this command:

2.1. define a new keymap with mappings from such unbound keys to commands.

For example, using project-prefix-map where "f" is bound to 'project-find-file'
and while project-prefix-map itself is bound to "p" would enable such
key sequences 'C-x 4 p f' to find a project file in another window.

There is no need to add all -other-window variants in such additional keymap,
it should handle the existing no-window commands, and display their buffers
in another window.

2.2. another possibility is when the above keymap doesn't match
     an unbound key then run its global keybinding.

For example, typing 'C-x 4 C-h i' will display the Info manual
in another window.

Now I tried to implement this, but the problem is that the fallback
'[remap t]' doesn't work, for example in:

  (define-key ctl-x-4-map [remap t] 'other-window-prefix)

it has no effect.  Then I discovered this explanation in
(info "(elisp) Remapping Commands"):

     Note that remapping only takes place through active keymaps; for
  example, putting a remapping in a prefix keymap like 'ctl-x-map'
  typically has no effect, as such keymaps are not themselves active.

So it seems remapping in ctl-x-4-map has no effect.

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.

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > > 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),

Sorry, I wasn't following this at that point.

                 but the feedback I got was that it would be better to avoid
  > cluttering the function symbol namespace with lots of -other-window
  > commands.

I think we are miscommunicating very slightly.  There are two closely
related but distinct questions.

1. Whether Drew would like to use that facility to make -other-window
  functions.

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.

   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.

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Monnier]

>> So I think there needs to be a exception list, a way of defining a few
>> key sequences starting with C-x 4 so that they depart from the usual
>> rule and maintain backwards compatibility instead.

In `other-frame-window` this is done via `ofw-transient-map`.


        Stefan

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

[Barry Fishman]

On 2020-07-14 23:32:33 -04, Richard Stallman wrote:
> If this change will make help commands fail to entirely work,
> why do it?
>
> On he other hand, if the change is a great big improvement, I suppose
> we can create a mechanism to allow the help commands to work 100% with
> this new command.  Please don't fail to make that work.

There seems to be alternatives to those proposed.

When getting "C-h k" help and you enter a prefix command, Emacs it
waiting for you to finish the command.  If you then type 'C-h', and that
has no binding it could just list what the bindings at that point are.
The use of C-h after a prefix tends to be use only to list the bindings
anyway, so if it is defined it only tells you that it is a command to
give you what you are looking for.

A less useful though more complex solution is to use tab with "C-h k"
help to first give you a list of possible completions and having to
type tab again to get help for tab itself.

The least work would be to just add a "C-h 4 C-h" command to get help
on the "C-h 4" commands available as is done in many other places.
--
Barry Fishman

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

[Drew Adams]

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

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

[Drew Adams]

> The least work would be to just add a "C-h 4 C-h" command to get help
> on the "C-h 4" commands available as is done in many other places.

`C-h r C-h' already lists all of the `C-x 4' keys
and their commands.  And choosing any of those
then shows you its complete help.

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

[Barry Fishman]

On 2020-07-19 15:38:57 GMT, Drew Adams wrote:
> `C-h r C-h' already lists all of the `C-x 4' keys
> and their commands.  And choosing any of those
> then shows you its complete help.

If you mean "C-x 4 C-h", yes but, "C-h k C-x 4" is left waiting for
further input and "C-h k C-x 4 C-h" just says there is no binding for
it.

There is no universal way to get further information at that point.  If
"C-h k" had a solution it would apply uniformly and not require mucking about
which changing any (other) key bindings.

Should there be a general rule than any partial key sequence have "C-h"
show the possible options?  And if so wouldn't it be more straight
forward to not have to manually define for each possible key sequence,
but still have any exiting such binding still work?

--
Barry Fishman

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

[Drew Adams]

> > `C-h r C-h' already lists all of the `C-x 4' keys
> > and their commands.  And choosing any of those
> > then shows you its complete help.
> 
> If you mean "C-x 4 C-h", yes 

Yep.  Finger-flunked; sorry.

> but, "C-h k C-x 4" is left waiting for further input
> and "C-h k C-x 4 C-h" just says there is no binding for it.

> There is no universal way to get further information at that point.

I guess the info you want at that point is the
info you'd get from `C-x 4 C-h'.  Is that right?

> If "C-h k" had a solution it would apply uniformly and not require mucking
> about which changing any (other) key bindings.

OK.

> Should there be a general rule than any partial key sequence have "C-h"
> show the possible options?

Maybe.

Have you really found this to be a problem?

I haven't.  But I know that some users don't
know about using `C-h' after a prefix key.

And I do get your point, about not wanting to
abandon `C-h k C-x 4' and use `C-x 4 C-h' at
that point.  That doesn't bother me, but OK.

> And if so wouldn't it be more straight
> forward to not have to manually define for each possible key sequence,
> but still have any exi[s]ting such binding still work?

Definitely.  But only if implementing that
doesn't remove/break something else (unlike
what's being proposed in this thread).

No one has to explicitly define a binding for
`C-h' after a prefix key, for example.  (And
as you point out, there is in fact _no_ such
key binding.)  Yes, the same should apply for
what you suggest.

But I don't think the overall discussion is
really about `C-h k' and its getting to the
help for a prefix key (e.g. help like what
`C-h 4 C-h' shows).

But if it were, then my reply would be (besides
perhaps doing something such as you suggest -
which AFAIK doesn't require changes such as
those proposed), to instead provide something
like the help that key completion (library
Key See or Icicles) or `which-key' provides.

https://www.emacswiki.org/emacs/KeySee

https://www.emacswiki.org/emacs/Icicles

https://github.com/justbur/emacs-which-key

Those all, like an appended `C-h', let you see
the keys that complete a prefix key, as well
as their commands.  And unlike `C-h', they
don't interrupt use of the prefix key.

(In addition, Icicles lets you get the full
doc string for any such completing key.)

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

[Juri Linkov]

> In `other-frame-window` this is done via `ofw-transient-map`.

`C-x 4` could fall back to `ofw-transient-map` when `C-x 4` is
followed by an unbound key that has a binding in `ofw-transient-map`.
Otherwise, when there is no binding in the `C-x 4` keymap,
and no binding in `ofw-transient-map` then the key sequence
could be followed by a global binding.

But such fallback currently is impossible to implement because
`[remap t]` doesn't work in `ctl-x-4-map`.  Tried with:

  (define-key ctl-x-4-map [remap t] 'other-window-prefix)

then typed `C-x 4 C-x C-f` and the result is:

  C-x 4 C-x C-f is undefined

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

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I propose the following design:

  > 1. keep the existing 'C-x 4' bindings and other-window commands
  >    unchanged to maintain backwards compatibility;

  > 2. add a catch-all fallback to ctl-x-4-map and bind it to the command
  >    invoked when an unbound key is typed after 'C-x 4'.

LGTM.

  > There are 2 possibilities what to do with an unbound key in this command:

  > 2.1. define a new keymap with mappings from such unbound keys to commands.

Why do we need this -- can't we define those exceptions directly
in ctl-x-4-map?

  > 2.2. another possibility is when the above keymap doesn't match
  >      an unbound key then run its global keybinding.

  > For example, typing 'C-x 4 C-h i' will display the Info manual
  > in another window.

  > Now I tried to implement this, but the problem is that the fallback
  > '[remap t]' doesn't work, for example in:

  >   (define-key ctl-x-4-map [remap t] 'other-window-prefix)

We could make that work, one way or another.


-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

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

[Stefan Monnier]

>> In `other-frame-window` this is done via `ofw-transient-map`.
> `C-x 4` could fall back to `ofw-transient-map` when `C-x 4` is
> followed by an unbound key that has a binding in `ofw-transient-map`.
> Otherwise, when there is no binding in the `C-x 4` keymap,
> and no binding in `ofw-transient-map` then the key sequence
> could be followed by a global binding.

I don't understand how that's different from how `ofw-transient-map` is
used in `other-frame-window`.

> But such fallback currently is impossible to implement because
> `[remap t]` doesn't work in `ctl-x-4-map`.  Tried with:
>
>   (define-key ctl-x-4-map [remap t] 'other-window-prefix)

`other-frame-window` uses `set-transient-map`, not [remap t] (which
indeed is basically unusable, at least not without introducing weird
corner cases).

And of course, it would still suffer from the same problem of how to
make `C-x k` return the command bound to `C-x 4 C-f` or to `C-x e e e`.


        Stefan

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

[Stefan Monnier]

> 2. add a catch-all fallback to ctl-x-4-map and bind it to the command
>    invoked when an unbound key is typed after 'C-x 4'.

I don't know how to implement that in a way that works well enough
(i.e. without suffering from weird corner case behaviors due to
interactions with `input-decode-map`, `function-key-map`, etc...).

`set-transient-map` is the least bad I way I found to provide this kind
of behavior.


        Stefan

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

[Juri Linkov]

>> `C-x 4` could fall back to `ofw-transient-map` when `C-x 4` is
>> followed by an unbound key that has a binding in `ofw-transient-map`.
>> Otherwise, when there is no binding in the `C-x 4` keymap,
>> and no binding in `ofw-transient-map` then the key sequence
>> could be followed by a global binding.
>
> I don't understand how that's different from how `ofw-transient-map` is
> used in `other-frame-window`.

This was intended to address TODO items in `other-frame-window`.
The first TODO item:

;; - Pay attention to bindings added to ctl-x-4-map and ctl-x-5-map

can be solved by just leaving the existing ctl-x-4-map and ctl-x-5-map
as they are now.  And by adding to these maps the [remap t] fallback
bound to the `ofw--set-prefix` command it would be possible to use key bindings
from `ofw-transient-map` where keys don't need to be bound to special
-other-window variants.

And when no key is found in `ofw-transient-map`, then the global binding
could be appled.  For example, `C-x 4 C-h i' could show the Info manual
in another window.

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

[Sean Whitton]

Hello,

On Sat 18 Jul 2020 at 10:28PM -04, Richard Stallman wrote:

> I think we are miscommunicating very slightly.  There are two closely
> related but distinct questions.
> [...]

Thanks, I see what you mean.

-- 
Sean Whitton