RE: C-o

RE: C-o

[Drew Adams]

> >>> What do you use it for?
> > I'm also curious to know how people use `C-o`, which I never ever use.

I wasn't going to chime in on this thread...

My use of `C-o' is, well, peculiar.  I almost
don't use it.

I keep its default binding, which I never use
it for.  I use it only to try/test a command
I want to temporarily bind to a repeatable,
simple key that won't interfere with bindings
I really do use.  I do this (fairly often):

 M-x global-set-key RET C-o <some command
 I want to use temporarily, perhaps repeatedly
 (by just holding it down)> RET

Yeah, I know, seems a waste of such a simple,
repeatable key.  But it's precisely the
uselessness to me of that binding that keeps
the key free for me mentally.  In effect, I've
unconsciously tossed it onto the No-Default
Free List.

Needless to say, I do NOT want its default
binding to be changed to some command that's
useful but not repeatable.

I dread this thread, given that it has the
possibility that Emacs will change the useless
binding of `C-o' to some command that's useful
but not repeatable.  (Repeatable keys not at
the end of a prefix key are indeed rare).

IOW, it's a bad default binding, but therein
lies its usefulness: it could be worse.

[ The only reasonable alternative to binding a
  simple repeatable key to a repeatable command
  is to bind it as a prefix key.  That's what
  we've done for keys such as `C-x'.  That's
  OK.  But to bind a simple repeatable key to a
  command that, e.g., prompts for something is
  a mortal sin. Thou Shalt Not Waste. ]

  - Church of Emacs

I was content to let this sleeping dog lie.
Now that it's awakened, Bonjour les dégats...

RE: C-o

[Daniel Colascione]

On July 2, 2024 11:41:55 AM EDT, Drew Adams <drew.adams@oracle.com> wrote:
>> >>> What do you use it for?
>> > I'm also curious to know how people use `C-o`, which I never ever use.
>
>I wasn't going to chime in on this thread...
>
>My use of `C-o' is, well, peculiar.  I almost
>don't use it.
>
>I keep its default binding, which I never use
>it for.  I use it only to try/test a command
>I want to temporarily bind to a repeatable,
>simple key that won't interfere with bindings
>I really do use.  I do this (fairly often):
>
> M-x global-set-key RET C-o <some command
> I want to use temporarily, perhaps repeatedly
> (by just holding it down)> RET
>
>Yeah, I know, seems a waste of such a simple,
>repeatable key.  But it's precisely the
>uselessness to me of that binding that keeps
>the key free for me mentally.  In effect, I've
>unconsciously tossed it onto the No-Default
>Free List.
>
>Needless to say, I do NOT want its default
>binding to be changed to some command that's
>useful but not repeatable.
>
>I dread this thread, given that it has the
>possibility that Emacs will change the useless
>binding of `C-o' to some command that's useful
>but not repeatable.  (Repeatable keys not at
>the end of a prefix key are indeed rare).


If the default binding for C-o changed, how would your workflow change? Are you imagining we'd bind C-o to some *new* functionality for which we didn't have other bindings, forcing you to forego this functionality, change your habits, or bind the new functionality to some other key yourself?

>
>IOW, it's a bad default binding, but therein
>lies its usefulness: it could be worse.
>
>[ The only reasonable alternative to binding a
>  simple repeatable key to a repeatable command
>  is to bind it as a prefix key.  That's what
>  we've done for keys such as `C-x'.  That's
>  OK.  But to bind a simple repeatable key to a
>  command that, e.g., prompts for something is
>  a mortal sin. Thou Shalt Not Waste. ]
>
>  - Church of Emacs
>
>I was content to let this sleeping dog lie.
>Now that it's awakened, Bonjour les dégats...
>

Re: C-o

[Alfred M. Szmidt]

Seeing how hard it is to agree on adding a new keybinding where none
exist, can we not descend into madness where we fload ideas to modifiy
things that have existed in Emacs since TECO days -- suggesting to
modify C-o is a hornets nest that one shouldn't touch.

Re: C-o

[Stefan Monnier]

> Seeing how hard it is to agree on adding a new keybinding where none
> exist, can we not descend into madness where we fload ideas to modifiy
> things that have existed in Emacs since TECO days -- suggesting to
> modify C-o is a hornets nest that one shouldn't touch.

To clarify: I started this `C-o` subthread for the sole purpose of
understanding what I'm missing.  I have no intention to change the `C-o`
binding (I'd even argue it's good to keep such a short "useless" binding
around since it acts as a kind of "user-reserved" key).


        Stefan

RE: [External] : Re: C-o

[Drew Adams]

> (I'd even argue it's good to keep such a short "useless" binding
> around since it acts as a kind of "user-reserved" key).

Great minds think alike. ;-)

Re: C-o

[Daniel Colascione]

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

>> Seeing how hard it is to agree on adding a new keybinding where none
>> exist, can we not descend into madness where we fload ideas to modifiy
>> things that have existed in Emacs since TECO days -- suggesting to
>> modify C-o is a hornets nest that one shouldn't touch.
>
> To clarify: I started this `C-o` subthread for the sole purpose of
> understanding what I'm missing.  I have no intention to change the `C-o`
> binding (I'd even argue it's good to keep such a short "useless" binding
> around since it acts as a kind of "user-reserved" key).

Same here.  It might also be useful to think about whether open-line can
be made more useful or DWIM-y in a way that doesn't break compatibility.

Re: C-o

[Stefan Monnier]

> Same here.  It might also be useful to think about whether open-line can
> be made more useful or DWIM-y in a way that doesn't break compatibility.

Many people mentioned the use of `C-o` specifically because it's not as
DWIMish as RET, so it sounds like it's probably better to leave
it alone.


        Stefan

Re: C-o

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Cc: drew.adams@oracle.com, dmitry@gutov.dev, monnier@iro.umontreal.ca,
>  luangruo@yahoo.com, acm@muc.de, stefankangas@gmail.com, emacs-devel@gnu.org
> Date: Tue, 02 Jul 2024 13:18:34 -0400
> 
> Seeing how hard it is to agree on adding a new keybinding

It isn't hard, at least not in this case.  You just sometimes need to
ignore messages posted here that don't affect the actual
decision-making process.

> can we not descend into madness where we fload ideas to modifiy
> things that have existed in Emacs since TECO days -- suggesting to
> modify C-o is a hornets nest that one shouldn't touch.

Don't worry, C-o will not be changed any time soon.  People can talk
all they want, it's a free forum.

Re: Re: C-o

[chad]

[-- Attachment #1.1: Type: text/plain, Size: 813 bytes --]

First someone posts a message saying effectively "I am curious about
people's use of [a keybinding]. I am *not* suggesting any change."

Then there are multiple messages from long-standing members of the mailing
list, objecting to the idea of changing [the keybinding].

Then there's a post from a long-time maintainer, saying essentially
"getting things done is not necessarily hard; you just sometimes need to
ignore a bunch of messages posted to emacs-devel".

On the one hand, accidents happen, we don't need "email police", etc. On
the other hand it surely seems like conversation and cooperation via
emacs-devel is vastly worse than it was in the 90's, 2000's, and 2010's.

Is there anything that can/should be done, aside from "everyone try to do a
better job with their own communication"?

Thanks,
~Chad

[-- Attachment #1.2: Type: text/html, Size: 1030 bytes --]

[-- Attachment #2: Type: text/plain, Size: 92 bytes --]

---
via emacs-tangents mailing list (https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: C-o

[Dr. Arne Babenhauserheide]

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

Drew Adams <drew.adams@oracle.com> writes:

>> >>> What do you use it for?
>> > I'm also curious to know how people use `C-o`, which I never ever use.
>
> I wasn't going to chime in on this thread...

I regularly use C-o. It’s pretty useful to add newlines without
automation which cuts in on pressing Enter.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 1125 bytes --]

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

[Po Lu]

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.

The advantage is that it is possible to continue typing on the current
line after opening another, as may be desired when entering parameters
to functions, and in similar contexts?  It's not strictly proper to
treat of the two operations in terms of their relative advantages,
moreover, they are simply fundamentally incomparable.

Consider the scenario of inserting a parameter between these two:

  x_y_z (a_voluminous_identifier (), composed_of_polysyllables ());

At the cost of two additional keystrokes (C-f and TAB), neighboring
parameters will not move as the new parameter is input.  This example
was just taken from the lossage of an actual editing session.

Re: C-o

[Gerd Möllmann]

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

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

I'm using it relatively often, but almost exclusively in C-a C-o.

Re: C-o

[Visuwesh]

[திங்கள் ஜூலை 01, 2024] Stefan Monnier wrote:

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

I primarily use it when I'm rewriting a sentence.  I like to keep the
old sentence around to compare it with the rewritten one but it is
distracting to have them in the same paragraph so I move to beginning of
the sentence if required and type C-o.  I could type RET but that does
not preserve the point.  Finally, I join the lines together and kill the
old sentence (I have M-j behave like M-- M-^).  Note how I never have to
move the point except initially.
[ I should say that I find it more natural to think and manipulate text
  vertically downwards rather than vertically upwards like Emacs
  commands do.  Which is why I find it hard to wrap my brain around
  transpose-lines and delete-indentation.  It may be due to my using vi
  before Emacs.  ]

Like Po Lu says, it also comes in handy when you're typing in function
parameters too.

I started using C-o after enabling hard newlines though.  Although RET
still inserts hard newlines, my brain still thinks of RET as inserting
soft newlines so I started to use C-o.  Then I found cases for it
outside of the hard-soft newline thingy.

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

I hope I provided some context.  Preservation of the point is very
handy.  I think I would enjoy C-M-o more in prog-mode but it is a lot
more cumbersome to type.  Perhaps, I should try rebinding C-o to C-M-o.

Re: C-o

[Dmitry Gutov]

On 02/07/2024 06:26, Stefan Monnier wrote:
>>> 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

A lot of times I used it due to the expectation that RET will reindent 
the current line and will do so incorrectly (which happens).

Looks like C-j is a possible alternative, but somehow that didn't grow 
into the muscle memory, and in some buffers it does something different 
(e.g. inside *scratch*).

Re: C-o

[Po Lu]

Dmitry Gutov <dmitry@gutov.dev> writes:

> A lot of times I used it due to the expectation that RET will reindent
> the current line and will do so incorrectly (which happens).
>
> Looks like C-j is a possible alternative, but somehow that didn't grow
> into the muscle memory, and in some buffers it does something
> different (e.g. inside *scratch*).

For a less embellished alternative to C-j or RET, C-q C-j is probably
the better option.

Re: C-o

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  Daniel Colascione
>  <dancol@dancol.org>,  Alan Mackenzie <acm@muc.de>,  Stefan Kangas
>  <stefankangas@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 02 Jul 2024 21:06:09 +0800
> 
> Dmitry Gutov <dmitry@gutov.dev> writes:
> 
> > A lot of times I used it due to the expectation that RET will reindent
> > the current line and will do so incorrectly (which happens).
> >
> > Looks like C-j is a possible alternative, but somehow that didn't grow
> > into the muscle memory, and in some buffers it does something
> > different (e.g. inside *scratch*).
> 
> For a less embellished alternative to C-j or RET, C-q C-j is probably
> the better option.

Only if you are young enough to not have C-j burned into your muscle
memory as what RET does in most places in Emacs nowadays.

Old Sun keyboards had an LFD key, and Emacs used it a lot in old
versions.  Which made C-j anything but a simple newline key.

And having to quote a key is a sign of a key-binding bug in my book.

Re: C-o

[Alfred M. Szmidt]

   > > A lot of times I used it due to the expectation that RET will reindent
   > > the current line and will do so incorrectly (which happens).
   > >
   > > Looks like C-j is a possible alternative, but somehow that didn't grow
   > > into the muscle memory, and in some buffers it does something
   > > different (e.g. inside *scratch*).
   > 
   > For a less embellished alternative to C-j or RET, C-q C-j is probably
   > the better option.

   Only if you are young enough to not have C-j burned into your muscle
   memory as what RET does in most places in Emacs nowadays.

There are also a few where there is quite a big difference, e.g., in
any "REPL" like setting where C-j and RET have very different
behaviour.  Say, a shell buffer... RET behaviour depends on the mode
more often than not, while C-o and C-j generally don't.	

   Old Sun keyboards had an LFD key, and Emacs used it a lot in old
   versions.  Which made C-j anything but a simple newline key.

   And having to quote a key is a sign of a key-binding bug in my book.

Re: C-o

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> Only if you are young enough to not have C-j burned into your muscle
> memory as what RET does in most places in Emacs nowadays.
>
> Old Sun keyboards had an LFD key, and Emacs used it a lot in old
> versions.  Which made C-j anything but a simple newline key.

I think by "less embellished C-j or RET", I meant a command that inserts
a line feed character, which remains the same whether entered as Ctrl+j
or XK_Linefeed on the keyboard.

> And having to quote a key is a sign of a key-binding bug in my book.

What's the alternative?

Re: C-o

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: dmitry@gutov.dev,  monnier@iro.umontreal.ca,  dancol@dancol.org,
>   acm@muc.de,  stefankangas@gmail.com,  emacs-devel@gnu.org
> Date: Wed, 03 Jul 2024 17:24:10 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> I think by "less embellished C-j or RET", I meant a command that inserts
> a line feed character, which remains the same whether entered as Ctrl+j
> or XK_Linefeed on the keyboard.
> 
> > And having to quote a key is a sign of a key-binding bug in my book.
> 
> What's the alternative?

C-o, of course, what else?

Re: C-o

[Po Lu]

Eli Zaretskii <eliz@gnu.org> writes:

> C-o, of course, what else?

To produce the same effect, one must also type "C-n", which still
amounts to two keystrokes.  But I see your point.

Re: C-o

[T.V Raman]

A long time ago I started using C-o as my outline prefix key and put
open-line on C-o o Yes, Emacs needs more modifiers! I also now use xcape
to turn the Windows modifier keys into C-x and C-c -- helps the strain
on my  hands, C-x especially causes stress, even if you use caps-lock as
CTRL.

-- 

Re: C-o

[Alfred M. Szmidt]

   A long time ago I started using C-o as my outline prefix key and put
   open-line on C-o o Yes, Emacs needs more modifiers! 

It is not Emacs that needs more bucky keys, it has Control, Meta,
Super, and Hyper .. on top of Shift.  The issue is that keyboards make
anything beyond Meta impossible to type.  What would be nice is
dedicated keys, C-x 4 and C-x 5 could have a dedicated <window> and
<frame> key (they aren't modifiers ..).

   I also now use xcape to turn the Windows modifier keys into C-x and
   C-c -- helps the strain on my hands, C-x especially causes stress,
   even if you use caps-lock as CTRL.

I have Control mapped to the key beside the Space bar, as intended.
Control should be used for the most frequent things one does in Emacs,
Meta for things that are slightly larger and less common but common
enough.  C-M-.. expanding the scope of an action, etc.

That is at least how Emacs was intended to be ..

Re: C-o

[Michael Heerdegen via Emacs development discussions.]

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

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

I can only add something trivial: contrary to RET, C-o doesn't move
point, which is sometimes what I want, and sometimes not.

Michael.

Re: C-o

[Jeremy Bryant]

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

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

C-o helps with readability (esp. with code rather than text) if you want
to insert a blank line before typing.

Furthermore the above 2 example are not quite interchangeable as
foo bar RET
moves you to the second line, which you may not always want, compared to
C-o foo bar


C-o open-line, appears to be an example of a pragmatic editing command
which is present in Emacs but not generally in other text editors.  Its
presence could be the result of accumulated wisdom.
Different typists use different commands.

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

Re: C-o

[Howard Melman]

Per Starbäck <per.starback@gmail.com> writes:

> 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 do this too.  I write prose with soft newlines in
visual-line mode, usually in markdown-mode which can have
some performance problems with font-locking in larger
buffers.  If I'm inserting text in the middle of a paragraph
I'll use C-o to make the paragraph smaller first which can
alleviate the performance issue.  I'll then rejoin the
paragraph if I added text or delete the following paragraph
if I've rewritten it and convinced myself the new text is
better. 

I also commonly use C-x C-o (delete-blank-lines) so having
line changing commands on C-o seems consistent to me.

Oddly I never use join-line M-^ instead making use of C-k
and C-d and M-SPC for such work.

-- 

Howard

Re: C-o

[Yuri Khan]

On Wed, 3 Jul 2024 at 22:25, Howard Melman <hmelman@gmail.com> wrote:

> I write prose with soft newlines in
> visual-line mode, usually in markdown-mode which can have
> some performance problems with font-locking in larger
> buffers.  If I'm inserting text in the middle of a paragraph
> I'll use C-o to make the paragraph smaller first which can
> alleviate the performance issue.

Since markdown uses blank lines to separate paragraphs,
you could use hard newlines within paragraphs
and place them at strategic points
such as ends of sentences and phrases.

This would probably solve performance issues you mention
and give you more useful diffs.
Your text insertions would also, with high probability,
start on line boundaries.

This is called “semantic line breaks”[1].
This message is formatted this way.

[1]: https://sembr.org/

Re: C-o

[Howard Melman]

> On Jul 3, 2024, at 12:24 PM, Yuri Khan <yuri.v.khan@gmail.com> wrote:
> 
> Since markdown uses blank lines to separate paragraphs,
> you could use hard newlines within paragraphs
> and place them at strategic points
> such as ends of sentences and phrases.
> 
> This would probably solve performance issues you mention
> and give you more useful diffs.
> Your text insertions would also, with high probability,
> start on line boundaries.

I'm on a mac, using soft linebreaks in emacs means
I can cut & paste to other apps with expected results.

Howard

Re: C-o

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

  > > This would probably solve performance issues you mention
  > > and give you more useful diffs.
  > > Your text insertions would also, with high probability,
  > > start on line boundaries.

  > I'm on a mac, using soft linebreaks in emacs means
  > I can cut & paste to other apps with expected results.

I wonder about two questions:

* What happens when other people edit or look at your code running
Emacs on GNU/Linux?

* What happens when other people edit or look at your code using
other tools, not involving Emacs?

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

Re: C-o

[Howard Melman]

> On Jul 5, 2024, at 12:14 AM, Richard Stallman <rms@gnu.org> wrote:
> 
>>> This would probably solve performance issues you mention
>>> and give you more useful diffs.
>>> Your text insertions would also, with high probability,
>>> start on line boundaries.
> 
>> I'm on a mac, using soft linebreaks in emacs means
>> I can cut & paste to other apps with expected results.
> 
> I wonder about two questions:
> 
> * What happens when other people edit or look at your code running
> Emacs on GNU/Linux?
> 
> * What happens when other people edit or look at your code using
> other tools, not involving Emacs?

In my original message I mentioned I was talking about prose
which I typically edit in emacs in markdown-mode, not code.

My code uses newlines same as on other platforms.

My prose typically has no newlines within a paragraph.
IME, most apps will wrap that the way visual-line-mode will
in emacs.  This message I wrote in macOS Mail.app and
included (hard) newlines.

Howard

Re: C-o

[Bob Rogers]

   From: Howard Melman <hmelman@gmail.com>
   Date: Wed, 03 Jul 2024 08:48:35 -0400

   Per Starbäck <per.starback@gmail.com> writes:

   > 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 do this too . . .

Likewise; Per might as well have been reading my mind, his practices
there and the rationale for them are so close to mine.  Admittedly, my
use of C-o may be a holdover from the days of slow terminals, but
"pushing text in front of me" still feels somewhat claustrophobic even
when I don't have to wait for line wrapping.

   I also commonly use C-x C-o (delete-blank-lines) so having
   line changing commands on C-o seems consistent to me.

   Oddly I never use join-line M-^ instead making use of C-k
   and C-d and M-SPC for such work.

   -- 

   Howard

Curiously, I'm the other way around, using M-^ but not C-x C-o.  I
suppose one can fit only so much Emacs into one's head.

					-- Bob Rogers
					   http://www.rgrjr.com/