Re: C-o

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

[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

[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

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

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

[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

[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

[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

[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

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

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