Re: Suggested experimental test

Re: Suggested experimental test

[Paul W. Rankin via Emacs development discussions.]

> May I suggest the attached, slightly more controversial, experimental test?

Along this same vein, I suggest that we unbind the `e' key from self-insert-command and instead make it insert the string "Emacs " 17 times, e.g.

Before:
the quick brown fox jumped over the lazy dog

After:
thEmacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs quick brown fox jumpEmacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs d ovEmacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs r thEmacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs Emacs lazy dog

This would be a boon for promoting Emacs, and anyone wanting the legacy behaviour can just rebind `e' in their init.

Lets apply this to the master for the lols as an experiment for... one month!

Or maybe we could just not break fundamental editing operations?

Re: Suggested experimental test

[Lars Ingebrigtsen]

"Paul W. Rankin" via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

>> May I suggest the attached, slightly more controversial, experimental test?
>
> Along this same vein, I suggest that we unbind the `e' key from
> self-insert-command and instead make it insert the string "Emacs " 17
> times, e.g.

This isn't helpful.  People should be able to make suggestions on
emacs-devel without being ridiculed, and stuff like this makes
emacs-devel seem like a very hostile environment.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[tomas]

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

On Wed, Mar 24, 2021 at 09:34:44AM +0100, Lars Ingebrigtsen wrote:
> "Paul W. Rankin" via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
> 
> >> May I suggest the attached, slightly more controversial, experimental test?
> >
> > Along this same vein, I suggest that we unbind the `e' key from
> > self-insert-command and instead make it insert the string "Emacs " 17
> > times, e.g.
> 
> This isn't helpful.  People should be able to make suggestions on
> emacs-devel without being ridiculed, and stuff like this makes
> emacs-devel seem like a very hostile environment.

Agreed. There is a lot of ungood karma around in this thread, which
is a pity. I can understand the different POVs, but folks, could you
try to calm a bit down?

I do understand that keybindings /is/ a hot topic. It'll keep coming
back time and again. It's worth being discussed time and again, IMHO,
because it is at some intersection of tech and social: those fields
change, therefore re-discussion is necessary.

It would be far more pleasant [1] if such discussions happened without
us hurting each other :-)

Cheers

[1] and efficient -- but I'm a hedonist ;-P

 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Suggested experimental test

[Paul W. Rankin via Emacs development discussions.]

> On 24 Mar 2021, at 6:51 pm, <tomas@tuxteam.de> <tomas@tuxteam.de> wrote:
> 
> On Wed, Mar 24, 2021 at 09:34:44AM +0100, Lars Ingebrigtsen wrote:
>> 
>> 
>> This isn't helpful.  People should be able to make suggestions on
>> emacs-devel without being ridiculed, and stuff like this makes
>> emacs-devel seem like a very hostile environment.
> 
> Agreed. There is a lot of ungood karma around in this thread, which
> is a pity. I can understand the different POVs, but folks, could you
> try to calm a bit down?
> 
> I do understand that keybindings /is/ a hot topic. It'll keep coming
> back time and again. It's worth being discussed time and again, IMHO,
> because it is at some intersection of tech and social: those fields
> change, therefore re-discussion is necessary.
> 
> It would be far more pleasant [1] if such discussions happened without
> us hurting each other :-)

Guys guys guys, you just gotta read a Modest Proposal such as this with one arched eyebrow... no one wishes to spoil our Utopia.

Re: Suggested experimental test

[tomas]

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

On Wed, Mar 24, 2021 at 07:16:39PM +1000, Paul W. Rankin wrote:

[...]

> Guys guys guys, you just gotta read a Modest Proposal such as this with one arched eyebrow...

I didn't understand that one.

> no one wishes to spoil our Utopia.

Utopia? Where's Utopia? I want to go there ;-)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Suggested experimental test

[Eli Zaretskii]

On March 24, 2021 10:51:14 AM GMT+02:00, tomas@tuxteam.de wrote:
> On Wed, Mar 24, 2021 at 09:34:44AM +0100, Lars Ingebrigtsen wrote:
> > "Paul W. Rankin" via "Emacs development discussions."
> > <emacs-devel@gnu.org> writes:
> > 
> > >> May I suggest the attached, slightly more controversial,
> experimental test?
> > >
> > > Along this same vein, I suggest that we unbind the `e' key from
> > > self-insert-command and instead make it insert the string "Emacs "
> 17
> > > times, e.g.
> > 
> > This isn't helpful.  People should be able to make suggestions on
> > emacs-devel without being ridiculed, and stuff like this makes
> > emacs-devel seem like a very hostile environment.
> 
> Agreed. There is a lot of ungood karma around in this thread, which
> is a pity.

"A lot"?  Aren't we exaggerating a bit?  This thread amassed more than 150 messages; how many of them can be qualified as "ungood karma"?

Re: Suggested experimental test

[tomas]

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

[pruned CC a bit]

On Wed, Mar 24, 2021 at 12:37:59PM +0200, Eli Zaretskii wrote:
> On March 24, 2021 10:51:14 AM GMT+02:00, tomas@tuxteam.de wrote:

[...]

> > Agreed. There is a lot of ungood karma around in this thread, which
> > is a pity.
> 
> "A lot"?  Aren't we exaggerating a bit?  This thread amassed more than 150 messages; how many of them can be qualified as "ungood karma"?

Eli, sometimes you make me confused. I genuinely don't know
if you are ironic here or not. In case you're not: I didn't
mean "a lot" in some quantitative sense; I admit the expression
is somewhat unfortunate.

It's more the intensity of bad feelings on (mostly) both
sides, the "oldtimers" on the one fearing someone's out to
eat their lunch, the "newcomers" on the other, pushing their
new, shiny idea and frustrated that "progress is impossible"
at every (often well-founded!) pushback... well, we see that
time and again.

Now, I think it's OK to have strong feelings about one's
main and favourite tool, but perhaps we could try to develop
some genuine understanding [1] for each other's pain points
and just be a bit... nicer to each other.

Cheers
[1] Just trying to police one's tone doesn't quite work,
   since hurt feelings tend to escape in a very weird
   passive-aggressive way :-/

 - tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Suggested experimental test

[Jean Louis]

We better assume good faith of each participant here.

When there is proposal to change something very fundamental to Emacs
then such proposal should be well reasoned or justified.

As changing anything fundamental in any subject of humans will cause
disagreements even if such change is maybe beneficial for the
group. When a group has made fundamental agreements between
themselves, changing or proposing those agreements requires
explanatory approach.

When there is a borderline proposal, something close to fundamental
agreements it will be either funny or sad.

If proposal is too extreme and proposes changes of things very
fundamental such as key binding for letter `e' to "Emacs" -- then this
may appear funny, and so why not make some jokes there. It tells me
that person perceivs those proposals for key binding changes as funny
and adds up to that fun, but maybe not everybody shares the
sentiments. Neither the proposal neither jokes are not bad faith, I
don't perceive it so.

Viewpoint of experienced older Emacs only users clash with view point
of users of other editors who came to Emacs world and who share
different view points, exchanging view points is good for improvement
of this software and creation of new.

Jean

Re: Suggested experimental test

[tomas]

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

On Wed, Mar 24, 2021 at 02:51:37PM +0300, Jean Louis wrote:
> We better assume good faith of each participant here.

Yes, please :)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

RE: [External] : Re: Suggested experimental test

[Drew Adams]

> If proposal is too extreme and proposes changes of things very
> fundamental such as key binding for letter `e' to "Emacs" -- then this
> may appear funny, and so why not make some jokes there. It tells me
> that person perceivs those proposals for key binding changes as funny
> and adds up to that fun, but maybe not everybody shares the
> sentiments. Neither the proposal neither jokes are not bad faith, I
> don't perceive it so.

+1

> Viewpoint of experienced older Emacs only users clash with view point
> of users of other editors who came to Emacs world and who share
> different view points, exchanging view points is good for improvement
> of this software and creation of new.

+1

Re: Suggested experimental test

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

  > We better assume good faith of each participant here.

Yes, let's all do that.

-- 
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: Suggested experimental test

[Eli Zaretskii]

> Date: Wed, 24 Mar 2021 12:13:17 +0100
> From: tomas@tuxteam.de
> Cc: emacs-devel@gnu.org
> 
> It's more the intensity of bad feelings on (mostly) both
> sides, the "oldtimers" on the one fearing someone's out to
> eat their lunch, the "newcomers" on the other, pushing their
> new, shiny idea and frustrated that "progress is impossible"
> at every (often well-founded!) pushback... well, we see that
> time and again.

I see no problem with intense feelings, as long as they are expressed
in a civilized and polite form.  And AFAICT, they generally are in
this thread.  (The rest of what you wrote above is stuff no one
actually said, it looks like your interpretation of the social
dynamics here.  Which is fine, but it's your interpretation, not
necessarily what really goes on.  And even if it does, I wouldn't
start discussing these aspects, they are only tangentially relevant,
and moreover, we cannot really do anything about them.)

It is true that we sometimes have discussions here that end up in
flames, but this one is not one of them, nowhere near that, actually.
Thus, Lars's comment should have been enough to respond to a remark
that could have bordered on an insult (although I'm quite sure that
was never the intent).  No need to second it, not in this thread.
Exaggeration in these matters is as bad as indifference, IME.

> Now, I think it's OK to have strong feelings about one's
> main and favourite tool, but perhaps we could try to develop
> some genuine understanding [1] for each other's pain points
> and just be a bit... nicer to each other.

We do, but don't expect that to be 110% bulletproof, as even the most
innocent jokes and wording nuances are known to offend someone,
somewhere.  The only way never to risk offense is to keep silent.

Re: Suggested experimental test

[tomas]

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

On Wed, Mar 24, 2021 at 07:04:00PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 24 Mar 2021 12:13:17 +0100
> > From: tomas@tuxteam.de
> > Cc: emacs-devel@gnu.org
> > 
> > It's more the intensity of bad feelings on (mostly) both
> > sides [...]

> I see no problem with intense feelings, as long as they are expressed
> in a civilized and polite form.

We are on one page here, I think.

>                      And AFAICT, they generally are in
> this thread.  (The rest of what you wrote above is stuff no one
> actually said, it looks like your interpretation of the social
> dynamics here.  Which is fine, but it's your interpretation, not
> necessarily what really goes on.  And even if it does, I wouldn't
> start discussing these aspects, they are only tangentially relevant,
> and moreover, we cannot really do anything about them.)

Point taken. You think I went a bit overboard. If that is the case,
I apologise. Should I've hurt somebody's feelings, doubly so.

> Thus, Lars's comment should have been enough to respond to a remark
> that could have bordered on an insult (although I'm quite sure that
> was never the intent).

I'm sure of the latter, too. As for the first... yes, perhaps too
eager on my part.

[...]

> We do, but don't expect that to be 110% bulletproof, as even the most
> innocent jokes and wording nuances are known to offend someone,
> somewhere.  The only way never to risk offense is to keep silent.

Of course. Especially on mailing lists, which cross big physical
and cultural distances while providing little secondary communication
channels.

Thanks for your patience :-)

Cheers
-- tomás

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Suggested experimental test

[Dmitry Gutov]

On 24.03.2021 13:13, tomas@tuxteam.de wrote:
> the "newcomers" on the other, pushing their
> new, shiny idea and frustrated that "progress is impossible"
> at every (often well-founded!) pushback

Except these conversations much too often pit 20-year-old ideas against 
40-year-old special bespoke Emacs ideas. But I guess you could still 
call them shiny.

Re: Suggested experimental test

[tomas]

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

On Wed, Mar 24, 2021 at 07:30:45PM +0200, Dmitry Gutov wrote:
> On 24.03.2021 13:13, tomas@tuxteam.de wrote:
> >the "newcomers" on the other, pushing their
> >new, shiny idea and frustrated that "progress is impossible"
> >at every (often well-founded!) pushback
> 
> Except these conversations much too often pit 20-year-old ideas
> against 40-year-old special bespoke Emacs ideas. But I guess you
> could still call them shiny.

But that was not my point at all. I spotted communication patterns
which I thought concerning and wanted to point that out.

Eli has disagreed. I hold his opinion in high esteem and am going
to shut up now :)

Cheers
 - t

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: Suggested experimental test

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

  > > Agreed. There is a lot of ungood karma around in this thread, which
  > > is a pity.

  > "A lot"?  Aren't we exaggerating a bit?  This thread amassed more than 150 messages; how many of them can be qualified as "ungood karma"?

Instead of disputing who is more wrong, how about if we simply try to
make the discussion kind from now 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: Suggested experimental test

[Paul W. Rankin via Emacs development discussions.]

> On 25 Mar 2021, at 3:14 pm, Richard Stallman <rms@gnu.org> wrote:
> 
> Instead of disputing who is more wrong, how about if we simply try to
> make the discussion kind from now on?

Hmm thought it was clear satire, which I never thought of as kind/unkind... Illustrating how an individual's personal preference when applied universally can easily reach absurdity...

Or the "sane defaults" meme taken to its logical conclusions.

Re: Suggested experimental test

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Thu, 25 Mar 2021 01:14:37 -0400
> Cc: larsi@gnus.org, tomas@tuxteam.de, gregory@heytings.org, pwr@bydasein.com,
>  emacs-devel@gnu.org
> 
>   > "A lot"?  Aren't we exaggerating a bit?  This thread amassed more than 150 messages; how many of them can be qualified as "ungood karma"?
> 
> Instead of disputing who is more wrong, how about if we simply try to
> make the discussion kind from now on?

I generally find abstract calls to behave kindly not effective enough.
First, it is unclear who was unkind, or why some utterance/behavior is
unkind, or how to behave differently to make it less so.  If someone
indeed intended to be unkind, then the answer is clear at least to
that person.  But that is rarely the case; it certainly isn't so in
this last episode.

Therefore, I find that discussing this a bit is indeed beneficial, as
it lets people think more about possible misinterpretations of their
words, and maybe choose better ones next time; and it also tells those
on the receiving end to be more tolerant to what could well be an
innocent joke or even just a misunderstanding, due to language and
cultural nuances.

Suggested experimental test

[Gregory Heytings]

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


>
> This concludes our first experimental test on the devel branch.  The 
> amount of feedback wasn't overwhelming, but we did get some -- and I 
> guess the `M-o' command wasn't very popular, so I'm not really that 
> surprised.
>
> So I think it was a moderately successful experiment, and we should use 
> this way of trying out user interface changes more.
>

May I suggest the attached, slightly more controversial, experimental 
test?

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-diff; name=0001-lisp-loadup.el-Change-the-C-o-open-line-binding-expe.patch, Size: 2185 bytes --]

From 8282fa547f79230a112da9e4e49c4149d4c31f7f Mon Sep 17 00:00:00 2001
From: Gregory Heytings <gregory@heytings.org>
Date: Fri, 19 Mar 2021 18:51:49 +0000
Subject: [PATCH] * lisp/loadup.el: Change the 'C-o' ('open-line') binding
 experimentally

---
 lisp/loadup.el | 34 ++++++++++++++++++++++++++++++++++
 1 file changed, 34 insertions(+)

diff --git a/lisp/loadup.el b/lisp/loadup.el
index 4a0b8f508c..02808365f0 100644
--- a/lisp/loadup.el
+++ b/lisp/loadup.el
@@ -477,6 +477,40 @@
 
 \f
 
+(define-key global-map "\C-o" #'free-ctl-o)
+
+(defun free-ctl-o ()
+  (interactive)
+  (setq prefix-arg current-prefix-arg)
+  (message "Repeat C-o to insert newlines after point, or type C-h or ? for help")
+  (let ((map (make-sparse-keymap)))
+    (define-key map (kbd "C-o") #'open-line)
+    (define-key map (kbd "C-h") #'free-ctl-o-explain)
+    (define-key map (kbd "?") #'free-ctl-o-explain)
+    (set-transient-map map t)))
+
+(defun free-ctl-o-explain ()
+  (interactive)
+  (switch-to-buffer "*Change to C-o*")
+  (let ((inhibit-read-only t))
+    (erase-buffer)
+    (insert "[Type `q' to exit this buffer.]\n\n"
+            "We've disabled the normal `C-o' binding for a month (until April\n"
+            "23th, 2021) in the development version of GNU Emacs, while keeping\n"
+            "the `open-line' command that was bound to `C-o' on repeated `C-o'.\n\n"
+            "If this change doesn't annoy too many people, the plan is to leave\n"
+            "the `C-o' key unbound, except when it is repeated, for usage by\n"
+            "third-party packages.\n\n"
+            "If you wish to restore the `C-o' binding, you can put the following\n"
+            "in your .emacs or .emacs.d/init.el file:\n\n"
+            "(global-set-key (kbd \"C-o\") #'open-line)\n\n"
+            "If you wish to protest this change, please send you thoughts to the\n"
+            "emacs-devel@gnu.org mailing list.\n"))
+  (goto-char (point-min))
+  (special-mode))
+
+\f
+
 (if dump-mode
     (let ((output (cond ((equal dump-mode "pdump") "emacs.pdmp")
                         ((equal dump-mode "dump") "emacs")
-- 
2.30.1

Re: Suggested experimental test

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> May I suggest the attached, slightly more controversial, experimental
> test?

Removing `C-o' has already been suggested, and there's already been a
lot of negative feedback on that, if I remember correctly.  So I don't
think there's much point in doing this experiment.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[Alfred M. Szmidt]

   > May I suggest the attached, slightly more controversial, experimental
   > test?

   Removing `C-o' has already been suggested, and there's already been a
   lot of negative feedback on that, if I remember correctly.  So I don't
   think there's much point in doing this experiment.

I think there was less negative feedback about C-o than about removing
M-o M-s and friends.  Yet that was removed, and not even moved to
another binding -- indeed, rather calls for keeping at least some
where promptly ignored.

Why not just remove all keybindings?  

Re: Suggested experimental test

[Gregory Heytings]

>
> I think there was less negative feedback about C-o than about removing 
> M-o M-s and friends.  Yet that was removed, and not even moved to 
> another binding -- indeed, rather calls for keeping at least some where 
> promptly ignored.
>

Don't worry, they are not ignored, but it is not possible to do everything 
in one go.

Re: Suggested experimental test

[Alfred M. Szmidt]

   > I think there was less negative feedback about C-o than about removing 
   > M-o M-s and friends.  Yet that was removed, and not even moved to 
   > another binding -- indeed, rather calls for keeping at least some where 
   > promptly ignored.

   Don't worry, they are not ignored, but it is not possible to do everything 
   in one go.

So is the plan to readd keybindings center-FOO?  What about C-o --
that seems to be hitting the trash can, for whatever reason.  Some of
these bindings (C-o for example) have existed for 40 years in Emacs
(M-o M-s was once upon a time on M-s).

There was alot of thought put into it back then, and the intent was to
make it easy to write code and text.  That was the main intent of
Emacs, and main design decisions in the bindings.  These "freeing up
keybindings" initiatives make it harder for people to use Emacs, not
easier.

Re: Suggested experimental test

[Gregory Heytings]

>
> So is the plan to readd keybindings center-FOO?
>

There is no clear predefined plan, just some ideas I'm currently 
experimenting with.

>
> What about C-o -- that seems to be hitting the trash can, for whatever 
> reason.  Some of these bindings (C-o for example) have existed for 40 
> years in Emacs (M-o M-s was once upon a time on M-s).
>
> There was alot of thought put into it back then, and the intent was to 
> make it easy to write code and text.  That was the main intent of Emacs, 
> and main design decisions in the bindings.  These "freeing up 
> keybindings" initiatives make it harder for people to use Emacs, not 
> easier.
>

C-o is not at all "hitting the trash can", at the moment there is nothing 
more than a proposal to conduct an experiment to make a (small?) change to 
its meaning.

Even among the C-LETTER and M-LETTER keys, there are quite a few whose 
meaning have changed during the last 40 years.  I know at least of: C-h, 
C-l, M-g, M-j, M-n, M-o, M-p, M-r and M-s.  That's 9 keys out of 52.

C-o was described as follows in the 1985 Emacs manual: "When you want to 
insert a new line of text before an existing line, you can do it by typing 
the new line of text, followed by RET.  However, it may be easier to see 
what you are doing if you first make a blank line and then insert the 
desired text into it.  This is easy to do using the key C-o, which inserts 
a newline after point but leaves point in front of the newline.  After 
C-o, type the text for the new line. C-o F O O has the same effect as F O 
O RET, except for the final location of point."  It seems clear that C-o 
was thought as a convenience command, not as an essential editing command.

C-o is, by the way, not even mentioned in the tutorial.

Emacs evolves very conservatively, and if at some point it becomes clear 
that some key binding is not useful for 99.9% of its users, there is no 
reason to keep it as is just because 40 years ago, under very different 
circumstances, it was considered convenient or useful.  I'd say that Emacs 
is a bit like the C programming language, which evolves as conservatively 
as (or perhaps even more conservatively than) Emacs.  Just because a 
function was considered useful and was included in the standard library 30 
years ago does not mean that it should forever remain in the standard 
library.

Re: Suggested experimental test

[Alfred M. Szmidt]

   > What about C-o -- that seems to be hitting the trash can, for whatever 
   > reason.  Some of these bindings (C-o for example) have existed for 40 
   > years in Emacs (M-o M-s was once upon a time on M-s).
   >
   > There was alot of thought put into it back then, and the intent was to 
   > make it easy to write code and text.  That was the main intent of Emacs, 
   > and main design decisions in the bindings.  These "freeing up 
   > keybindings" initiatives make it harder for people to use Emacs, not 
   > easier.

   C-o is not at all "hitting the trash can", at the moment there is nothing 
   more than a proposal to conduct an experiment to make a (small?) change to 
   its meaning.

It isn't a small change to remove a feature completely.  When asked to
keep _a_ binding, it has been meet with silence and it has been more
important to inconvinence users than to listen to them, so I can only
assume that this will a similar case for C-o.  The overal tone of the
discussion of removing keybindings has been to remove them without
considering users, and that it is more important to free them up at
all costs.

   C-o is, by the way, not even mentioned in the tutorial.

Not everything is mentioned in the tutorial, nor can it.

   Emacs evolves very conservatively, and if at some point it becomes clear 
   that some key binding is not useful for 99.9% of its users, there is no 
   reason to keep it as is just because 40 years ago, under very different 
   circumstances, it was considered convenient or useful.

emacs-devel is not even 1% of people using Emacs, and the more I see
these statements the more I am inclined to think that people on this
list don't use Emacs.  When it has been suggested to actually do a
poll, it is far to cumbersome, and instead complicated schemes are
devised.

Re: Suggested experimental test

[Gregory Heytings]

>
> It isn't a small change to remove a feature completely.  When asked to 
> keep _a_ binding, it has been meet with silence and it has been more 
> important to inconvinence users than to listen to them, so I can only 
> assume that this will a similar case for C-o.
>

Your assumption is wrong.  Please have a look at the proposed experiment: 
it moves open-line to repeated C-o.

Re: Suggested experimental test

[Alfred M. Szmidt]

   > It isn't a small change to remove a feature completely.  When asked to 
   > keep _a_ binding, it has been meet with silence and it has been more 
   > important to inconvinence users than to listen to them, so I can only 
   > assume that this will a similar case for C-o.

   Your assumption is wrong.  

Neither center-line nor center-paragraph have been given an
alternative binding.  The same is also applicable for facemenu.
Despite requests for it.
 
   Please have a look at the proposed experiment: it moves open-line
   to repeated C-o.

A proposal is not reality, and such a behaviour would be yet again
beyond annoying.  How about doing polls first instead of doing this
blind experiments where it will be far to late when these changes
sneak into Emacs for them to be changed back.

Re: Suggested experimental test

[Gregory Heytings]

>>> It isn't a small change to remove a feature completely.  When asked to 
>>> keep _a_ binding, it has been meet with silence and it has been more 
>>> important to inconvinence users than to listen to them, so I can only 
>>> assume that this will a similar case for C-o.
>>
>> Your assumption is wrong.
>
> Neither center-line nor center-paragraph have been given an alternative 
> binding.  The same is also applicable for facemenu. Despite requests for 
> it.
>

This is another topic, unrelated to the current one, and as I said earlier 
I'm currently experimenting ways to readd these commands.  I do this 
thinking specifically of you.

>> Please have a look at the proposed experiment: it moves open-line to 
>> repeated C-o.
>
> A proposal is not reality, and such a behaviour would be yet again 
> beyond annoying.  How about doing polls first instead of doing this 
> blind experiments
>

What kind of poll would you like to see?  What would you consider to be a 
significant enough fraction of Emacs users?  How would you poll them? 
There has been a survey a few months ago, and in spite of the fact that 
there were more than 7000 replies, many complained that the results were 
not representative.

Moreover, polling with abstract questions is not a good way to discuss UI 
changes.  The point of conducting experiments on the trunk is that users 
concretely experiment potential changes.

>
> where it will be far to late when these changes sneak into Emacs for 
> them to be changed back.
>

Fortunately, such changes are easy to revert for users who would dislike 
them, and the way to revert them is documented in the NEWS file.

As I said, there have been many changes even to the C-LETTER and M-LETTER 
keys in the past, when it was thought that the key in question could be 
used in a better way.  Another example, which I forgot in my previous 
list, is C-c, which was changed from exit-recursive-edit to a prefix key 
in Emacs 16, and exit-recursive-edit was moved to C-M-c.

Re: Suggested experimental test

[Alfred M. Szmidt]

   > Neither center-line nor center-paragraph have been given an alternative 
   > binding.  The same is also applicable for facemenu. Despite requests for 
   > it.

   This is another topic, unrelated to the current one, and as I said earlier 
   I'm currently experimenting ways to readd these commands.  I do this 
   thinking specifically of you.

Thanks, I'm flattered, but I'd hope you rather consider those who do
not read this list first than grumpy Emacs users.

   >> Please have a look at the proposed experiment: it moves open-line to 
   >> repeated C-o.
   >
   > A proposal is not reality, and such a behaviour would be yet again 
   > beyond annoying.  How about doing polls first instead of doing this 
   > blind experiments

   What kind of poll would you like to see?  What would you consider to be a 
   significant enough fraction of Emacs users?  How would you poll them? 
   There has been a survey a few months ago, and in spite of the fact that 
   there were more than 7000 replies, many complained that the results were 
   not representative.

The best polling suggestion I've seen so far has been from rms, and
those have had good track records over the years.

   Moreover, polling with abstract questions is not a good way to discuss UI 
   changes.  The point of conducting experiments on the trunk is that users 
   concretely experiment potential changes.

I think you can make these questions less abstract, even to the point
of a yes / no question.  "Do you use M-o (frobnicate-line)? Yes/No.".
Sending out a questionare for each release would be unrealistic, so
one could accumulate a set of proposal in release 20, send it out
during release 21, and delibrate and implement for 22.

One could also add some extra details, like if the change is for
something in a very recent version such a long cycle isn't required,
but if it is has existed since Emacs 18 it is.

   > where it will be far to late when these changes sneak into Emacs for 
   > them to be changed back.

   Fortunately, such changes are easy to revert for users who would dislike 
   them, and the way to revert them is documented in the NEWS file.

From my experience, it isn't the case.  The usual argument is that "we
just changed it, lets keep it for a bit more" -- and then it becomes
permanent.

   As I said, there have been many changes even to the C-LETTER and M-LETTER 
   keys in the past, when it was thought that the key in question could be 
   used in a better way.  Another example, which I forgot in my previous 
   list, is C-c, which was changed from exit-recursive-edit to a prefix key 
   in Emacs 16, and exit-recursive-edit was moved to C-M-c.

Elided much of that since if I didn't, my reply would become a rather
longer rant.  Changing the semantics slightly is I think less annoying
than completle removing a keybinding.

The bare minimum I think is that if removing a long standing
keybinding, it should at least get a new one.  Make it a three stage
rocket, M-s got punted to M-o M-s .. this could get punted to H-x M-o
M-s (or something slighly more paltable) ... and then removed.  With
actual polls inbetween to get a feel of what people outside this list
prefer, but also a heavier handed touch of deciding on an actual
policy of how exactly bindings should be mapped.

The way Emacs did it is that C- is smaller than M- which is smaller
than C-M-.  Right now, there is no such decision process, and its
quite random.  As an example if I do not recall incorrectly, C-o used
to insert new line, M-o would also adjust for indentation, and C-M-o
would keep the same indentation as the current line.

It is these small things that make Emacs make sense for new users.

Re: Suggested experimental test

[Gregory Heytings]

>>> Neither center-line nor center-paragraph have been given an 
>>> alternative binding.  The same is also applicable for facemenu. 
>>> Despite requests for it.
>>
>> This is another topic, unrelated to the current one, and as I said 
>> earlier I'm currently experimenting ways to readd these commands.  I do 
>> this thinking specifically of you.
>
> Thanks, I'm flattered, but I'd hope you rather consider those who do not 
> read this list first than grumpy Emacs users.
>

I do consider them, too.  But I think that "grumpy Emacs users" who 
express themselves also speak for (at least some of) those who do not read 
this list.

>> Moreover, polling with abstract questions is not a good way to discuss 
>> UI changes.  The point of conducting experiments on the trunk is that 
>> users concretely experiment potential changes.
>
> I think you can make these questions less abstract, even to the point of 
> a yes / no question.  "Do you use M-o (frobnicate-line)? Yes/No.". 
> Sending out a questionare for each release would be unrealistic,
>

That doesn't answer the main question: how do you concretely poll these 
users? and what would you consider to be a significant enough fraction of 
Emacs users for the poll to be representative?  Would 500 answers be 
enough? 1000? 5000? 10000?

What would you do with the result of such a poll?  What if only 50 or 100 
in those 10000 answer "yes"?  Should the feature be kept for those 50 or 
100?

Moreover the result of a yes/no poll like "Do you use M-o 
(frobnicate-line)?" is not very useful:

"No, I don't use it, because I did not know it exists"
"No, I don't use it, I know it exists and I'm sure I'll never use it"
"No, I don't use it at the moment, but I may use it in the future"
"Yes, I do use it, but I use viper-mode/evil-mode, so it's not bound to M-o"
"Yes, I do use it, but I bind it to another key in my init file and use M-o for something else"
"Yes, I do use it, but not frequently, so I wouldn't mind if it were moved to another key"
"Yes, I do use it, but not frequently, and I wouldn't mind if I had to use M-x frobnicate-line instead"
"Yes, I do use it frequently, but I wouldn't mind if it were moved to another key"
"Yes, I do use it frequently, and would prefer that it remains on the same key"
"Yes, I do use it frequently, and would rebind it to the current key in my init file if its binding changed"
...

are all valid answers with very different consequences, that cannot be 
seen in a yes/no poll.

>
> so one could accumulate a set of proposal in release 20, send it out 
> during release 21, and delibrate and implement for 22.
>

That would be unrealistic, it would mean a four to six years waiting 
period before an UI change can be implemented, long enough to discourage 
anyone in advance to even envision the possibility of proposing such a 
change.

>> Fortunately, such changes are easy to revert for users who would 
>> dislike them, and the way to revert them is documented in the NEWS 
>> file.
>
> From my experience, it isn't the case.
>

Of course it is, for example the way to revert the M-o change is 
documented in the NEWS file, both for those who would like to only revert 
facemenu, and for those who would like to only revert the two center-foo 
commands.

>> Another example, which I forgot in my previous list, is C-c, which was 
>> changed from exit-recursive-edit to a prefix key in Emacs 16, and 
>> exit-recursive-edit was moved to C-M-c.
>
> Changing the semantics slightly is I think less annoying than completle 
> removing a keybinding.
>

Changing "C-c" from exit-recursive-edit to a prefix key was not changing 
its semantics slightly, and the proposed experiment in this thread is not 
about completely removing a key binding, it is about changing its 
semantics slightly.

Re: Suggested experimental test

[Alfred M. Szmidt]

   That doesn't answer the main question: how do you concretely poll these 
   users? and what would you consider to be a significant enough fraction of 
   Emacs users for the poll to be representative?  Would 500 answers be 
   enough? 1000? 5000? 10000?

I don't have the link at hand, but RMS had posted how to do exactly
this time of poll.  I can try to locate it for you if you want.

   What would you do with the result of such a poll?  What if only 50 or 100 
   in those 10000 answer "yes"?  Should the feature be kept for those 50 or 
   100?

The idea behind a poll is to gather some data and get an idea of the
overal situation.  emacs-devel isn't a very good place for such
information.

   Moreover the result of a yes/no poll like "Do you use M-o 
   (frobnicate-line)?" is not very useful:

What is the issue understanding those answers? They give some insight
as to what users might prefer and what they do.

   > so one could accumulate a set of proposal in release 20, send it out 
   > during release 21, and delibrate and implement for 22.

   That would be unrealistic, it would mean a four to six years waiting 
   period before an UI change can be implemented, long enough to discourage 
   anyone in advance to even envision the possibility of proposing such a 
   change.

Would that be a bad thing? Why is there such a hurry to change
_existing_ behaviour, or specifically _removing_ existing behaviour?
We aren't talking about every single UI change.  Emacs is stable, and
significant changes in the UI should take time (I consider C-o to be
more significant than M-o -- which at least when it got modified the
key got a different useful meaning).

   >> Fortunately, such changes are easy to revert for users who would
   >> dislike them, and the way to revert them is documented in the
   >> NEWS file.
   >
   > From my experience, it isn't the case.

   Of course it is, for example the way to revert the M-o change is
   documented in the NEWS file, both for those who would like to only
   revert facemenu, and for those who would like to only revert the
   two center-foo commands.

We are misscommunicating, I am talking about restoring the previous
behaviour in Emacs, not on a per user basis.  

The point here is that the suggestions have been removing
featues, without replacing them. exit-recursive-edit got moved to a
different binding, and the semantics of C-c got changed to something
useful.

Re: Suggested experimental test

[Gregory Heytings]

>
> I don't have the link at hand, but RMS had posted how to do exactly this 
> time of poll.  I can try to locate it for you if you want.
>

I would indeed be interested in seeing it.

>
> The point here is that the suggestions have been removing featues, 
> without replacing them. exit-recursive-edit got moved to a different 
> binding, and the semantics of C-c got changed to something useful.
>

Once again, the point of the suggested experiment is _not_ to remove a 
feature.  open-line would be moved to a different binding, and the 
semantics of C-o would be changed to something useful.

(Obviously, I'm not proposing this just to leave the that key unused.)

RE: [External] : Re: Suggested experimental test

[Drew Adams]

> Obviously, I'm not proposing this just to leave the that key unused.

Oh, but I wish that _were_ the proposal...  Unused AND
with an intention not to bind it by default at all.

If we can remove preloading of facemenu or whatever
then why can't we remove this or that default binding?

Post the change in NEWS, with the code to reenable
it for anyone who needs it: (global-set-key ...).

I'm in favor of freeing up `C-o' for preferential
use by 3rd-party code (e.g. as a prefix key or a
repeating command or ...).

I sympathize with anyone who has a longstanding habit
of using some key that's been bound by default.  But
nothing is easier for a user than binding such a key.

Voila.  You asked for opinions.  Apologies to all
who objected to the proposed change for other/opposite
reasons.

My objection is not to removal of the existing binding;
it's to binding `C-o' in some other default way.

Just unbind it and declare Emacs's intention, at least
for the foreseeable future, to not bind it by default.
Give it up to 3rd-party code, unless/until Emacs really
gets a screaming/important need to bind it by default.

Re: [External] : Re: Suggested experimental test

[Alfred M. Szmidt]

   > Obviously, I'm not proposing this just to leave the that key
   > unused.

   Oh, but I wish that _were_ the proposal...  Unused AND
   with an intention not to bind it by default at all.

Seeing that to get sensible behaviour in Emacs is to re-bind it, why
can't you do the same and ignore whatever it is bound too?

RE: [External] : Re: Suggested experimental test

[Drew Adams]

>    > Obviously, I'm not proposing this just to leave the that key
>    > unused.
> 
>    Oh, but I wish that _were_ the proposal...  Unused AND
>    with an intention not to bind it by default at all.
> 
> Seeing that to get sensible behaviour in Emacs is to re-bind it, why
> can't you do the same and ignore whatever it is bound too?

As a user, of course I can.  I'm talking about 3rd-party
code.

And sure, 3rd-party code can likewise trample on Emacs
default bindings.  But that's asking for trouble.

I don't think we want to _encourage_ that.  But by
binding more and more keys by default, Emacs dev does
indeed risk encouraging just that - a wild free-for-all.

Re: [External] : Re: Suggested experimental test

[Alfred M. Szmidt]

   And sure, 3rd-party code can likewise trample on Emacs
   default bindings.  But that's asking for trouble.

And removing features from users isn't? :-)

   I don't think we want to _encourage_ that.  But by
   binding more and more keys by default, Emacs dev does
   indeed risk encouraging just that - a wild free-for-all.

There is plenty of keybindings available for third-party modes.  Emacs
could also just state a policy that 3rd party stuff can some
keybindings like C-o / M-o for other purposes, with a caveat emperor
instead of removing those features.

Re: Suggested experimental test

[Gregory Heytings]

>> May I suggest the attached, slightly more controversial, experimental 
>> test?
>
> Removing `C-o' has already been suggested, and there's already been a 
> lot of negative feedback on that, if I remember correctly.  So I don't 
> think there's much point in doing this experiment.
>

Well... the suggested experiment does not remove C-o, it changes C-o in a 
way that is, I believe, painless.  We cannot know whether it is indeed 
painless without experimenting at a larger scale.  The few who objected 
against changing C-o may well find out, after trying it out, that this 
small change is not as bad as they thought.

As far as I remember, there has not been a lot of negative feedback on 
changing C-o, the negative feedback was (to my surprise) mostly about the 
possibility of changing the behavior of C-z.

Re: Suggested experimental test

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> Well... the suggested experiment does not remove C-o, it changes C-o
> in a way that is, I believe, painless. 

Sorry; I didn't read the patch carefully.  So it basically moves `C-o'
to `C-o C-o' (and makes the `C-o' prefix open for new commands)?

I don't use `C-o' myself, so I can't really say to what degree this
would be annoying or not for users.  Any `C-o' users who have an opinion
here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 22 Mar 2021 13:06:09 +0100
> Cc: emacs-devel@gnu.org
> 
> I don't use `C-o' myself, so I can't really say to what degree this
> would be annoying or not for users.  Any `C-o' users who have an opinion
> here?

I use it _a_lot_.

Re: Suggested experimental test

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I don't use `C-o' myself, so I can't really say to what degree this
>> would be annoying or not for users.  Any `C-o' users who have an opinion
>> here?
>
> I use it _a_lot_.

`M-o M-o' seemed to be a command that many people were unaware of, but
when they learned of what it was used for, they recognised the utility
of such a command.  (I was certainly one of them.)

I've tried using `C-o' here and there, but it never seems to do what I
want, so I wonder what the practical use case for this command is.  I'm
probably missing something.

That is, I expected the command to go from this:

(defun eww-detect-charset (html-p)
  (let ((case-fold-search| t)

to this:

(defun eww-detect-charset (html-p)
  (let ((case-fold-search|
         t)

Instead it gives me this:

(defun eww-detect-charset (html-p)
  (let ((case-fold-search|
 t)

The | character gives the point position.

In text-like modes it seems less awkward, since I just `M-q' afterwards
anyway.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: gregory@heytings.org,  emacs-devel@gnu.org
> Date: Mon, 22 Mar 2021 19:17:25 +0100
> 
> That is, I expected the command to go from this:
> 
> (defun eww-detect-charset (html-p)
>   (let ((case-fold-search| t)
> 
> to this:
> 
> (defun eww-detect-charset (html-p)
>   (let ((case-fold-search|
>          t)
> 
> Instead it gives me this:
> 
> (defun eww-detect-charset (html-p)
>   (let ((case-fold-search|
>  t)

This command isn't supposed to reindent the next line, it just inserts
a newline.  My main use for it is to move line(s) downward when point
is in column zero.  The 'o' in C-o stands for "open" a line.

Re: Suggested experimental test

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> This command isn't supposed to reindent the next line, it just inserts
> a newline.  My main use for it is to move line(s) downward when point
> is in column zero.  The 'o' in C-o stands for "open" a line.

I see.  Yes, that seems useful.

Gregory, I don't think there's much point in doing this experiment --
the pushback is already substantial, so I think we have the data we need
already.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Gregory, I don't think there's much point in doing this experiment --
> the pushback is already substantial, so I think we have the data we need
> already.

The tenor of discussion in this thread has been shocking, though, with
people ascribing nefarious motivations to Gregory's suggestion.  Please
stop doing this -- it makes this mailing list distinctly unfriendly.

People should be free to make suggestions without being sniped at.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[Stefan Kangas]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Gregory, I don't think there's much point in doing this experiment --
>> the pushback is already substantial, so I think we have the data we need
>> already.
>
> The tenor of discussion in this thread has been shocking, though, with
> people ascribing nefarious motivations to Gregory's suggestion.  Please
> stop doing this -- it makes this mailing list distinctly unfriendly.
>
> People should be free to make suggestions without being sniped at.

+1

FWIW, I don't particularly see the need for freeing up a key for
third-party packages.

But if we're going to do that, `C-o' seems like a bad choice.  If it is
to be worth changing this keybinding to anything, it should be to
`find-file'.  That is, after all, what all other software assigns this
key to.

RE: [External] : Re: Suggested experimental test

[Drew Adams]

> If it is to be worth changing this keybinding [`C-o']
> to anything, it should be to `find-file'.  That is,
> after all, what all other software assigns this key to.

Wow.  Just wow.

After all.  What's next?

RE: [External] : Re: Suggested experimental test

[Stefan Kangas]

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

> After all.  What's next?

Do you mean besides rebinding `C-p' to `print-buffer' in Emacs 28.1?

RE: [EXTERNAL] Re: Suggested experimental test

[Stephan Mueller]

Since opinions are explicitly being solicited, and since I have not encountered a particular point in my not-necessarily-comprehensive reading of this thread, I'll add one:

I use C-o (usually followed by C-n) many times a day, instead of <Enter>, in order to suppress re-indentation of the current line in cases where that re-indentation will be incorrect for my purposes**.

Needing to hit C-o twice would make the workaround more painful.  I expect I would end up rebinding in my .emacs to restore the current behaviour.

Also, I find myself nodding in agreement to the argument (apologies for not recalling who made it in this thread) that as a long-standing and fairly 'basic' binding, it is in use in other editors that try to be Emacs-like.  Changing the default behaviour here would introduce confusion to the world and confound muscle memory.

stephan();

** Of course, addressing the indentation issue would be good, but that perpetually remains a task for another day -- it's not a configurable behaviour, and will require me to do substantial research into cperl mode to understand more.  That said, even in cases not involving my oddly formatted perl, auto-indentation seems generally accurate enough to keep using, and inaccurate enough to need a workaround multiple times daily.

-----Original Message-----
From: Emacs-devel <emacs-devel-bounces+stephan=sbmueller.net@gnu.org> On Behalf Of Lars Ingebrigtsen
Sent: Monday, March 22, 2021 5:06 AM
To: Gregory Heytings <gregory@heytings.org>
Cc: emacs-devel@gnu.org
Subject: [EXTERNAL] Re: Suggested experimental test

Gregory Heytings <gregory@heytings.org> writes:

> Well... the suggested experiment does not remove C-o, it changes C-o
> in a way that is, I believe, painless. 

Sorry; I didn't read the patch carefully.  So it basically moves `C-o'
to `C-o C-o' (and makes the `C-o' prefix open for new commands)?

I don't use `C-o' myself, so I can't really say to what degree this
would be annoying or not for users.  Any `C-o' users who have an opinion
here?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flars.ingebrigtsen.no%2F&amp;data=04%7C01%7CStephan.Mueller%40microsoft.com%7C6defb25382ae4b50aabc08d8ed2afd3e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637520116190706836%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=dsMofHZVHi9n24IzfOxmFyXFOEVpV9GttwoJ6kXtwWA%3D&amp;reserved=0

Re: Suggested experimental test

[Lars Ingebrigtsen]

Stephan Mueller <Stephan.Mueller@microsoft.com> writes:

> I use C-o (usually followed by C-n) many times a day, instead of
> <Enter>, in order to suppress re-indentation of the current line in
> cases where that re-indentation will be incorrect for my purposes**.

Oh, I see -- it's useful as an alternative to `RET' exactly when
re-indentation does the wrong thing?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Mon, 22 Mar 2021 19:34:34 +0100
> Cc: Gregory Heytings <gregory@heytings.org>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> Stephan Mueller <Stephan.Mueller@microsoft.com> writes:
> 
> > I use C-o (usually followed by C-n) many times a day, instead of
> > <Enter>, in order to suppress re-indentation of the current line in
> > cases where that re-indentation will be incorrect for my purposes**.
> 
> Oh, I see -- it's useful as an alternative to `RET' exactly when
> re-indentation does the wrong thing?

Yes, but not only that -- it doesn't move point to the next line,
unlike RET.

Re: Suggested experimental test

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> > I use C-o (usually followed by C-n) many times a day, instead of
>> > <Enter>, in order to suppress re-indentation of the current line in
>> > cases where that re-indentation will be incorrect for my purposes**.
>> 
>> Oh, I see -- it's useful as an alternative to `RET' exactly when
>> re-indentation does the wrong thing?
>
> Yes, but not only that -- it doesn't move point to the next line,
> unlike RET.

Right, but in the use case described, the `C-o' is followed by `C-n', so
it's just to suppress faulty re-indentation, apparently.

And I think that's a valid use case -- Emacs does get these things wrong
now and then, and having an escape hatch readily available seems
useful.  Perhaps the doc string of `RET' (i.e., `newline-and-indent' in
most modes) should mention (and link to) to `C-o'?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

Re: Suggested experimental test

[chad]

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

On Mon, Mar 22, 2021 at 12:14 PM Lars Ingebrigtsen <larsi@gnus.org> wrote:

> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > I use C-o (usually followed by C-n) many times a day, instead of
> >> > <Enter>, in order to suppress re-indentation of the current line in
> >> > cases where that re-indentation will be incorrect for my purposes**.
> >>
> >> Oh, I see -- it's useful as an alternative to `RET' exactly when
> >> re-indentation does the wrong thing?
> >
> > Yes, but not only that -- it doesn't move point to the next line,
> > unlike RET.
>
> Right, but in the use case described, the `C-o' is followed by `C-n', so
> it's just to suppress faulty re-indentation, apparently.
>
> And I think that's a valid use case -- Emacs does get these things wrong
> now and then, and having an escape hatch readily available seems
> useful.  Perhaps the doc string of `RET' (i.e., `newline-and-indent' in
> most modes) should mention (and link to) to `C-o'?
>

I'm having a hard time finding a behavior difference between `C-o C-n' and
`C-j' in these contexts. Can someone help me understand the difference?

Thanks in advance,
~Chad

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

Re: Suggested experimental test

[Eli Zaretskii]

> From: chad <yandros@gmail.com>
> Date: Mon, 22 Mar 2021 12:21:23 -0700
> Cc: Eli Zaretskii <eliz@gnu.org>, Gregory Heytings <gregory@heytings.org>, Stephan.Mueller@microsoft.com, 
> 	EMACS development team <emacs-devel@gnu.org>
> 
> I'm having a hard time finding a behavior difference between `C-o C-n' and `C-j' in these contexts. Can
> someone help me understand the difference?

C-j doesn't only insert a newline.  In fact, in some modes it does
something utterly different.  That's a stark contrast to what C-o with
or without C-n does.

Re: Suggested experimental test

[Stefan Monnier]

> C-j doesn't only insert a newline.  In fact, in some modes it does
> something utterly different.

AFAIC this is a bug in those modes.


        Stefan

Re: Suggested experimental test

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: chad <yandros@gmail.com>,  larsi@gnus.org,  emacs-devel@gnu.org,
>   gregory@heytings.org,  Stephan.Mueller@microsoft.com
> Date: Mon, 22 Mar 2021 15:51:32 -0400
> 
> > C-j doesn't only insert a newline.  In fact, in some modes it does
> > something utterly different.
> 
> AFAIC this is a bug in those modes.

??? Including lisp-interaction-mode?

Re: Suggested experimental test

[Stefan Monnier]

>> > C-j doesn't only insert a newline.  In fact, in some modes it does
>> > something utterly different.
>> AFAIC this is a bug in those modes.
> ??? Including lisp-interaction-mode?

lisp-interaction-mode is a weird beast, indeed.


        Stefan "who uses IELM instead"

RE: [External] : Re: Suggested experimental test

[Drew Adams]

> > Including lisp-interaction-mode?
> lisp-interaction-mode is a weird beast, indeed.
>         Stefan "who uses IELM instead"

+1.  Drew, who uses emacs-lisp-mode instead.

Re: Suggested experimental test

[Lars Ingebrigtsen]

chad <yandros@gmail.com> writes:

> I'm having a hard time finding a behavior difference between `C-o C-n'
> and `C-j' in these contexts. Can someone help me understand the
> difference?

That's true, but `C-j' is sometimes more complicated:

---
It is bound to C-j.

(electric-newline-and-maybe-indent)

Insert a newline.
If ‘electric-indent-mode’ is enabled, that’s that, but if it
is *disabled* then additionally indent according to major mode.
---

But, yes, `C-j' is often the command to use when `RET' does too much.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

RE: [External] : Re: Suggested experimental test

[Drew Adams]

> It is bound to C-j.
> (electric-newline-and-maybe-indent)
> 
> Insert a newline.
> If ‘electric-indent-mode’ is enabled, that’s that, but if it
> is *disabled* then additionally indent according to major mode.

I turned that off as soon as `C-j' was co-opted by it.
I prefer the classic Emacs RET and C-j behavior.

Re: [External] : Re: Suggested experimental test

[Stefan Monnier]

> I prefer the classic Emacs RET and C-j behavior.

You mean the one where RET sometimes indents and sometimes doesn't
depending on the preference of the major mode's author?  ;-)


        Stefan

RE: [External] : Re: Suggested experimental test

[Drew Adams]

> > I prefer the classic Emacs RET and C-j behavior.
> 
> You mean the one where RET sometimes indents and sometimes doesn't
> depending on the preference of the major mode's author?  ;-)

I suppose I do.  But the major modes I use
haven't presented a problem for me in that regard.

I use C-j to get a newline + indent behavior, just
as it always did.  And RET to get a newline-only
behavior, just as it always did.

I don't get any weird RET behavior in any modes
I use - RET just inserts a newline.  I do get
mode-specific behavior for C-j.

(Not important; just the reverse.)
___

I do find it interesting that the doc string of
`electric-indent-mode' says nothing about C-j
or RET.  Yet NEWS for Emacs 24.4 put that key
change front and center:

 *** `electric-indent-mode' is now enabled by default.
 Typing RET reindents the current line and indents the
 new line. `C-j' inserts a newline but does not indent.
 In some programming modes, additional characters are
 electric (eg `{').

RE: [EXTERNAL] Re: Suggested experimental test

[Stephan Mueller]

" Lars Ingebrigtsen <larsi@gnus.org> writes:
" Stephan Mueller <Stephan.Mueller@microsoft.com> writes:
" 
" > I use C-o (usually followed by C-n) many times a day, instead of
" > <Enter>, in order to suppress re-indentation of the current line in
" > cases where that re-indentation will be incorrect for my purposes**.
" 
" Oh, I see -- it's useful as an alternative to `RET' exactly when
" re-indentation does the wrong thing?

Yes, exactly and concisely.

stephan();

Re: [EXTERNAL] Re: Suggested experimental test

[Stefan Monnier]

> I use C-o (usually followed by C-n) many times a day, instead of <Enter>, in
> order to suppress re-indentation of the current line in cases where that
> re-indentation will be incorrect for my purposes**.

FWIW, normally you can replace `C-o C-n` with `C-j`.

[ I'm not sure `cperl-mode` is sufficiently normal in this respect, tho
  (one of the reasons why I prefer `perl-mode`).  ]


        Stefan

Re: [EXTERNAL] Re: Suggested experimental test

[Dmitry Gutov]

On 22.03.2021 20:11, Stephan Mueller wrote:
> I use C-o (usually followed by C-n) many times a day, instead of <Enter>, in order to suppress re-indentation of the current line in cases where that re-indentation will be incorrect for my purposes**.

Same.

Probably less frequently, though, now that I

   (global-set-key (kbd "RET") 'newline-and-indent)

in my init script. Though this customization choice bears its own downsides.