C-o (was: Proposal: new default bindings for winner and windmove)

C-o (was: Proposal: new default bindings for winner and windmove)

[Johan Myréen]

[-- Attachment #1: Type: text/plain, Size: 762 bytes --]

>
> I can see someone doing C-o foo bar but I don't see the benefit compared
> to foo bar RET


The benefit is that C-o opens a new blank line to type on, instead of
prepending what you are writing to the pre-existing text on the line, which
I find very distracting. Also, I might want to do a quick edit to what I
have typed so far (maybe to fix a typo before I forget it's there), and
then return to add new text to the line. If I open a new blank line with
C-o, I just type C-e to continue typing, but if the line is still stringed
together with the old line, then finding the correct point is a pita.

Note that the vi editor also has not only one, but two "open line" commands
"o" and "O", for opening a line below and above the current line,
respectively.

[-- Attachment #2: Type: text/html, Size: 1018 bytes --]

Re: C-o (was: Proposal: new default bindings for winner and windmove)

[Jean Louis]

* Johan Myréen <johan.myreen@gmail.com> [2024-07-03 22:33]:
> >
> > I can see someone doing C-o foo bar but I don't see the benefit compared
> > to foo bar RET
> 
> 
> The benefit is that C-o opens a new blank line to type on, instead of
> prepending what you are writing to the pre-existing text on the line, which
> I find very distracting. Also, I might want to do a quick edit to what I
> have typed so far (maybe to fix a typo before I forget it's there), and
> then return to add new text to the line. If I open a new blank line with
> C-o, I just type C-e to continue typing, but if the line is still stringed
> together with the old line, then finding the correct point is a pita.
> 
> Note that the vi editor also has not only one, but two "open line" commands
> "o" and "O", for opening a line below and above the current line,
> respectively.

Just confirming on the older thread, that I am frequently using C-o
and find it very useful as explained abve by Johan.

-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

✡️🛡️ Proudly standing with Israel, a nation rooted in history and culture. Let's condemn hatred and promote understanding.

In support of Richard M. Stallman
https://stallmansupport.org/

Re: C-o (was: Proposal: new default bindings for winner and windmove)

[Emanuel Berg]

Jean Louis wrote:

>> Note that the vi editor also has not only one, but two
>>  "open line" commands "o" and "O", for opening a line below
>>  and above the current line, respectively.
>
> Just confirming on the older thread, that I am frequently
> using C-o and find it very useful as explained abve
> by Johan.

I also bind it to a bunch of keys.

As a prefix key, so I can do, e.g.

(keymap-global-set "C-o i" #'beginning-of-buffer)
(keymap-global-set "C-o k" #'end-of-buffer)

and many more.

See `define-prefix-command'.

-- 
underground experts united
https://dataswamp.org/~incal

Proposal: new default bindings for winner and windmove

[Daniel Colascione]

Today, winner binds C-c LEFT  and C-c RIGHT for window configuration 
undo and redo, respectively. This set of bindings has three problems:

  1) the bindings occupy binding space on important keys, LEFT and 
RIGHT, for functions that are rarely used,

2) the winner binding space isn't logically connected to window 
management, and

3) the bindings don't work on terminals without LEFT and RIGHT.

How about we set up these bindings instead?

C-x 4 C-/ winner-undo

M-- C-x 4 C-/ winner-redo

This way, a winner undo has the same binding as editing undo, but under 
C-x 4, which means window management stuff.

(Also: is there any reason we shouldn't enable winner by default?)

Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and 
DWIM for people automatically, enabled by default.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

> M-- C-x 4 C-/ winner-redo
>
> This way, a winner undo has the same binding as editing undo, but under C-x
> 4, which means window management stuff.
>
> (Also: is there any reason we shouldn't enable winner by default?)

IIUC these features somewhat overlap with the (new) features introduced
with the (frame-level) tab-bar, so it would likely be good to try and
integrate them better.

As for a key-binding, `C-x 4` might be a good prefix for it, tho note
that `C-x 5` is also a good choice (since winner does not operate on
a window but on the windows within a frame).

Count me as a vote in favor of using a key-binding like the one you suggest.

> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> for people automatically, enabled by default.

That sounds even better (and we could have similar commands in `C-x 5`
to select frames based on their location on the screen).


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

A few years ago, Daniel suggested:
> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
> for people automatically, enabled by default.

AFAICT we still don't actually provide any keybindings for the windmove
commands by default.  Did I miss a controversy about that, or did it
just fall through the cracks?

[ I mean, I assume there are different opinions about which set of keybindings
  is the best, but it seems to me that it should not be that hard to
  find a default set of keybindings that's better than no keybindings
  at all.  ]


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> A few years ago, Daniel suggested:
>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>> for people automatically, enabled by default.
>
> AFAICT we still don't actually provide any keybindings for the windmove
> commands by default.  Did I miss a controversy about that, or did it
> just fall through the cracks?

FWIW, I don't remember any controversy either, so my guess is that it
just fell through the cracks.

Re: Proposal: new default bindings for winner and windmove

[Stefan Monnier]

Stefan Kangas [2024-06-21 15:39:09] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> A few years ago, Daniel suggested:
>>> Likewise, for windmove, we can bind C-x 4 {left, right, up, down} and DWIM
>>> for people automatically, enabled by default.
>> AFAICT we still don't actually provide any keybindings for the windmove
>> commands by default.  Did I miss a controversy about that, or did it
>> just fall through the cracks?
> FWIW, I don't remember any controversy either, so my guess is that it
> just fell through the cracks.

Well, seeing the disproportionately intense fire coming from Alan and Po
Lu on such a minor proposal is a good reminder why people like to stay
away from emacs-devel.


        Stefan

Re: Proposal: new default bindings for winner and windmove

[Stefan Kangas]

Generally speaking, we provide an extensive set of keybindings.  These
defaults ensure that Emacs is as usable as possible out-of-the-box.

There is of course room for reasonable people to agree or disagree to
what extent this or that keybinding is useful enough to provide
out-of-the-box; this is largely a matter of taste and how you use Emacs.

However, I'm not convinced by the argument that there is some
"keybinding real estate" that we are somehow occupying by adding _any_
new defaults, since users can change keybindings relatively easily.
So there is no way around the need to consider each new proposal
individually.

Now, it is clear that there is a need for users to navigate between
windows.  The need for even more specialized commands (e.g. windmove,
ace-window) is arguably bigger today than it used to be.  Users will
routinely have huge monitors where they can have a large number of
windows visible at the same time.  What served users in 1995 will not
necessarily be enough for the needs of users today.

In my view, having considered this discussion in full, the benefits of
adding these key bindings, favored by several developers, therefore
outweigh the perceived drawbacks.

- The proposal is to add global bindings, which AFAIU means that they
  will not affect people that are binding these keys to something else
  (whether globally or in specific modes).

- People that do not like these keys do not need to use them, or they
  can unbind them, or rebind them to something else.

- The relevant windmove commands are already autoloaded.

- There is no need to deprecate anything to add these bindings.

Thus, I don't think I see any compelling reason not to go ahead with
this change.  I would propose that we now start discussing the specifics
of how to go about doing that (patches, proposed alternative solutions).

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Stefan.

On Sun, Jun 30, 2024 at 18:29:03 -0700, Stefan Kangas wrote:
> Generally speaking, we provide an extensive set of keybindings.  These
> defaults ensure that Emacs is as usable as possible out-of-the-box.

> There is of course room for reasonable people to agree or disagree to
> what extent this or that keybinding is useful enough to provide
> out-of-the-box; this is largely a matter of taste and how you use Emacs.

> However, I'm not convinced by the argument that there is some
> "keybinding real estate" that we are somehow occupying by adding _any_
> new defaults, since users can change keybindings relatively easily.
> So there is no way around the need to consider each new proposal
> individually.

The above is true, but it misses the point.  That point is that once the
Emacs maintenance team has added a _default_ binding, that can never in
the future be changed.  People will scream "backward compatibility"
until the heat death of the universe.

In that sense, "keybinding real estate" very much is a real issue - we
can only add so many default key bindings, and once added they are
difficult to change or to remove.

> Now, it is clear that there is a need for users to navigate between
> windows.  The need for even more specialized commands (e.g. windmove,
> ace-window) is arguably bigger today than it used to be.  Users will
> routinely have huge monitors where they can have a large number of
> windows visible at the same time.  What served users in 1995 will not
> necessarily be enough for the needs of users today.

This is one of these user dependant things.  For some users,
sophisticated window changing commands will be essential for using Emacs
at all, others simply won't need them, and there will be few users in
between.

> In my view, having considered this discussion in full, the benefits of
> adding these key bindings, favored by several developers, therefore
> outweigh the perceived drawbacks.

That "perceived" there is a mistake.  The drawbacks are real.  At the
very least, such usage is liable to provoke a long, withering post from
Drew Adams.  ;-)

> - The proposal is to add global bindings, which AFAIU means that they
>   will not affect people that are binding these keys to something else
>   (whether globally or in specific modes).

> - People that do not like these keys do not need to use them, or they
>   can unbind them, or rebind them to something else.

As already said, those people don't include the Emacs maintainers when
considering default key bindings.

> - The relevant windmove commands are already autoloaded.

> - There is no need to deprecate anything to add these bindings.

> Thus, I don't think I see any compelling reason not to go ahead with
> this change.  I would propose that we now start discussing the specifics
> of how to go about doing that (patches, proposed alternative solutions).

I think I would agree with the somebody else that suggested enabling
these keys by a minor mode.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Dmitry Gutov]

Hi Alan,

On 01/07/2024 13:07, Alan Mackenzie wrote:
> The above is true, but it misses the point.  That point is that once the
> Emacs maintenance team has added a_default_  binding, that can never in
> the future be changed.  People will scream "backward compatibility"
> until the heat death of the universe.

People screaming "backward compatibility" for each and every reason can 
indeed be a problem.

We should be able to change default key bindings more freely than we do now.

Re: Proposal: new default bindings for winner and windmove

[Alan Mackenzie]

Hello, Dmitry.

On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote:
> Hi Alan,

> On 01/07/2024 13:07, Alan Mackenzie wrote:
> > The above is true, but it misses the point.  That point is that once the
> > Emacs maintenance team has added a_default_  binding, that can never in
> > the future be changed.  People will scream "backward compatibility"
> > until the heat death of the universe.

> People screaming "backward compatibility" for each and every reason can 
> indeed be a problem.

Yes, but it's a difficult problem.  I would be screaming if somebody
suggested removing the bindings C-o or C-M-o, for example.  I use these
all the time.  But if I were the only user of them, it would be
difficult to argue for their retention in the default key map.

On the other hand, C-x w h (highlight-regexp) already has a "more
modern" binding M-s h r, so although I wouldn't be enthused about the
removal of C-x w h, I wouldn't object to it either.

> We should be able to change default key bindings more freely than we do now.

Yes, but...  Every time we do this, we're upsetting _sombody_'s work
flow.  I don't see any way of getting this increased freedom to change.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Proposal: new default bindings for winner and windmove

[Daniel Colascione]

[Re-sending: accidentally sent narrow reply]

Alan Mackenzie <acm@muc.de> writes:
> Hello, Dmitry.
>
> On Mon, Jul 01, 2024 at 14:25:51 +0300, Dmitry Gutov wrote:
>> Hi Alan,
>
>> On 01/07/2024 13:07, Alan Mackenzie wrote:
>> > The above is true, but it misses the point.  That point is that once the
>> > Emacs maintenance team has added a_default_  binding, that can never in
>> > the future be changed.  People will scream "backward compatibility"
>> > until the heat death of the universe.
>
>> People screaming "backward compatibility" for each and every reason can 
>> indeed be a problem.
>
> Yes, but it's a difficult problem.  I would be screaming if somebody
> suggested removing the bindings C-o or C-M-o, for example.  I use these
> all the time.  But if I were the only user of them, it would be
> difficult to argue for their retention in the default key map.

I still think we need to find a better binding for C-o, FWIW.
I recognize I'm in the minority on this position though, but still, I
think I've used C-o maybe once or twice ever.

What do you use it for?

> On the other hand, C-x w h (highlight-regexp) already has a "more
> modern" binding M-s h r, so although I wouldn't be enthused about the
> removal of C-x w h, I wouldn't object to it either.

What do you think of my previous keybindings-editions proposal?

>> We should be able to change default key bindings more freely than we do now.
>
> Yes, but...  Every time we do this, we're upsetting _sombody_'s work
> flow.  I don't see any way of getting this increased freedom to change.

I love how https://xkcd.com/1172/ is about us.

Re: Proposal: new default bindings for winner and windmove

[Po Lu]

Daniel Colascione <dancol@dancol.org> writes:

> I still think we need to find a better binding for C-o, FWIW.
> I recognize I'm in the minority on this position though, but still, I
> think I've used C-o maybe once or twice ever.
>
> What do you use it for?

What do you expect?  Opening a new line?  Every Emacs-like editor of the
past several decades have bound such a command to C-o, and proposing to
change it now is plainly absurd.  Even GNOME does, if "Emacs shortcuts"
are enabled, to the best of my knowledge.

> I love how https://xkcd.com/1172/ is about us.

It means we're doing our job.

C-o (was: Proposal: new default bindings for winner and windmove)

[Stefan Monnier]

>> I still think we need to find a better binding for C-o, FWIW.
[...]
>> What do you use it for?

I'm also curious to know how people use `C-o`, which I never ever use.

> What do you expect?  Opening a new line?

Not sure what answer Daniel was looking for, but for me at least the
question is about the "context" where you use `C-o`.  E.g. I can see
someone doing

    C-o foo bar

but I don't see the benefit compared to

    foo bar RET

It probably comes down to habit, but I'm hoping there's more to it
than that.


        Stefan

Re: C-o (was: Proposal: new default bindings for winner and windmove)

[Stefan Kangas]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Not sure what answer Daniel was looking for, but for me at least the
> question is about the "context" where you use `C-o`.  E.g. I can see
> someone doing
>
>     C-o foo bar
>
> but I don't see the benefit compared to
>
>     foo bar RET
>
> It probably comes down to habit, but I'm hoping there's more to it
> than that.

When I want to insert a new line above the current one, the easiest way
is two keys:

    C-a C-o

Without C-o, I'd need to use three keys:

    C-a RET <up>

I also use it to split lines and keep point at the current location.
For example, when in the middle of some line, I press

    C-o

Instead of

    RET <left>

It's minor, admittedly, but I'm so used to it that I'd miss it if I
didn't have it.  Vim has similar commands on o and O, IIRC.

Re: C-o (was: Proposal: new default bindings for winner and windmove)

[Per Starbäck]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

>
>  I can see
> someone doing
>
>     C-o foo bar
>
> but I don't see the benefit compared to
>
>     foo bar RET
>
> It probably comes down to habit, but I'm hoping there's more to it
> than that.
>

I have realized I want to add more text somewhere in the text:
----------------------------------------------------------------------
This is the beginning of the text before the insertion. Here is the
end of the text, after the insertion.
----------------------------------------------------------------------
Point is on "H" in "Here". Before typing the new text I do C-o to get the
continuation out of the way while typing. I wouldn't do that if I'm just
adding something short, but if I'm adding a longer text I would.
In programming I would also do that if adding something longer or something
complicated. It feels better to be at the end of the line when adding text
than to push text in front of you, which can look a bit disturbing,
especially if it is long enough to be broken over to the next line.

I guess this is mostly by habit, but I see at least some advantages of
entering text at the end of the line. Then it's easier to C-e back to point
of entry if I go back to revise something just written, and I can use the
special case of C-t  for quick fixing. Also pushing text in front of me
will be a problem for ispell-word and other commands that look up the
current word. I could make sure to position myself before a space to avoid
that problem, but that would be an extra step to make where just C-o is
simpler.

[-- Attachment #2: Type: text/html, Size: 1912 bytes --]