Suggested experimental test

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-20 12:04]:
> +            "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

Yes, go ahead and make the test, why not. I like testing, but I also
do not like changing this C-o to anything else than what it is. This
time I will immediately revert it back due to how many times I use C-o
in Emacs. C-o is in other editors because of Emacs standard
keybindings also in many other Emacs related editors. I use zile
editor, and mg editor and e3em editor depeding on what system I am,
console or GUI, and if Emacs is installed or not. In all those editors
I use C-o

Also is one test like M-o now suppposed to endorse many new tests that
are going against standard and well used keybindings.

Imagine just how that impacts people who depend on instructions spread
all over Internet for Emacs standard key bindings.

Rutgers School of Arts and Sciences publishes it:
https://resources.cs.rutgers.edu/docs/emacs-command-summary/

Yale has article "How to use Emacs" in the clas
https://zoo.cs.yale.edu/classes/cs210/help/emacs.html

Stanford:
http://www-tcad.stanford.edu/local/DOC/emacs_21.html

Michigan State University:
https://www.cse.msu.edu/Resources/Facilities/Howto/TextEditing.php

Columbia:
https://cuit.columbia.edu/emacs

Before making proposals out of the blue, I suggest that from a list of
all key bindings then make:

- a list of very basic standard and wide spread key bindings shall be
  made, that most probably should not change, as that is where one has
  to be reluctant. C-f is a sample member of this list, IMHO C-o as
  well.

- with a list of other keys possible for some changes due to their
  improper placement, as we have seen that M-o was improperly placed
  globally instead of only in enriched mode.

- do tests on the latter.

Jean

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Sat, 20 Mar 2021 14:14:42 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org
> 
> - with a list of other keys possible for some changes due to their
>   improper placement, as we have seen that M-o was improperly placed
>   globally instead of only in enriched mode.

M-o is useful in Text mode (and hence many of its derivatives), not
just in Enriched mode.

Re: Suggested experimental test

[Gregory Heytings]

>
> Before making proposals out of the blue, I suggest...
>

Before commenting on a proposed experiment, I suggest to read it (not just 
its two first lines), and possibly to try it.

Proposal to remove C-o binding [was: Suggested experimental test]

[Alan Mackenzie]

Hello, Gregory.

On Sat, Mar 20, 2021 at 09:03:39 +0000, Gregory Heytings wrote:


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

I anticipate there will be quite a lot of resentment about this when we
release Emacs 28.1.

> > So I think it was a moderately successful experiment, and we should use 
> > this way of trying out user interface changes more.

Hmm.

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

I suggest it remains just a suggestion - at least for now.  We won't know
how well or badly the removal of M-o will go until after the release of
Emacs 28.

C-o is a much used binding.  Replacing it with the less convenient C-o
C-o binding is going to annoy people greatly.

Also, we don't really need to free up C-o - we've already got all of M-o
unused.  Where is this all going to stop?

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).

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

[Alfred M. Szmidt]

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

Attached is one way of polling users that was suggested.

===File ~/how-to-poll-users.text============================
Content-Type: text/plain; charset=Utf-8
From: Richard Stallman <rms@gnu.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: luangruo@yahoo.com, seb@k-7.ch, pcr910303@icloud.com, emacs-devel@gnu.org
In-Reply-To: <0ce06d95-0593-bc55-983f-6b6601503a1a@yandex.ru> (message from
 Dmitry Gutov on Tue, 21 Apr 2020 16:55:39 +0300)
Subject: How to poll the users
Reply-To: rms@gnu.org
Date: Tue, 21 Apr 2020 23:14:05 -0400

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

  > Also note that we don't really have the ability to poll even our 
  > existing users,

We have done it many times.  Here's the method I developed for polls
in the past:

* Make a file for the replies to go into.

* Make a mailing address which drops all mail into the file.

* Mail to info-gnu-emacs and help-gnu-emacs, and any other suitable
place, presenting the proposed change in sufficient detail that people
can judge it, and where to email the response, as well as what kind of
information we seek.

What we seek is not "votes", but understanding.  If you are for the
change, please explain why.  Would it help you directly?  If so, in
what scenario, and what would the benefit be?  And how important?

Or is it that you think it will help Emacs development by helping
others?  Please distinguish between what you know and what you guess.

Likewise, if you are against the change, please explain why.  Would it
inconvenience you directly?  If so, in what scenario, and what would
the inconvenience be?  And how important?

Or is it that you think it will harm Emacs development by
inconveniencing others?

We invite you also to propose changes in the proposal that would
improve it, for you -- saying in what scenario, and how.

* We state a deadline some weeks in the future, but since there is no
hurry, we wait some extra time before we look at the responses.

* Ultimately, we do not restrict ourselves to choosing between "make
the change" and "don't make it".  The best outcome is that the
feedback enables us to design a way to please almost everyone.




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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-22 02:47]:
> 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.

You do not need a poll of many users. But you have to make proper
study. Editor and any software and computer usability may be measured
with few people only.

References:
https://www.nngroup.com/articles/why-you-only-need-to-test-with-5-users/
https://www.nngroup.com/videos/usability-testing-w-5-users-design-process/

In my opinion here we talk about usability related to inserting a new
line. The fundamental useful command is inserting a new line or
`open-line'.

What you are here proposing is to replace key binding with something
else like C-o C-o -- but you forget the fundamental usefulness of it.

How about talking about the fundamental feauture of opening a new line
or inserting new empty line and improving that, if at all possible?

How do you do?

How other users do it?

Why would it be more usable for user to press C-o C-o to insert new
line rather than C-o ? That is better discussed rather than purpose of
removing or replacing key bindings for purpose of some other commands
on C-o -- I hope you understand difference between those purposes.

Jean

Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-22 02:06]:
> > 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.

If you have followed my personal usage of C-o from my previous email:

- behavior #1, cursor at beginnin of line, C-o inserts new line, and I
  start typing

- behavior #2, cursor anywhere else on the line, C-a C-o moves to
  beginning of line, opens new line

- behavior #3 is the one explained in 1985 manual, to start typing
  text in the middle of the line while bringin the remainder of text
  down -- this one I do not use

then now please imagine how it would like like with your change:

- behavior #1 above, would require 2 key bindings instead of 1

- behavior #2, above, would require now 3 key bindings instead of 2

- behavior #3 as you explained from 1985 manual, I do not use, almost never

Among all those I would choose the vi like `O' to open new line, but
it does not work within Emacs key binding style.

I am not really fan of moving or customizing any default key bindings,
as for those personal customizations I use either Super key or Hyper
on Caps Lock or C-c LETTER bindings. Reason I am not fan of changing
default key bindings myself is that I wish to have consistent behavior
across multipe operating systems, multiple remote virtual private
servers that run multiple various free operating systems, across
multiple Emacs versions and across multiple Emacs-like editors.

But would I be fan of customizing some default key bindings I would
then replace C-o with C-a C-o like this:

(defun my-C-o ()
  "Opens new line regardless where is cursor positioned."
  (interactive)
  (move-beginning-of-line nil)
  (open-line 1))

(global-set-key (kbd "C-o") #'my-C-o)

But I am not doing that, as I do not like having habit on default key
bindings as that breaks my habits on those other computers where I do
not use any customizations.

Jean

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Sun, 21 Mar 2021 22:16:59 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: emacs-devel@gnu.org
> 
> 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.

Please describe those changes one by one.  At least for some of these
keys I'm unaware of any changes in their bindings, so I'm curious what
exactly is considered a "change" in this context.

Re: Suggested experimental test

[Gregory Heytings]

>> 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.
>
> Please describe those changes one by one.  At least for some of these 
> keys I'm unaware of any changes in their bindings, so I'm curious what 
> exactly is considered a "change" in this context.
>

C-c: was initially exit-recursive-edit, and was changed to a prefix key 
for modes in Emacs 16; exit-recursive-edit was then moved to C-M-c

C-h: was initially (and in other Emacsen) the same as C-b, and was (very 
early in the development of GNU Emacs) changed into the help character

C-l: was 'recenter' up to and including Emacs 22, then became 
'recenter-top-bottom', which changes its semantics when is repeated

C-z: was initially (and in other Emacsen) a prefix character, was at some 
point bound exit-recursive-edit, then became (in GNU Emacs 1.11) bound to 
suspend-emacs

M-g: was initially bound to fill-region, was used for facemenu in Emacs 
19-21, and is used for goto-like commands since Emacs 22

M-j: was initially unused, became indent-new-comment-line in Emacs 1.7

M-n and M-p: were initially unused, became what they are now in Emacs 17

M-o: was unused before Emacs 22, was used for facemenu in Emacs 22-27

M-r: was initially unused, became 'move-to-window-line' in Emacs 16, then 
became 'move-to-window-line-top-bottom', which changed its semantics when 
it is repeated

M-s: was initially unused, became center-line for text-modes in Emacs 16, 
and is used for search-like commands since Emacs 23

Re: Suggested experimental test

[Philip Kaludercic]

Gregory Heytings <gregory@heytings.org> writes:

> M-n and M-p: were initially unused, became what they are now in Emacs 17

M-n and M-p are still unused? Or did the convention 

     A major mode can also rebind the keys ‘M-n’, ‘M-p’ and ‘M-s’.  The
     bindings for ‘M-n’ and ‘M-p’ should normally be some kind of moving
     forward and backward, but this does not necessarily mean cursor
     motion.

     (elisp) Major Mode Conventions

not exist before Emacs 17?

-- 
	Philip K.

Re: Suggested experimental test

[Gregory Heytings]

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


>> M-n and M-p: were initially unused, became what they are now in Emacs 17
>
> M-n and M-p are still unused? Or did the convention
>
>     A major mode can also rebind the keys ‘M-n’, ‘M-p’ and ‘M-s’.  The bindings for ‘M-n’ and ‘M-p’ should normally be some kind of moving forward and backward, but this does not necessarily mean cursor motion.
>
>     (elisp) Major Mode Conventions
>
> not exist before Emacs 17?
>

No, M-n/M-p are of course not unused.  They were unused before Emacs 17 
(except in rmail mode).  The current convention for M-n/M-p started to 
exist with the binding of M-n/M-p in the minibuffer to move to the 
next/previous command in the command history in Emacs 17.  But of course 
at that point it was not formalized as a convention.

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Mon, 22 Mar 2021 10:05:31 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: ams@gnu.org, emacs-devel@gnu.org
> 
> 
> >> 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.
> >
> > Please describe those changes one by one.  At least for some of these 
> > keys I'm unaware of any changes in their bindings, so I'm curious what 
> > exactly is considered a "change" in this context.
> >
> 
> C-c: was initially exit-recursive-edit, and was changed to a prefix key 
> for modes in Emacs 16; exit-recursive-edit was then moved to C-M-c
> 
> C-h: was initially (and in other Emacsen) the same as C-b, and was (very 
> early in the development of GNU Emacs) changed into the help character
> 
> C-l: was 'recenter' up to and including Emacs 22, then became 
> 'recenter-top-bottom', which changes its semantics when is repeated
> 
> C-z: was initially (and in other Emacsen) a prefix character, was at some 
> point bound exit-recursive-edit, then became (in GNU Emacs 1.11) bound to 
> suspend-emacs
> 
> M-g: was initially bound to fill-region, was used for facemenu in Emacs 
> 19-21, and is used for goto-like commands since Emacs 22
> 
> M-j: was initially unused, became indent-new-comment-line in Emacs 1.7
> 
> M-n and M-p: were initially unused, became what they are now in Emacs 17
> 
> M-o: was unused before Emacs 22, was used for facemenu in Emacs 22-27
> 
> M-r: was initially unused, became 'move-to-window-line' in Emacs 16, then 
> became 'move-to-window-line-top-bottom', which changed its semantics when 
> it is repeated
> 
> M-s: was initially unused, became center-line for text-modes in Emacs 16, 
> and is used for search-like commands since Emacs 23

Thanks, this matches my recollection: only 3 keys (M-g, M-o, M-s) were
changed recently enough to count for this discussion.  The rest are
ancient history (more than 35 years ago), and C-l's change is very
much minor (it _adds_ to the previous user-visible behavior, but
doesn't change it).

So my summary would be different: since 35 years ago, only a handful
of these keys were ever changed.

Re: Suggested experimental test

[Gregory Heytings]

>>>> 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.
>>>
>>> Please describe those changes one by one.  At least for some of these 
>>> keys I'm unaware of any changes in their bindings, so I'm curious what 
>>> exactly is considered a "change" in this context.
>>
>> C-c: was initially exit-recursive-edit, and was changed to a prefix key 
>> for modes in Emacs 16; exit-recursive-edit was then moved to C-M-c
>>
>> C-h: was initially (and in other Emacsen) the same as C-b, and was 
>> (very early in the development of GNU Emacs) changed into the help 
>> character
>>
>> C-l: was 'recenter' up to and including Emacs 22, then became 
>> 'recenter-top-bottom', which changes its semantics when is repeated
>>
>> C-z: was initially (and in other Emacsen) a prefix character, was at 
>> some point bound exit-recursive-edit, then became (in GNU Emacs 1.11) 
>> bound to suspend-emacs
>>
>> M-g: was initially bound to fill-region, was used for facemenu in Emacs 
>> 19-21, and is used for goto-like commands since Emacs 22
>>
>> M-j: was initially unused, became indent-new-comment-line in Emacs 1.7
>>
>> M-n and M-p: were initially unused, became what they are now in Emacs 
>> 17
>>
>> M-o: was unused before Emacs 22, was used for facemenu in Emacs 22-27
>>
>> M-r: was initially unused, became 'move-to-window-line' in Emacs 16, 
>> then became 'move-to-window-line-top-bottom', which changed its 
>> semantics when it is repeated
>>
>> M-s: was initially unused, became center-line for text-modes in Emacs 
>> 16, and is used for search-like commands since Emacs 23
>
> Thanks, this matches my recollection: only 3 keys (M-g, M-o, M-s) were 
> changed recently enough to count for this discussion.  The rest are 
> ancient history (more than 35 years ago), and C-l's change is very much 
> minor (it _adds_ to the previous user-visible behavior, but doesn't 
> change it).
>

You forget M-r, changed in Emacs 23.

>
> So my summary would be different: since 35 years ago, only a handful of 
> these keys were ever changed.
>

I was replying to Alfred, who said that nothing had changed during the 
last 40 years.

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Mon, 22 Mar 2021 17:48:44 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: ams@gnu.org, emacs-devel@gnu.org
> 
> You forget M-r, changed in Emacs 23.

Right.  However, that's still a handful.

> > So my summary would be different: since 35 years ago, only a handful of 
> > these keys were ever changed.
> >
> 
> I was replying to Alfred, who said that nothing had changed during the 
> last 40 years.

Yes, but you said "many keys" have been changed.  I don't think that's
accurate, since the number of people here who used Emacs before v18.x
is less than the number of keys whose bindings were changed since then
;-)

Re: Suggested experimental test

[Alfred M. Szmidt]

   > So my summary would be different: since 35 years ago, only a handful of 
   > these keys were ever changed.

   I was replying to Alfred, who said that nothing had changed during the 
   last 40 years.

Eh? I didn't say that at all.

Re: Suggested experimental test

[Alfred M. Szmidt]

   >> 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.
   >
   > Please describe those changes one by one.  At least for some of these 
   > keys I'm unaware of any changes in their bindings, so I'm curious what 
   > exactly is considered a "change" in this context.


So 6 keybinding got added, not changed.  Two/Three got semantics
changed slightly.  And an equal amount got rebound to something else.
I don't think this means that they changed that much meaning over the
last 40 years.

Since you mentioned "other" Emacsen....

   C-c: was initially exit-recursive-edit, and was changed to a prefix key 
   for modes in Emacs 16; exit-recursive-edit was then moved to C-M-c

Zmacs / TECO had this unbound.

   C-h: was initially (and in other Emacsen) the same as C-b, and was (very 
   early in the development of GNU Emacs) changed into the help character

Not in TECO or ZMACS; C-h was unbound (though, the key on the keyboard
said help, but it was initiated using TOP-h or some such).

   C-l: was 'recenter' up to and including Emacs 22, then became 
   'recenter-top-bottom', which changes its semantics when is repeated

Same in Zmacs / TECO, ignoring the minor semantical difference.

   C-z: was initially (and in other Emacsen) a prefix character, was at some 
   point bound exit-recursive-edit, then became (in GNU Emacs 1.11) bound to 
   suspend-emacs

C-z has always meant to punt Emacs to the background since the early
days of Emacs.

   M-g: was initially bound to fill-region, was used for facemenu in Emacs 
   19-21, and is used for goto-like commands since Emacs 22

Which is also what TECO and Zmacs had it too (fill-region)...

   M-j: was initially unused, became indent-new-comment-line in Emacs 1.7

M-j was in Zmacs for changing fonts.

   M-n and M-p: were initially unused, became what they are now in Emacs 17

These where normaly mode specific, but generally speaking comment
down/up line.

   M-o: was unused before Emacs 22, was used for facemenu in Emacs
   22-27

Once upon a time, this was "this indentation", i.e. new line but keep
same column.

   M-r: was initially unused, became 'move-to-window-line' in Emacs
   16, then became 'move-to-window-line-top-bottom', which changed its
   semantics when it is repeated

Zmacs / Teco have this as "move to screen edge".

   M-s: was initially unused, became center-line for text-modes in
   Emacs 16, and is used for search-like commands since Emacs 23

Center line in TECO / Zmacs.

Re: Suggested experimental test

[Rudolf Schlatte]

Gregory Heytings <gregory@heytings.org> writes:

>>
>> So is the plan to readd keybindings center-FOO?
>>
>
> There is no clear predefined plan, just some ideas I'm currently
> experimenting with.

[...]

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

Could you maybe repeat what change is planned?  I looked at the proposed
patch and it seems to only remove the C-o keybinding.  Apologies if the
proposal was posted already; I don't assume the plan is to leave C-o
unbound?

Since I use C-o frequently, I'm curious what will happen when my fingers
press it while editing text, and to what extent I will have to
reconfigure standard Emacs keybindings (which is something I try to
avoid).

Re: Suggested experimental test

[Gregory Heytings]

>> 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.
>
> Could you maybe repeat what change is planned?  I looked at the proposed 
> patch and it seems to only remove the C-o keybinding.
>

No change is planned, at the moment there is nothing more than a proposal 
to conduct an experiment to make a (small?) change to its meaning, namely 
to move the open-line command to repeated C-o.

>
> Since I use C-o frequently, I'm curious what will happen when my fingers 
> press it while editing text, and to what extent I will have to 
> reconfigure standard Emacs keybindings (which is something I try to 
> avoid).
>

This is precisely the purpose of time-limited experiments, during which 
users such as you can see what happens with their fingers, whether they 
can adapt to the new default binding, or whether they have to reconfigure 
something.

Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-22 01:18]:
> 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.

I hope you started keeping notes of number of those who agree and
those who disagree, did you? In my opinion the experiment started by
introducing it. Some disagreer could read in the patch what is going
on, and there is no need for it to be experimented, as the
disagreement is already there due to high usage of C-o personally. But
I can understand that your experiment comes from a different view
point, I can bet you do not use C-o as much as I do, you probably
never use it, am I right?

Me I learned about it long time ago, and I use it in every Emacs-like
editor. Did you hear of zile-on-guile editor? There is also Emacs that
runs on Guile, there is mg, e3em, zile, those are most common that I
use, but I may sometimes use 

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

I do understand the above.

Because cursor is often located at the beginning of the line, C-o
opens up new line and allows me to basically insert new line of
text. The behavior described in this paragraph is somewhat different
than the behavior described in the above paragraph from 1985. It is
inserting a new line in this specific example, do you see? 

Another personal usage of C-o is whe cursor is located somewhere on
the line, but not at beginning of the line, then C-a C-o is what I
mostly use. That is how I insert new line above the current one with
cursor in such position. You can see that this behavior in this
paragraph is definitely not the same as the behavior described in 1985
manual, but also not same as behavior in the previous paragraph.

I could be doing instead C-a RET C-p or C-a RET ARROW-UP -- and I am
kind of thankful for C-a C-o sequence as that is what I use so often.

At this point I would like to know, how do you insert new line? Do you
insert them at all?

124 -- ONE LINE --
345 -- LAST LINE --
       ^
When your cursor is on the letter L in the second line above, what do
you do to insert one line there?

When your cursor is on the number 3 on last line, what do you do to
insert new line?

Both questions are beyond the behavior as described in the 1985 manual
that you assume to be the default and not usable behavior today. This
analysis is also part of your experiment, and I am genuinely
interested how people insert new line above the current line. I use
C-o or C-a C-o combination when cursor is not at beginning of the
line. 

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

If you have a list of number of people agreeing and disagreeing, then
you can make one true mathematical percentage as result. As now you
presented some information and then also your opinion that somehow
relates 99.9% to C-o not being useful, but opinions should not be
biased, as if you do the experiment, count the number of people
agreeing or disagreeing. Also explain how you insert new lines, and if
you insert them at all. Give some reasoning.

In vi and vim editors I use often O to insert new line, it is little
easier than C-o as it works with cursor being anywhere on the
line. The point is, I do insert empty lines all the time, every single
day, every hour.

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

Yes, I do agree on that, but you are relating that statement which is
opinion to experiment, which was supposed to be some observable
countable fact, and experiment would not even involve casual Emacs
users, only those people reading this mailing list. It could not be
really complete without getting feedback from many other users.

How do you insert new lines? 

Jean

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.

Sv: Suggested experimental test

[arthur miller]

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

I don't understand why people are so passionately wasting time
on arguing about shortcuts. As I understand Emacs it is supposed
to be molded after each ones preference. Personally to me I rebind
almost anything to my liking and what makes sense to me.

So go ahead please, do any change you wish to C-o or whatever
other shortcut, including C-z, M-x or C-x if you would like 🙂.
________________________________
Från: Emacs-devel <emacs-devel-bounces+arthur.miller=live.com@gnu.org> för Gregory Heytings <gregory@heytings.org>
Skickat: den 21 mars 2021 11:48
Till: Lars Ingebrigtsen <larsi@gnus.org>
Kopia: emacs-devel@gnu.org <emacs-devel@gnu.org>
Ämne: Re: Suggested experimental test


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


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

Re: Suggested experimental test

[Gregory Heytings]

>
> I don't understand why people are so passionately wasting time on 
> arguing about shortcuts. As I understand Emacs it is supposed to be 
> molded after each ones preference.
>

Of course Emacs can be molded to ones preferences, but the discussion is 
about Emacs' default bindings, about sensible defaults that improve Emacs' 
user experience for newcomers.  This is not a waste of time, at least not 
more than, say, creating new color themes, or improving the help-for-help 
screen.

Re: Sv: Suggested experimental test

[Alfred M. Szmidt]

If I go to the bakery and buy a tiger sponge cake, I don't expect
coming home with an unbaked cake and all the ingredients in a shooping
bag with broken eggs, and then having a baker with the galls telling
me that I'm wasting my time asking for a pre-baked cake cause "this is
better, you can do anything you want".

I just want a tiger sponge cake, and eat it.

Emacs is first and for most a text editor for code and prose, and not
some bag of pre-mixed ingredients that one has to bake first before
using it.

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

  > Emacs is first and for most a text editor for code and prose, and not
  > some bag of pre-mixed ingredients that one has to bake first before
  > using it.

Yes, exactly.  We do not release Emacs as a kit for making editors.
Emacs _is an editor_.


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

[Jean Louis]

* arthur miller <arthur.miller@live.com> [2021-03-21 13:59]:
> I don't understand why people are so passionately wasting time
> on arguing about shortcuts. As I understand Emacs it is supposed
> to be molded after each ones preference. Personally to me I rebind
> almost anything to my liking and what makes sense to me.

To help you understand from my perspective, I am maintaining multiple
remote servers, and have multiple computers, and each time when
working on those computers I do not use any custom key bindings, and I
do some extensive, personally important editing. Some computers use
older Emacs versions, only one is using the development version, some
are on different free operating systems, currently we use 4 different
operating systems. I do expect Emacs to behave by how we used to know
it by habit.

Being passionate is virtue and benefit for Emacs development. I cannot
see it as a waste of time as by following last months or years of
development I can just see great improvements without which I would
not be able to do my work right now. It is easy, after all
discussions, to then say how some of emails were waste of time, but
that falls into the context of saying that it is easy to be general
after the battle. Discussions bring about good things, and they create
new software and incite people to create new software.

Many disagreements may bring some programmers to make new useful
software, we can see that in case of ergonomical key bindings in the
package `ergoemacs-mode' of Xah, we can see that disagreements come up
with new excellent Emacs extensions like Spacemacs or Doom Emacs, that
people like so much.

Emacs may be customizes as one wish, but there are expectations by
Emacs users that can annoy and break the habits. That is price. If the
price is affordable, then changing some key bindings like M-o is quite
alright as for now.

If we however start changing key bindings like it is some kind of a
priority, we will see decline of Emacs users as some may find it
silly. Human editors tend to learn methods and rely on its software.

Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-21 13:52]:
> 
> > > 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.

We learned in sales to take the viewpoint of a customer to understand
customer better. Now imagine people using C-o for decades and now C-o
does not do what it is supposed to do, but then in other editors
related to Emacs it does what is supposed to do. This impacts users
greatly.

I am multi-editor user, so imagine I start using in vi editor
something like `i i' to insert letters, or `O O' to insert new line,
then one Emacs version will be claiming that C-o does this, the other
that C-o C-o does what C-o was doing. Counting with millions of Emacs
users that brings some implications.

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

[Gregory Heytings]

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

Yes and yes.

>
> 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 think we won't really know without experimenting.

Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-22 15:24]:
> 
> > > 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)?
> > 
> 
> Yes and yes.
> 
> > 
> > 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 think we won't really know without experimenting.

Gregory, don't you think that 3 users including me who expressed their
objections is not part of the experiment already?

Re: Suggested experimental test

[Jean Louis]

* Lars Ingebrigtsen <larsi@gnus.org> [2021-03-22 15:07]:
> 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?

For now I count 3 people from mailing lists who already objected to
it, including me.

How do you Lars insert new lines, before the current line with cursor?

Jean

Re: Suggested experimental test

[Gregory Heytings]

>>> 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?
>
> For now I count 3 people from mailing lists who already objected to it, 
> including me.
>

I've only seen one (you), and perhaps a second one (Alfred), but I'm not 
quite sure because he initially thought that open-line would be removed.

>
> How do you Lars insert new lines, before the current line with cursor?
>

I can't speak for Lars, but if this is something that I frequently needed, 
I would either learn the C-p C-e C-m sequence, or make it a command in my 
init file, for example:

(global-set-key (kbd "M-RET") (lambda () (interactive) (previous-line) (end-of-line) (newline-and-indent)))

(M-RET has a similar purpose in org-mode.)

>
> Gregory, don't you think that 3 users including me who expressed their 
> objections is not part of the experiment already?
>

No, precisely because nobody actually experimented the potential change. 
You cannot give an opinion on a change before experimenting it for some 
time, say, at least a day.

Re: Suggested experimental test

[Alan Mackenzie]

Hello, Gregory.

On Mon, Mar 22, 2021 at 17:08:32 +0000, Gregory Heytings wrote:

[ .... ]

> > For now I count 3 people from mailing lists who already objected to it, 
> > including me.

> I've only seen one (you), and perhaps a second one (Alfred), but I'm not 
> quite sure because he initially thought that open-line would be removed.

You ignored my objections on Saturday.  That makes at least 3 people
who've objected.  That's not counting the people who have merely
"commented" rather than objected whole-heartedly.

[ .... ]

> > Gregory, don't you think that 3 users including me who expressed their 
> > objections is not part of the experiment already?

> No, precisely because nobody actually experimented the potential change. 

There's no need for any "experiment".  It's perfectly obvious what you're
proposing and the effect it will have.

And describing it as an "experiment", as though your intention is purely
to discover something about Emacs use, is more than a little disingenuous.

There remains the possibility that you intend to push through this
removal of the C-o binding, and describing it as "an experiment" should
soften the resistance to it.  Of course, it is very easy to forget to
restore the binding once the "experiment" is over.

C-o is a much used binding, valued by lots of people, including me.

> You cannot give an opinion on a change before experimenting it for some 
> time, say, at least a day.

Anybody who wishes to experiment with this thing is perfectly able to
make the temporary adjustments to his own key maps without annoying other
users of the master branch.

-- 
Alan Mackenzie (Nuremberg, Germany).

Re: Suggested experimental test

[Gregory Heytings]

>
> And describing it as an "experiment", as though your intention is purely 
> to discover something about Emacs use, is more than a little 
> disingenuous.
>

Thank you so much for your kind words.

Re: Suggested experimental test

[Alfred M. Szmidt]

Well said.

   And describing it as an "experiment", as though your intention is purely
   to discover something about Emacs use, is more than a little disingenuous.

It is exactly how M-o was forced through, "an experiment" -- people
objected, those who just didn't care the keybinding (i.e. people who
had already rebound it, or didn't use it) weren't effected.

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

  > > > Gregory, don't you think that 3 users including me who expressed their 
  > > > objections is not part of the experiment already?

  > > No, precisely because nobody actually experimented the potential change. 

  > There's no need for any "experiment".  It's perfectly obvious what you're
  > proposing and the effect it will have.

What we don't know is how many users will oppose the change, nor what
reasons they will give us.  It is not absurd to try an experiment to
find out.

However, when people say before the experiment that they oppose the
removal, they do count.  They are users and they know they use this
feature.

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-22 20:08]:
> 
> > > > 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?
> > 
> > For now I count 3 people from mailing lists who already objected to it,
> > including me.
> > 
> 
> I've only seen one (you), and perhaps a second one (Alfred), but I'm not
> quite sure because he initially thought that open-line would be
> removed.

Plus Rudolf Schlatte who explained using `C-o` frequently. Those are 3 for now.

> > How do you Lars insert new lines, before the current line with cursor?
> > 
> 
> I can't speak for Lars, but if this is something that I frequently needed, I
> would either learn the C-p C-e C-m sequence, or make it a command in my init
> file, for example:
> 
> (global-set-key (kbd "M-RET") (lambda () (interactive) (previous-line) (end-of-line) (newline-and-indent)))
> 
> (M-RET has a similar purpose in org-mode.)

That is good that you tell how you do it. Sounds funny to me,
obviously we have different ways to getting to same result. I am
inserting lines frequently and I would never think of using `C-p C-e
C-m` -- which now makes sense, as from your side you probably do not
insert lines, so for you `C-o` does not make sense.

In considerations if some change is useful one has to consider also
what other people are doing when they want to achieve functionality X,
in this case `open-line` which is often used to insert new lines
before the current one.

From your viewpoint, you are already using 3 keys to get to the
result, for you is fine to replace `C-o` with `C-o C-o` as that one
would any way shorten your own 3-keys sequence. But it looks like you
do not even use C-o to open a new line, like `C-a C-o` seems something
you did not use when cursor is not at beginning of wthe line.

Meeting users and their behavior of editing in relation to specific
feature is better, it is more productive, and gives more insights.

> > Gregory, don't you think that 3 users including me who expressed their
> > objections is not part of the experiment already?
> 
> No, precisely because nobody actually experimented the potential
> change. You cannot give an opinion on a change before experimenting
> it for some time, say, at least a day.

I am also thankful for that insight. For me, the experiment begins
with the simple introduction at the moment of understanding it. For
you it begins then when people actually start using it -- but you miss
the fact that some people would not even start experimenting with it
as they do not find it useful in the first place and do not want to
change their habits.

Experiment should not be conducted for the sake of experiment
alone. It should be conducted to improve the usability or user
experience with editor.

In my opinion, experiments of changing key bindings should not be
conducted with the purpose of introduction of new commands, but with
the purpose of making usability or user experience or efficiency of
editing better.

Checklist for key binding experiments:

1. [ ] - Conduct research, is the key binding included in Emacs-like
   editors like Emacs on Guile, Zile on Guile, Zile, mg, e3m, MIT
   Scheme's Edwin, and maybe few other similar.

2. [ ] - Conduct online research if the command and key binding is
   frequently asked for by users, review occurences of mentioning the
   command and the key binding on EmacsWiki, manual, and other
   websites by using search engines.

3. [ ] - Instead of proposing the experiment too early, ask people how
   they are doing the functionality X -- don't ask if they are using
   specific command `you-name-it`; example is how I have asked you and
   Lars "How are you inserting new line from the current line?" -- and
   I am still curious how people are doing it. Question is not really
   related to `C-o` or `open-line` but to the result of it that could
   be achieved by various different ways.

4. [ ] - Decide what is your proposal to replace key binding, define
   it well, but don't publish on the mailing list (or do publish).

5. [ ] - Compare your proposal to the existing key binding and the
   command and make list of reasons why would your replaced key
   binding be more useful and beneficial for users, user experience or
   efficiency in editing than the already present key binding. For
   example if you have never used `C-o` it would be better to fully
   understand its usage as it can be you have quite different idea on
   how to insert new lines. But if you did not understand usage of
   `C-o` you should or could assume that your proposal is maybe
   biased by your own user experience.

6. [ ] - After the review, if you think your proposal is improving
   editing efficiency, or usability, or user experience, then propose
   the new change. Provide patch, initiate experiments, or ask people
   about it.

7. [ ] - Do not assume that experiment, objections, protests, begin
   with the actual invokation of the experiment, as people on the
   mailing list already understand by reading the Emacs Lisp code,
   consider their opinions as valid objections and count them even if
   they did not practically experiment with it -- as they obviously
   did not find it practical to experiment with.

8. [ ] - Count pro and contras. Even if there are more positives for
   your experiment, do not assume that it would really enhance user
   experience, or that you got users' feedback, as we are on this
   mailing list testing Emacs in development stage, while users will
   be using it in their daily life. Consider various implications,
   breaking habits of millions of people. Consider butterfly effects
   before introducing it in new stable version of Emacs.

Jean

Re: Suggested experimental test

[Robin Tarsiger]

Lars Ingebrigtsen wrote:
> 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'm a corner case here, FWIW. I use C-o quite frequently to open a new
line... except I didn't like Emacs's line-splitting behavior! Instead
I define dxc/vim-style-open-line as (goto-char (point-at-eol))
(insert "\n") to approximate what 'o' does in Vim. I should possibly
add support for a prefix argument to switch to before the current
line, and maybe indentation...

I think I mentioned in an earlier thread that any redefinition of
C-o would probably make me grumble for a short while before adjusting
my customizations to compensate, if nothing else. But I'm also quite
sympathetic to the "increasing skew between people's keymaps creates
fragmentation issues" line of thought---I'm just already invested in
one branch of response to that in practice...

-RTT

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

[Gregory Heytings]

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

But of course, as you said a month ago:

>
> This question also goes to everyone else in this long dispute who wants 
> their precious key bindings preserved: why is such a long discussion 
> needed when it is so easy to restore, in your init file, a binding you 
> want preserved?
>

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Mon, 22 Mar 2021 17:55:31 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, 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_.
> >
> 
> But of course, as you said a month ago:
> 
> >
> > This question also goes to everyone else in this long dispute who wants 
> > their precious key bindings preserved: why is such a long discussion 
> > needed when it is so easy to restore, in your init file, a binding you 
> > want preserved?

Sure.  But what I wrote then didn't prevent you-all from flooding this
list with precisely the discussions I tried to prevent.

And anyway, I was responding to Lars's question about the use of this
key.  I said nothing else.

Re: Suggested experimental test

[Gregory Heytings]

>>>> 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_.
>>
>> But of course, as you said a month ago:
>>
>>> This question also goes to everyone else in this long dispute who 
>>> wants their precious key bindings preserved: why is such a long 
>>> discussion needed when it is so easy to restore, in your init file, a 
>>> binding you want preserved?
>
> Sure.  But what I wrote then didn't prevent you-all from flooding this 
> list with precisely the discussions I tried to prevent.
>

I'm sorry for this, that's not what I wanted.  What would be the way to 
conduct such an experiment without provoking such a flooding, for those 
who do not have write access to the trunk?

IMO Emacs is now in a position that is similar to that of Emacs 16, when 
RMS introduced modes.  He realized that he needed a prefix key for them, 
and he did not choose to use one of the yet unused meta keys: instead he 
repurposed C-c and moved its command somewhere else.  The need for such a 
prefix key is something that he could not have envisioned while writing 
Emacs 1, it became apparent only later.  Likewise, some time later, when 
user configuration files became common, the C-c LETTER keys were freed. 
Again the need for this could not have been seen beforehand, and again RMS 
did not choose to use a free meta key for this.

Now the situation is that third-party packages are becoming more and more 
popular, something which couldn't have been envisioned twenty years ago, 
and these packages can't be installed in a simple way, that is, without 
asking users to fiddle with their configuration files, to define some 
global key bindings that these packages need.  I don't see why we 
shouldn't act in the same way RMS acted, that is, by repurposing one 
control key for them.

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Mon, 22 Mar 2021 20:22:21 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> >>> This question also goes to everyone else in this long dispute who 
> >>> wants their precious key bindings preserved: why is such a long 
> >>> discussion needed when it is so easy to restore, in your init file, a 
> >>> binding you want preserved?
> >
> > Sure.  But what I wrote then didn't prevent you-all from flooding this 
> > list with precisely the discussions I tried to prevent.
> 
> I'm sorry for this, that's not what I wanted.  What would be the way to 
> conduct such an experiment without provoking such a flooding, for those 
> who do not have write access to the trunk?

I basically think you cannot.  Any such theme is bound to produce a
long heated discussion.  We cannot do anything practical to prevent
it.  That's life.

> IMO Emacs is now in a position that is similar to that of Emacs 16, when 
> RMS introduced modes.  He realized that he needed a prefix key for them, 
> and he did not choose to use one of the yet unused meta keys: instead he 
> repurposed C-c and moved its command somewhere else.  The need for such a 
> prefix key is something that he could not have envisioned while writing 
> Emacs 1, it became apparent only later.  Likewise, some time later, when 
> user configuration files became common, the C-c LETTER keys were freed. 
> Again the need for this could not have been seen beforehand, and again RMS 
> did not choose to use a free meta key for this.
> 
> Now the situation is that third-party packages are becoming more and more 
> popular, something which couldn't have been envisioned twenty years ago, 
> and these packages can't be installed in a simple way, that is, without 
> asking users to fiddle with their configuration files, to define some 
> global key bindings that these packages need.  I don't see why we 
> shouldn't act in the same way RMS acted, that is, by repurposing one 
> control key for them.

The difference is that 37 years have passed, and what was then a
recent keybinding in a program that had only a very limited user base
is now a keybinding many users have hardwired into their muscles.

Another thing that changed is that there are nowadays many more active
contributors to Emacs who have their own (and different!) views on
this subject.  See below.  It was easy to make such decisions when
Emacs was an RCS repository on Richard's own machine, and he was the
only one who actually made changes.

Yet another thing that's changed is that we nowadays have much fewer
free keys to work with, and many of those, while unbound globally, are
likely to be bound by some mode which is dear to someone.  Part of the
reasons for the differences in opinions is that different people use
different modes and have different usage patterns, and thus keybinding
that are important to some might be unimportant (or even unknown, as
these discussions repeatedly show!) to others.  How can we ever
significantly agree on removing or changing a keybinding under these
circumstances?

And one more thought, regarding the problem that 3rd-party packages
have: it can be argued that this is not our problem.  Why should users
of Emacs that never heard of package P and will likely never use it
pay the price? why couldn't the developers of P solve the problem
which is in a way caused by P and whose solution benefits the users of
P?  Some might think that shifting the price to the Emacs core is the
wrong way of dealing with the problem.  The solution could be for P to
use longer key sequences (which usurps fewer keys on the top level),
and if some users of P are unhappy about that, then those users could
rebind the commands privately to any key they like.  Think about it.

Re: Suggested experimental test

[Gregory Heytings]

>
> The difference is that 37 years have passed, and what was then a recent 
> keybinding in a program that had only a very limited user base is now a 
> keybinding many users have hardwired into their muscles.
>
> Another thing that changed is that there are nowadays many more active 
> contributors to Emacs who have their own (and different!) views on this 
> subject.  See below.  It was easy to make such decisions when Emacs was 
> an RCS repository on Richard's own machine, and he was the only one who 
> actually made changes.
>
> Yet another thing that's changed is that we nowadays have much fewer 
> free keys to work with, and many of those, while unbound globally, are 
> likely to be bound by some mode which is dear to someone.  Part of the 
> reasons for the differences in opinions is that different people use 
> different modes and have different usage patterns, and thus keybinding 
> that are important to some might be unimportant (or even unknown, as 
> these discussions repeatedly show!) to others.  How can we ever 
> significantly agree on removing or changing a keybinding under these 
> circumstances?
>

I see your points, but all this is rather sad, because it means that Emacs 
is forever locked by what looks very much like a historical accident.

>
> And one more thought, regarding the problem that 3rd-party packages 
> have: it can be argued that this is not our problem.  Why should users 
> of Emacs that never heard of package P and will likely never use it pay 
> the price? why couldn't the developers of P solve the problem which is 
> in a way caused by P and whose solution benefits the users of P?  Some 
> might think that shifting the price to the Emacs core is the wrong way 
> of dealing with the problem.  The solution could be for P to use longer 
> key sequences (which usurps fewer keys on the top level), and if some 
> users of P are unhappy about that, then those users could rebind the 
> commands privately to any key they like.  Think about it.
>

I'm not sure if the above ("this is not our problem") is your opinion, or 
if you just present a possible viewpoint you do not necessarily share. 
This has been discussed to death already, and (as you already know) IMO it 
is a problem that will have to be solved by Emacs itself, sooner or later. 
It does not apply to a single package P, or only to a few packages.

Just type emacs -Q, M-x list-packages RET, RET.  The package you now see 
('ace-window') asks you to fiddle with your init file by adding a 
'global-set-key' to it.  The second package in the list ('ack') does the 
same.  And so forth.  That's not a problem for you and me, it is a problem 
for newcomers, and these 'global-set-key's should be done automatically, 
during the installation process.  Do you know any other software that asks 
you to change a configuration file manually to use an extension package?

As the author of Magit wrote when he added the "C-x g" global binding:

"Some [...] beginners will initially have a low threshold for things not 
working out of the box and I don't want to (continue to) scare them off by 
immediately forcing them to learn how to add key bindings and what that 
even means.  There's a lot of talk about making Emacs friendlier for 
beginners and this is a small step in that direction." [1]

[1] https://github.com/magit/magit/pull/4237#issuecomment-723495053

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Tue, 23 Mar 2021 14:15:26 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> I see your points, but all this is rather sad, because it means that Emacs 
> is forever locked by what looks very much like a historical accident.

I disagree, on both counts: Emacs isn't locked, and what we have is
not an accident.  The utmost easiness with which users can change the
key bindings means there isn't, and can never be, a lockdown.

> I'm not sure if the above ("this is not our problem") is your opinion, or 
> if you just present a possible viewpoint you do not necessarily share. 

Does it matter?

> Just type emacs -Q, M-x list-packages RET, RET.  The package you now see 
> ('ace-window') asks you to fiddle with your init file by adding a 
> 'global-set-key' to it.  The second package in the list ('ack') does the 
> same.  And so forth.  That's not a problem for you and me, it is a problem 
> for newcomers, and these 'global-set-key's should be done automatically, 
> during the installation process.  Do you know any other software that asks 
> you to change a configuration file manually to use an extension package?

I disagree that it's a problem.  Customizing key bindings is an
integral part of using Emacs wisely and efficiently, and the sooner
newcomers learn that the better.  Emacs is unlike many other editors
in this regard.

> As the author of Magit wrote when he added the "C-x g" global binding:
> 
> "Some [...] beginners will initially have a low threshold for things not 
> working out of the box and I don't want to (continue to) scare them off by 
> immediately forcing them to learn how to add key bindings and what that 
> even means.  There's a lot of talk about making Emacs friendlier for 
> beginners and this is a small step in that direction." [1]
> 
> [1] https://github.com/magit/magit/pull/4237#issuecomment-723495053

I can only say I disagree, with all due respect to Magit and its
authors.  Trying to make everybody happy with the default Emacs key
bindings is a dead end.  Trying to solve that unsolvable problem is a
waste of energy.

Re: Suggested experimental test

[Gregory Heytings]

>> I see your points, but all this is rather sad, because it means that 
>> Emacs is forever locked by what looks very much like a historical 
>> accident.
>
> I disagree, on both counts: Emacs isn't locked, and what we have is not 
> an accident.
>

I think you understood what I meant: the "C-o" key is locked in the 
default bindings, and the fact that "C-o" was bound to open-line is a 
historical accident.

>
> I disagree that it's a problem.  Customizing key bindings is an integral 
> part of using Emacs wisely and efficiently, and the sooner newcomers 
> learn that the better.  Emacs is unlike many other editors in this 
> regard.
>

Let's (again) agree to disagree then.  IMO Emacs should aim at being fully 
usable, including all its extensions, without ever having to edit 
configuration files manually (and without restarting Emacs).

Packages that need to define keys globally should have a way to do that, 
just like major and minor mode packages.

Major and minor mode packages can define keys that work out of the box in 
buffers in which these modes are enabled.  I suppose everyone would agree 
that asking users who install a foo-mode package to add

(define-key foo-mode-map (kbd "<some key>") #'foo-mode-do-something)

lines in their init configuration file (and to restart Emacs) before being 
able to use foo-mode would be cumbersome.

>
> Trying to make everybody happy with the default Emacs key bindings is a 
> dead end.  Trying to solve that unsolvable problem is a waste of energy.
>

That's not at all what I aim(ed) at.  And the problem I want(ed) to solve 
is not unsolvable, it has a simple solution.

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Tue, 23 Mar 2021 16:51:47 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: larsi@gnus.org, emacs-devel@gnu.org
> 
> >> I see your points, but all this is rather sad, because it means that 
> >> Emacs is forever locked by what looks very much like a historical 
> >> accident.
> >
> > I disagree, on both counts: Emacs isn't locked, and what we have is not 
> > an accident.
> 
> I think you understood what I meant: the "C-o" key is locked in the 
> default bindings, and the fact that "C-o" was bound to open-line is a 
> historical accident.

Yes, understood and disagreed with both.

Re: Suggested experimental test

[Alfred M. Szmidt]

   >> I see your points, but all this is rather sad, because it means that 
   >> Emacs is forever locked by what looks very much like a historical 
   >> accident.
   >
   > I disagree, on both counts: Emacs isn't locked, and what we have is not 
   > an accident.

   I think you understood what I meant: the "C-o" key is locked in the 
   default bindings, and the fact that "C-o" was bound to open-line is a 
   historical accident.

C-o is bound where it is because when Emacs was written, someone --
most probpobly RMS -- bound it there, so it isn't really a historical
accident but rather an active design decision. There is also a reason
why C-x C-o where it is.

Re: Suggested experimental test

[Gregory Heytings]

>
> C-o is bound where it is because when Emacs was written, someone -- most 
> probpobly RMS -- bound it there, so it isn't really a historical 
> accident but rather an active design decision. There is also a reason 
> why C-x C-o where it is.
>

I digged further in my archives.  In case some are interested:

As most of you know, the original Emacs was written in TECO.  C-o was a 
command of TECO's real-time editing feature (which was entered with C-r), 
which was imported into Emacs.  The purpose of C-o in TECO was to optimize 
redisplay: when point on in the middle of a non-empty line, C-o F O O 
required less redisplay than F O O RET.

C-o in the original Emacs didn't quite do what C-o now does: the line(s) 
created by C-o were "eated" by the text that was inserted.  In other 
words, RET in the line(s) created with C-o did not push the next lines 
down, it went on the next created line (if any).  In other words again, 
let's assume the following initial situation:

  A
|D
  E

where | is the point.  After C-u 2 C-o B RET C RET, the buffer was now:

  A
  B
  C
|D
  E

In other words again, C-o was meant to "create some blank space on the 
screen" (not in the buffer) to optimize redisplay.

Do you now see the "historical accident"?

Re: Suggested experimental test

[Alfred M. Szmidt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1492 bytes --]

[WARNING: I AM A TECO EMACS USER!]

   C-o in the original Emacs didn't quite do what C-o now does: the line(s) 
   created by C-o were "eated" by the text that was inserted.  In other 
   words, RET in the line(s) created with C-o did not push the next lines 
   down, it went on the next created line (if any).  

It does exactly the same thing it does today.  Maybe you are confusing
this with the way the gap buffer works?

   In other words again, 
   let's assume the following initial situation:

     A
   |D
     E

   where | is the point.  After C-u 2 C-o B RET C RET, the buffer was now:

     A
     B
     C
   |D
     E

That is not the behaviour of TECO emacs, you would have two extra two
newlines there, like in GNU emacs.

"So, FOO Return is equivalent to C-o FOO."

>   You can make several blank lines by typing ‘C-o’ several times, or by
>giving it a numeric argument specifying how many blank lines to make.
>*Note Arguments::, for how.  If you have a fill prefix, the ‘C-o’
>command inserts the fill prefix on the new line, if typed at the
>beginning of a line.  *Note Fill Prefix::.
>
>   The easy way to get rid of extra blank lines is with the command ‘C-x
>C-o’ (‘delete-blank-lines’).  If point lies within a run of several
>blank lines, ‘C-x C-o’ deletes all but one of them.  If point is on a
>single blank line, ‘C-x C-o’ deletes it.  If point is on a nonblank
>line, ‘C-x C-o’ deletes all following blank lines, if any exists.

Re: Suggested experimental test

[Gregory Heytings]

>
> [WARNING: I AM A TECO EMACS USER!]
>

Of which version?

>
> It does exactly the same thing it does today.
>

No it didn't.  See AIM memo 554, written by RMS, dated October 1981:

"If you want to insert many lines, you can type many C-O's at the 
beginning (or you can give C-O an argument to tell it how many blank lines 
to make [...]).  As you then insert lines of text, you will notice that 
Return behaves strangely: it "uses up" the blank lines instead of pushing 
them down."

Re: Suggested experimental test

[Alfred M. Szmidt]

   > [WARNING: I AM A TECO EMACS USER!]

   Of which version?

162.

   > It does exactly the same thing it does today.

   No it didn't.  

I stand by my claim, maybe you should login on an ITS machine before
trying to contradict someone who uses the system on a semi-regular
basis?

Re: Suggested experimental test

[Gregory Heytings]

>>> It does exactly the same thing it does today.
>>
>> No it didn't.
>
> I stand by my claim, maybe you should login on an ITS machine before 
> trying to contradict someone who uses the system on a semi-regular 
> basis?
>

I gave a quote of the 1981 manual written by RMS, for "EMACS version 161" 
(AIM memo 554), which everyone can download and read.  It's very well 
possible that C-o was changed in version 162.

Re: Suggested experimental test

[Alfred M. Szmidt]

   It's very well possible that C-o was changed in version 162.

From what I can see (release notes, older versions), it wasn't.  Much
of the memo is a direct copy of the manual, so it is more plausible
that this is just a very old note that didn't get pruned from the memo
and refers to a very early Emacs which quickly modifed the behaviour.

If you want, we can continue the archeology somewhere else, don't
think this is teco-history@ ;)

Re: Suggested experimental test

[Gregory Heytings]

>
> From what I can see (release notes, older versions), it wasn't.  Much of 
> the memo is a direct copy of the manual, so it is more plausible that 
> this is just a very old note that didn't get pruned from the memo and 
> refers to a very early Emacs which quickly modifed the behaviour.
>

I stand by what I said, except that I now understand that it's the 
behavior of RET that was changed.  But that doesn't change the fact that 
C-o was initially meant to optimize redisplay by creating some blank space 
before filling it.  See below:

Date: 12 September 1981 03:11-EDT
From: Richard M. Stallman <RMS at MIT-AI>
Subject: poll on C-S, C-O, and Return
To: INFO-EMACS-RECIPIENTS at MIT-AI

What do you think of these two suggested changes to EMACS?

1) Make Altmode not be ignored when it terminates a search, so that it
would still function as a Metizer.  Some other character would have to
be provided instead as a way of terminating a search and doing nothing
else.  C-D was suggested, but I don't like it.  I'd like to hear other
suggestions.

2) Make C-O do what C-A C-O Tab does now.

3) Also, how many people now find it useful or desirable that Return
eats up blank lines?  This feature was invented in the days when
terminals did not have insert/delete line.

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

  >    > It does exactly the same thing it does today.

  >    No it didn't.  

  > I stand by my claim, maybe you should login on an ITS machine before
  > trying to contradict someone who uses the system on a semi-regular
  > basis?

If you could disagree in a more friendly tone, it would make this
mailing list more civil to be on.

Could this disagreement perhaps be moved to emacs-tangents?

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

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

  > C-o in the original Emacs didn't quite do what C-o now does: the line(s) 
  > created by C-o were "eated" by the text that was inserted.  In other 
  > words, RET in the line(s) created with C-o did not push the next lines 
  > down, it went on the next created line (if any).

For historical accuracy, I should correct that statement.

C-o inserted a line break in the buffer after point.
RET advanced over a newline into a blank line;
otherwise it inserted a newline.  In this way, RET would
eat up the blank lines.

Both of them operated by modifying the buffer, and the screen
reflected the buffer contents.

I sometimes made several black lines with C-u C-o or C-u C-u C-o,
then filled them in, advancing by RET.  At the end, if exta blank
lines remained, I removed them with C-x C-o.

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

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-24 00:07]:
> 
> > 
> > C-o is bound where it is because when Emacs was written, someone -- most
> > probpobly RMS -- bound it there, so it isn't really a historical
> > accident but rather an active design decision. There is also a reason
> > why C-x C-o where it is.
> > 
> 
> I digged further in my archives.  In case some are interested:
> 
> As most of you know, the original Emacs was written in TECO.  C-o was a
> command of TECO's real-time editing feature (which was entered with C-r),
> which was imported into Emacs.  The purpose of C-o in TECO was to optimize
> redisplay: when point on in the middle of a non-empty line, C-o F O O
> required less redisplay than F O O RET.

As "Emacs" by name, it was maybe in TECO, but we are here in GNU
Emacs, not in TECO by its name.

Please see this timeline (no accuracy guarantee) from:
https://www.jwz.org/doc/emacs-timeline.html


1976    TECMAC and TMACS
        a pair of "TECO-macro realtime editors."
        by Guy Steele, Dave Moon, Richard Greenblatt,
        Charles Frankston, et al.
          |
          |
1976    EMACS
        by Richard Stallman, Guy Steele,       EINE (EINE Is Not EMACS)
        and Dave Moon.                         by Dan Weinreb.
        Merger of TECMAC and TMACS, plus       for MIT Lisp Machine.
        a dynamic loader and Meta-key cmds.    First Emacs written in Lisp.
        Ran on ITS and TWENEX (Tops-20)                |
        written in TECO and PDP 10 assembly.           |
                                                       |
                                                       |
1978    Multics Emacs                         ZWEI (ZWEI Was EINE Initially)
        by Bernie Greenberg.                  by Dan Weinreb and Mike McMahon.
        written in MacLisp;                            |
        also used Lisp as its                          |
        extension language.                            |
1980                                         ZMACS (direct descendant of ZWEI)
                                             on Symbolics LM-2, LMI LispM,
                                             and later, TI Explorer (1983-1989)
1981               Gosling Emacs                       :
                   by James Gosling                    :
                   written in C; with "Mocklisp"
                   as its extension language.
                       /      |
1983                  /       |
                     /   Unipress Emacs (6-may-83)
                    /    $395 commercial product.
1984               /                                   Hemlock
                  /                                    by Bill Chiles,
                 /                                     Rob MacLachlan, et al.
1985  GNU Emacs 13.0? (20-mar-85)                      written in Spice Lisp
      by Richard Stallman.                             (CMU Common Lisp)
      initial public release?                              :
             |                                             :
      GNU Emacs 15.10 (11-apr-85)                          :
             |
      GNU Emacs 15.34 (07-may-85)
             |
      GNU Emacs 16.56 (15-jul-85)
      (Gosling code expunged
      for copyright reasons)
             |
             |
      GNU Emacs 16.60 (19-sep-85)
      (contained first patches from
      the net, including preliminary
      SYSV support)
             |
             |
      GNU Emacs 17.36 (20-dec-85)
      (included TeX manual; first
      version that worked on SYSV
      out of the box)
             |
             |
1986  GNU Emacs 18.24 beta (02-oct-86)
             |
1987  GNU Emacs 18.41 (22-mar-87)
             |
      GNU Emacs 18.45 (02-jun-87)
             |
      GNU Emacs 18.49 (18-sep-87)
             |   \
             |    \________________________________________________
             |                                                     \
             |                                                      \
             |                                           Early work on Epoch begins (1987)
             |                                           by Alan M. Carroll
1988  GNU Emacs 18.50 (13-feb-88)                                     |
             |                                                        |
      GNU Emacs 18.51 (07-may-88)                                     |
             |                                                        |
      GNU Emacs 18.52 (01-sep-88)                                     |
             |                                            Epoch 1.0 (14-dec-88)
             |                                            by Alan M. Carroll with Simon Kaplan
1989  GNU Emacs 18.53 (24-feb-89)                                     |
             |   \                                                    |
             |    \________________________________________________   |   _____
             |                                                        |        \
      GNU Emacs 18.54 (26-apr-89)                                     |         \
             |                                                        |          \
      GNU Emacs 18.55 (23-aug-89)                                     |           \ 
             |    |                                                   |            \
             |    |                                                   |     NEmacs 3.2.1 (15-dec-89)
             |    |                                                   |     "Nihongo Emacs": a fork
             |    |                                                   |     with multi-byte Japanese
             |    |                                                   |     language support.
             |    |                                                   |             |
             |    |                                       Epoch 2.0 (23-dec-89)     |
             |    |                                                   |             |
             |    |                                                   |             |
1990         |    |                                       Epoch 3.1 (06-feb-90)     |
             |    |                                                   |             |
             |    \                                                   |     NEmacs 3.3.1 (3-mar-90)
             |     \                                                  |             |
             |      \                                     Epoch 3.2 (11-dec-90)     |
             |       \                                    last Carroll release.     |
             |        \____ (sporadic work on                         |             |
             |               GNU Emacs 19 begins)                     |             |
             |                     |                                  |             |
             |                     |                                  |             |
             |                     |                      Epoch 4.0 (27-aug-90)     |
             |                     |                      Now maintained by NCSA.   |
             |                     |                                  |             |
1991  GNU Emacs 18.57 (??-jan-91)  |                                  |             |
             |                     |                                  |             |
      GNU Emacs 18.58 (??-???-91)  |                                  |             |
             |                     |                                  |             |
1992         |                     |___                               |     MULE 0.9.0b (4-mar-92)
             |                     |   \                              |     "Multilingual
             |                     |    \                             |     Enhancements to Emacs":
             |                     |     \                            |     support for input methods
             |                     |      \                           |     and various languages
             |                     |   Lucid Emacs 19.0 (??-apr-92)   |     including Japanese,
             |                     |   by Jamie Zawinski et al.       |     Chinese, Korean, Greek,
             |                     |      |                           |     Hebrew, and Cyrillic.
             |                     |   Lucid Emacs 19.1 (04-jun-92)   |             |
             |                     |      |                           |             |
             |                     |   Lucid Emacs 19.2 (19-jun-92)   |             |
             |                     |      |                           |             |
             |                     |   Lucid Emacs 19.3 (09-sep-92)   |             |
      GNU Emacs 18.59 (31-oct-92)  |      |                           |             |
             |                     |      |                           |             |
1993         |                    /    Lucid Emacs 19.4 (21-jan-93)   |             |
             |                   /        |                           |             |
             |                  /      Lucid Emacs 19.5 (05-feb-93)   |             |
             |                 /       (trade-show giveaway CD only)  |             |
             |                /           |                           |             |
             |   ____________/         Lucid Emacs 19.6 (09-apr-93)   |             |
             |  /                         |                           |             |
             | /                          |                           |             |
      GNU Emacs 19.7 beta (22-may-93)     |                          /|             |
      first public v19 beta               |                         / |             |
             |                            |                        /  |  ...___     |
      GNU Emacs 19.8 beta (27-may-93)     |                       /   |        \    |
             |        \                   |                      /    |         \   |
             |         \________________  |  ___________________/     |     MULE 1.0 (1-aug-93)
             |                          \ | /                         |     (based on GNU Emacs 18.59)
             |                         Lucid Emacs 19.8 (06-sep-93)   |             |
             |                         (Epoch merger, preliminary     |             |
             |                          I18N support)                 |             |
             |                            |                           |             |
      GNU Emacs 19.22 beta (28-nov-93)    |                           |             |
             |                            |                           |             |
1994         |                         Lucid Emacs 19.9 (12-may-94)  /              |
             |                         (scrollbars, Athena)         /               |
             |                            |                        /                |
      GNU Emacs 19.23 beta (17-may-94)    |                       /                 |
             |            \               |                      /                  |
             |             \____________  |  ___________________/                   |
             |                          \ | /                                       |
             |                         Lucid Emacs 19.10 (27-may-94)                |
             |                         last JWZ release.                            |
             |                            |                                         |
      GNU Emacs 19.24 beta (16-may-94)    |                                         |
             |                            |                               ...___    |
             |                            |                                     \   |
             |                            |                                      \  |
             |                            |                                 MULE 2.0 (6-aug-94)
             |                            |                                 (based on GNU Emacs 19.25)
             |                            |                                         |
             |                         XEmacs 19.11 (13-sep-94)                     |
             |                         Lucid Emacs -> XEmacs renaming.              |
             |                         now maintained by Chuck Thompson             |
             |                         and Ben Wing.                                |
             |                            |                                         |
      GNU Emacs 19.27 beta (14-sep-94)    |                                         |
             |                            |                                         |
      GNU Emacs 19.28 (01-nov-94)         |                                         |
      first official v19 release.         |                               ...___    |
             |                            |                                     \   |
             |                            |                                      \  |
             |                            |                                 MULE 2.2 (28-dec-94)
             |                            |                                 (based on GNU Emacs 19.28)
             |                            |                                         |
             |                            |                                         |
1995         |                            |                                 MULE 2.3 (24-jul-95)
             |                            |                                         .
             |                         XEmacs 19.12 (23-jun-95)                     .
             |                         (tty support)    \                           .
      GNU Emacs 19.29 (21-jun-95)         |              \                          .
             |                            |        (work on 20.x begins)            .
      GNU Emacs 19.30 (24-nov-95)         |               :                         .
             |           \                |               :                         .
             |            \_____________  |                                         .
             |                          \ |                                         .
             |                         XEmacs 19.13 (01-sep-95)                     .
1996  GNU Emacs 19.31 (25-may-96)         |                                         .
             |                         XEmacs 19.14 (23-jun-96)                     .
      GNU Emacs 19.34 (21-aug-96)         |                   \                     .
1997         |                         XEmacs 20.0 (09-feb-97) \                    .
             |                         now maintained by        \                   .
             |                         Steve Baur.               |                  .
             |                            |           XEmacs 19.15 (26-mar-97)      .
             |                            |                      |                  .
             |                         XEmacs 20.1 (15-apr-97)   |                  .
             |                            |                      |                  .
             |                         XEmacs 20.2 (16-may-97)   |                  .
      GNU Emacs 20.1 (17-sep-97)          |                      |                  .
             |                            |                      |                  .
      GNU Emacs 20.2 (20-sep-97)          |                      |                  .
             |                            |           XEmacs 19.16 (31-oct-97)     .
             |                            |                                       .
             |                         XEmacs 20.3 (21-nov-97)                   .
             |                            |                                     /
             |                            |    ________________________________/
             |                            |   /
             |                            |  /
1998         |                         XEmacs 20.4 (28-feb-98)
             |                         first reasonably stable
             |                         release with MULE support.
             |                         XEmacs "core" and "packages"
             |                         now packaged separately.
             |                            |
             |                            |
             |                         XEmacs 21.0-pre5 (18-jul-98)
             |                         Numbering scheme goes wonky due to
             |                         switch to stable + unstable branches.
      GNU Emacs 20.3 (19-aug-98)          |
             |                            |
             |                         XEmacs 21.0.60 (10-dec-98)
             |                           /  \___________________
             |                          /                       \
1999         |                         /             XEmacs 21.2.9 (03-feb-99)
             |                        /              (trunk / unstable branch)
             |                       /                           |
             |                XEmacs 21.1.3 (26-jun-99)          |
             |                (stable / maintenance branch)      |
             |                maintained by Vin Shelton.         |
             |                       |                           |
      GNU Emacs 20.4 (12-jul-99)     |                           |
             |                       |                           |
2000         |                       |               XEmacs 21.2.27 (18-jan-00)
             |                       |                           |
             |                XEmacs 21.1.9  (13-feb-00)         |
             |                       |                           |
      GNU Emacs 21.1 (20-oct-01)     |               XEmacs 21.2.36 (04-oct-00)
             |                       |                           |
2001         |                XEmacs 21.1.14 (27-jan-01)         |
             |                (branch retired)                   |
             |                                       XEmacs 21.2.40 (08-jan-01)
             |                             ____________________/ |
             |                            /                      |
             |                           /           XEmacs 21.5.0  (18-apr-01)
             |                          /            (trunk / unstable branch)
             |                         /                         |
             |                XEmacs 21.4.0  (16-apr-01)         |
             |                (stable / maintenance branch)      |
             |                Maintained by Stephen Turnbull.    |
             |                Shipped by Red Hat, Debian,        |
             |                Mandrake, etc.                     |
             |                        |                          |
2002  GNU Emacs 21.2 (16-mar-02)      |              XEmacs 21.5.6  (05-apr-02)
             |                        |                          |
             |                XEmacs 21.4.7  (04-may-02)         |
             |                        |                          |
2003         |                XEmacs 21.4.12 (15-jan-03)         |
             |                first "stable" 21.4                |
             |                        |                          |
      GNU Emacs 21.3 (19-mar-03)      |                          |
             |                        |                          |
             |                XEmacs 21.4.13 (25-may-03)         |
             |                maintained by Vin Shelton.         |
             |                        |                          |
             |                        |              XEmacs 21.5.14 (01-jun-03)
             |                        |                          |
             |                XEmacs 21.4.14 (05-sep-03)         |
             |                        |                          |
             |                        |              XEmacs 21.5.16 (26-sep-03)
2004         |                        |                          |
             |                XEmacs 21.4.15 (03-feb-04)         |
             |                        |                          |
             |                        |              XEmacs 21.5.18 (22-oct-04)
             |                        |                          |
             |                XEmacs 21.4.17 (06-feb-05)         |
2005         |                        |                          |
      GNU Emacs 21.4a (17-feb-05)     |              XEmacs 21.5.19 (18-feb-05)
             |                        |                          |
             |                        |              XEmacs 21.5.23 (26-oct-05)
             |                        |                          |
             |                XEmacs 21.4.18 (03-dec-05)         |
             |                        |                          |
             |                        |              XEmacs 21.5.24 (19-dec-05)
             |                        |                          |
2006         |                XEmacs 21.4.19 (28-jan-06)         |
             |                        |                          |
             |                        |              XEmacs 21.5.28 (21-may-06)
             |                        |
             |                XEmacs 21.4.20 (09-dec-06)
             |                        |
      GNU Emacs 22.1 (02-jun-07)      |
                                      |
2007                          XEmacs 21.4.21 (14-oct-07)

Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-23 20:53]:
> IMO Emacs should aim at being fully usable, including all its
> extensions, without ever having to edit configuration files manually
> (and without restarting Emacs).

From that specific view point how you think Emacs should work that
users ever edit configuration file manually, I do understand it. It
would increase the usability of Emacs by beginners, but it would hide
the configuration file which is program and software that users
create. We have got butterfly effect in Emacs from where you and other
people came to improve Emacs and created many other software.

Reference: https://en.wikipedia.org/wiki/Butterfly_effect

Because Emacs was never Android with "click and play" features, it
created so many programmers. Because it is programmable Editor it
helped many programmers to extend Emacs.

Would we have all the features in Emacs by the system "Click and Play"
very easy to go -- we would have less people collaborating on creating
free software and also software extending Emacs. 

We can see that in example on Android devices where users are
clueless, totally clueless that they can change, modify, create some
software. They are not told so, they are shaped as consumers, used,
who use applications and considered as number, not human, without any
collaboration or participation in software. They have no idea what is
Android, how it runs, how could they contribute, not even file bugs,
few free software repositories help on that like F-Droid -- but from
beginners' view point, software is too usable, but users may not even
be aware that it is software, as all what they did is "click and
play". It shaped our society to have largest number of computer users
ever, also the largest number of programmers, but it made the worse
ever ratio of number of programmers to number of computers!

Emacs such as it is, is raising the number of programmers to the
number of computers, as it gives incentives to users, incidentally or
planned, to evaluate things, to work with other software, to configure
this and that, and that is how programmers evolve.

I would not be thus changing Emacs into situation where use is not
supposed to think and create, as that situation we already have with
Android and society of computer users who do not even know they are
computer users.

From the general view point of Emacs usability for beginners,
beginners use arrows, they move cursor, use mouse, insert letters,
symbols and numbers, open and save files. Emacs is thus very user
friendly. I was beginner, we all were beginners, was it difficult to
open and save files, write files? It was never difficult to me.

> Major and minor mode packages can define keys that work out of the box in
> buffers in which these modes are enabled.  I suppose everyone would agree
> that asking users who install a foo-mode package to add
> 
> (define-key foo-mode-map (kbd "<some key>") #'foo-mode-do-something)
> 
> lines in their init configuration file (and to restart Emacs) before being
> able to use foo-mode would be cumbersome.

I am sure it may look cumbersome, but user installing it is not a
beginner. If it is beginner, one will start looking into function
definition, it is incitement to learn programming, and yields with new
Emacs contributors and programmers making extensions for software.

By hiding configurations, we would limit evolvement of number of
programmers in future.

One other good example of people becoming programmers by casual
incitement is the scratch buffer. Removing it, would make less
programmers. Providing scratch buffers in various languages, would
make more programmers.

Jean

Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-23 17:19]:
> Just type emacs -Q, M-x list-packages RET, RET.  The package you now see
> ('ace-window') asks you to fiddle with your init file by adding a
> 'global-set-key' to it.  The second package in the list ('ack') does the
> same.  And so forth.  That's not a problem for you and me, it is a problem
> for newcomers, and these 'global-set-key's should be done automatically,
> during the installation process.

I really do not believe it is a problem for newcomers, but if you do,
I would like to see how you get that data.

Newcomers in almost any editor will be able to:

- move cursors with arrows
- insert chars with letters
- delete chars with backspace or DEL
- open and save files

That is it. More than that newcomers do not need. Almost every editor
will provide arrows as key bindings to move, saving and opening
files. 

As soon as newcomer starts installing `ace-window' it is not
"newcomer" any more. :-)

> Do you know any other software that asks you to change a
> configuration file manually to use an extension package?

Actually it is not software that asks user, but README or source
code. Software provides functions which user may use with M-x and for
convenience such can be placed in the menu or on key bindings. 

We already discussed that software could ask user about the proposed
key bindings and that it would be good so as it forwards artificial
intelligence in Emacs which now excels itself only in the "Emacs
Psychotherapist" part.

Your point is valid and useful. When asking which other software asks
you to change a configuration file manually, well, other software
usually do not install functions that become convenient when placed on
a key. So we do not speak just of extensions, we speak of how to make
commands from extensions more convenient. They however work without
key bindings. Key bindings is convenience for commands.

Let us consider example of Gimp as other software, not being editor
and having extensions. GIMP works with GTK, and GTK allows changing
key bindings for every menu function on the fly. Isn't that handy?

Again, to allow such change for any function on the fly, one has to
configure it in: /home/data1/protected/.gtkrc-2.0.mine to be:

gtk-can-change-accels = 1

Then user can go to favorite function such as "Blur" and press key on
the menu item such as C-9 to assign Blur to C-9 on the fly.

From there on I see your proposal that users should be spared of
customizing key bindings very positive for progress of Emacs.

I do not know if Emacs GTK version allows GTK to change key bindings
by pressing a key on the menu, but it should in my opinion, follow the
example of GTK and GIMP above, and various other GTK based software,
at least in GTK version of Emacs. Maybe it does, I have never tried. 

To improve Emacs in general, I would propose that:

- Package authors should be nudged by instructions from the manual to
  make menu for the package by default, and that users can be asked
  upon installation if they wish to have menu turned on -- and how to
  turn it on later if they did not decide to turn it on. Menus could
  be sub-menu of new Extensions menu, as that way the menu line would
  not be full of various packages' menus.

- Once user is in any menu, user could then press a key and assign key
  bindings. If user attempts to assign default key binding, Emacs
  would ask user twice about that decision. Otherwise any empty key
  bindings could be assigned to menu.

- Package key binding assignment function. Instead or in addition to
  the menu system above that would allow simple customization by using
  mouse, Emacs could have a built in general function that summarizes
  all interactive commands from a package and asks user how to assign
  key bindings. This solves the problem on individual basis for each
  user separately, and does not ask package authors to do anything
  special.

Package key binding assignment function
=======================================

It would work as following:

- when package P is loaded, Emacs would create automatically new
  interactive function named P-assign-keys

- function `P-assign-keys' would encompass all interactive functions
  from package P

- it would ask user:

  - For the function P-function-1 "This function erases screen as
    example" -- would you like to assign key bindings?

    When user attempts to assign default key bindings, user would be
    asked twice if sure.

    When user attempts to assign already assigned, but not default key
    binding, function would say it is already assigned and again ask
    user twice

    If key is not bound, it would just get assigned.

- package authors could propose some default key bindings in a list
  that would be used by general key binding assignment function

That way all keys can be assigned interactively with user having
control how to do it. Package authors would not need to do anything
special. If they do propose some key bindings, they could provide a
list, and that list could be used by the general key bindings
assignment function. When `P-assign-keys' is invoked, it would display
some key bindings that package author recommended as default. Authors
could also exclude some functions from `P-assign-keys' processing
unless user press C-u to assign key bindings to all.

That would eliminate users to make key bindings, but it would also not
impose on users any new key bindings without users' control. 

Upon installation of a package, user could be asked if one wishes to
assign key bindings immediately.

> As the author of Magit wrote when he added the "C-x g" global binding:
> 
> "Some [...] beginners will initially have a low threshold for things not
> working out of the box and I don't want to (continue to) scare them off by
> immediately forcing them to learn how to add key bindings and what that even
> means.  There's a lot of talk about making Emacs friendlier for beginners
> and this is a small step in that direction." [1]
> 
> [1] https://github.com/magit/magit/pull/4237#issuecomment-723495053

Sorry, the above paragraph is to me contradictory, as who uses Magit
cannot be a beginner, and I telling people how to change key bindings
results with programmers who contribute to Emacs or make their own
packages. Let us not shoot in our own foot by sparing people to learn
something new.

Jean

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

[Dmitry Gutov]

On 23.03.2021 00:02, Stefan Kangas wrote:
> 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.

I think something like this is only worthwhile if we were changing a 
whole bunch of bindings. Like not just C-o, but also C-n and C-s, to 
their "other software" counterparts.

Perhaps not by default, but as a part of some "keybindings theme". Since 
the goal of the experiment was to free up the binding, that could've 
been beneficial in the context of such themes (the fewer important 
default bindings a theme touches, the fewer of them it has to reassign), 
but indeed not particularly critical given that C-o's current binding 
has no standard counterparts in other editors.

Re: Suggested experimental test

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 23.03.2021 00:02, Stefan Kangas wrote:
>> 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.
>
> I think something like this is only worthwhile if we were changing a
> whole bunch of bindings. Like not just C-o, but also C-n and C-s, to
> their "other software" counterparts.

Perhaps.  But it also gets progressively harder to convince emacs-devel
about it the more keys you add into the mix.  Being an old crank, I'm
not even sure I'm very convinced myself.  ;-)

> Perhaps not by default, but as a part of some "keybindings theme".

Yes, it would definitely be interesting to see if making far-reaching
changes in keybindings could work out.  A theme/profile would be a good
and presumably uncontroversial method to find out.

Re: Suggested experimental test

[Jean Louis]

* Dmitry Gutov <dgutov@yandex.ru> [2021-03-23 01:45]:
> Perhaps not by default, but as a part of some "keybindings theme". Since the
> goal of the experiment was to free up the binding, that could've been
> beneficial in the context of such themes (the fewer important default
> bindings a theme touches, the fewer of them it has to reassign), but indeed
> not particularly critical given that C-o's current binding has no standard
> counterparts in other editors.

Good idea!

Making an experimental theme that user can use with other themes
together is good idea that would not collide with anybody. Then NEWS
or other helpful information could ask users to test the key bindings
or other functions, and even users on Emacs stable could test it. The
experimental theme could be chosen from `customize-themes'. It could
also provide a reporting function so that users can send back their
impressions.

That way experiments go in parallel not disturbing the default key
bindings and users aware or willing to participate may do so.

Jean

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Tue, 23 Mar 2021 08:22:19 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, gregory@heytings.org,
>  Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefankangas@gmail.com>,
>  emacs-devel@gnu.org
> 
> That way experiments go in parallel not disturbing the default key
> bindings and users aware or willing to participate may do so.

That just delays the dispute to the point when we want to consider
making some of the bindings the default.  So it basically may solve a
secondary problem -- how to conduct the experiment -- but not the main
problem, which is whether and how to change bindings that existed in
Emacs since about forever.

Re: Suggested experimental test

[Philip Kaludercic]

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Tue, 23 Mar 2021 08:22:19 +0300
>> From: Jean Louis <bugs@gnu.support>
>> Cc: Lars Ingebrigtsen <larsi@gnus.org>, gregory@heytings.org,
>>  Eli Zaretskii <eliz@gnu.org>, Stefan Kangas <stefankangas@gmail.com>,
>>  emacs-devel@gnu.org
>> 
>> That way experiments go in parallel not disturbing the default key
>> bindings and users aware or willing to participate may do so.
>
> That just delays the dispute to the point when we want to consider
> making some of the bindings the default.  So it basically may solve a
> secondary problem -- how to conduct the experiment -- but not the main
> problem, which is whether and how to change bindings that existed in
> Emacs since about forever.

Forgive me for asking, maybe I'm missing something, but why should the
changes be made default?

Isn't the idea of providing a theme to change the behaviour that users
can enable or disable them easily, without the defaults having to change?

-- 
	Philip K.

Re: Suggested experimental test

[Eli Zaretskii]

> From: Philip Kaludercic <philipk@posteo.net>
> Cc: Jean Louis <bugs@gnu.support>,  larsi@gnus.org,  gregory@heytings.org,
>   emacs-devel@gnu.org,  stefankangas@gmail.com,  dgutov@yandex.ru
> Date: Tue, 23 Mar 2021 13:28:19 +0100
> 
> > That just delays the dispute to the point when we want to consider
> > making some of the bindings the default.  So it basically may solve a
> > secondary problem -- how to conduct the experiment -- but not the main
> > problem, which is whether and how to change bindings that existed in
> > Emacs since about forever.
> 
> Forgive me for asking, maybe I'm missing something, but why should the
> changes be made default?

The context was the discussion of changes in key bindings.  If they
are not changed by default, how else can such a change be made?

> Isn't the idea of providing a theme to change the behaviour that users
> can enable or disable them easily, without the defaults having to change?

The theme suggestion was a proposal to conduct an experiment without
interfering with those who want no part in the experiment.  But
eventually, the intent is to change the default behavior, because
rebinding any key to any command is already possible, and nothing
prevents users from doing that in their private init files.  So having
a non-default theme that makes a bunch of such rebindings makes little
sense to me.

Re: Suggested experimental test

[Dmitry Gutov]

On 23.03.2021 14:41, Eli Zaretskii wrote:

>> Isn't the idea of providing a theme to change the behaviour that users
>> can enable or disable them easily, without the defaults having to change?
> 
> The theme suggestion was a proposal to conduct an experiment without
> interfering with those who want no part in the experiment.

It has another goal as well: to have bindings changed in a logical and 
consistent fashion.

Having find-file on both 'C-x C-f' and 'C-o' would make little sense to 
me, for example.

> But
> eventually, the intent is to change the default behavior, because
> rebinding any key to any command is already possible, and nothing
> prevents users from doing that in their private init files.  So having
> a non-default theme that makes a bunch of such rebindings makes little
> sense to me.

I think the above is more important than the goal of making it a default 
(which might or might not happen in 10 years or so, if we end up 
reaching some critical mass of users who dislike Emacs's historical 
bindings).

But even while the alternative keybindings theme is not the default, we 
would maintain it and keep it usable. Whenever we add something to the 
default set, we would consider adding a corresponding binding to that 
other theme, etc.

Having an alternative, well-considered set of bindings which new user 
can just toggle on and get comfortable should be valuable.

Re: Suggested experimental test

[Philip Kaludercic]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 23.03.2021 14:41, Eli Zaretskii wrote:

>> But eventually, the intent is to change the default behavior, because
>> rebinding any key to any command is already possible, and nothing
>> prevents users from doing that in their private init files.  So
>> having a non-default theme that makes a bunch of such rebindings
>> makes little sense to me.
>
> I think the above is more important than the goal of making it a
> default (which might or might not happen in 10 years or so, if we end
> up reaching some critical mass of users who dislike Emacs's historical 
> bindings).
>
> But even while the alternative keybindings theme is not the default,
> we would maintain it and keep it usable. Whenever we add something to
> the default set, we would consider adding a corresponding binding to
> that other theme, etc.

You mean new default commands, right?

> Having an alternative, well-considered set of bindings which new user
> can just toggle on and get comfortable should be valuable.

Yes, this was my understanding too. Ideally, the splash screen could
instruct new users how to change the UX theme, making it easier to get
comfortable.

-- 
	Philip K.

Re: Suggested experimental test

[Dmitry Gutov]

On 23.03.2021 15:27, Philip Kaludercic wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 23.03.2021 14:41, Eli Zaretskii wrote:
> 
>>> But eventually, the intent is to change the default behavior, because
>>> rebinding any key to any command is already possible, and nothing
>>> prevents users from doing that in their private init files.  So
>>> having a non-default theme that makes a bunch of such rebindings
>>> makes little sense to me.
>>
>> I think the above is more important than the goal of making it a
>> default (which might or might not happen in 10 years or so, if we end
>> up reaching some critical mass of users who dislike Emacs's historical
>> bindings).
>>
>> But even while the alternative keybindings theme is not the default,
>> we would maintain it and keep it usable. Whenever we add something to
>> the default set, we would consider adding a corresponding binding to
>> that other theme, etc.
> 
> You mean new default commands, right?

Yup.

Or other changes in the default set (moves, removals, replacements).

>> Having an alternative, well-considered set of bindings which new user
>> can just toggle on and get comfortable should be valuable.
> 
> Yes, this was my understanding too. Ideally, the splash screen could
> instruct new users how to change the UX theme, making it easier to get
> comfortable.

Some initial screen could do that, yes. Or at least we would tell about 
in the same places we mention cua-mode now.

Re: Suggested experimental test

[Eli Zaretskii]

> Cc: bugs@gnu.support, larsi@gnus.org, gregory@heytings.org,
>  emacs-devel@gnu.org, stefankangas@gmail.com
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 23 Mar 2021 15:09:50 +0200
> 
> Having an alternative, well-considered set of bindings which new user 
> can just toggle on and get comfortable should be valuable.

I doubt that, because we already tried that in CUA mode.  That one
actually was better posed to succeed, since its key bindings weren't
invented "out of thin air", but use widely accepted conventions.

That said, I have no objection to having non-default sets of key
bindings that users can turn on at will.  I was only responding to
what I thought was a proposal for conducting such experiments with the
eventual goal of making the bindings the default.

Re: Suggested experimental test

[Dmitry Gutov]

On 23.03.2021 15:54, Eli Zaretskii wrote:
>> Cc: bugs@gnu.support, larsi@gnus.org, gregory@heytings.org,
>>   emacs-devel@gnu.org, stefankangas@gmail.com
>> From: Dmitry Gutov <dgutov@yandex.ru>
>> Date: Tue, 23 Mar 2021 15:09:50 +0200
>>
>> Having an alternative, well-considered set of bindings which new user
>> can just toggle on and get comfortable should be valuable.
> 
> I doubt that, because we already tried that in CUA mode.  That one
> actually was better posed to succeed, since its key bindings weren't
> invented "out of thin air", but use widely accepted conventions.

CUA mode is only halfway there (if that). It doesn't reach the other 
common bindings, such as C-o for 'open file', C-n for 'new file', C-s 
for 'save file', C-f for 'search forward', C-y for 'redo', C-a for 
'select all'.

And its dispatch is timer-based, as Yuri reminds us. Which is a constant 
source of subtle annoyance which makes its use untenable long-term, 
IMHO. Only as a set of training wheels for new users, but I wonder if 
even that is a good role for it, given that those annoyances create a 
worse impression of the editor for users who enabled it.

> That said, I have no objection to having non-default sets of key
> bindings that users can turn on at will.  I was only responding to
> what I thought was a proposal for conducting such experiments with the
> eventual goal of making the bindings the default.

You said "having a non-default theme that makes a bunch of such 
rebindings makes little sense to me". I have hopefully addressed that.

And as for making such a theme a default, that's far off enough in the 
future not to worry about it much. But OTOH if we manage to make this 
"keybinding theme" approach work, even a switch to a different theme by 
default won't have to be too painful for the many existing users, since 
they would be able to turn on the "Emacs classic" keybinding theme, 
which we will surely create by then.

Re: Suggested experimental test

[chad]

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

On Tue, Mar 23, 2021 at 7:05 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Cc: bugs@gnu.support, larsi@gnus.org, gregory@heytings.org,
> >  emacs-devel@gnu.org, stefankangas@gmail.com
> > From: Dmitry Gutov <dgutov@yandex.ru>
> > Date: Tue, 23 Mar 2021 15:09:50 +0200
> >
> > Having an alternative, well-considered set of bindings which new user
> > can just toggle on and get comfortable should be valuable.
>
> I doubt that, because we already tried that in CUA mode.  That one
> actually was better posed to succeed, since its key bindings weren't
> invented "out of thin air", but use widely accepted conventions.
>

FWIW, over the years, I have seen several people who were very interested
in CUA mode who eventually turned it off due to it working "most but not
all of the time". This experience is pretty old, but internet searches show
similar feedback continuing since then. In practice, it means that users
who might have recommended cua-mode instead anti-recommend it.

When I've looked at it for other people, it seems like an issue that can't
actually be fixed, because the people who care enough to change the
bindings need them to be absolutely %100 reliable, which the time-based
approach isn't. I'm afraid that I can't help more than that -- emacs'
default bindings are far more ingrained for me than the CUA bindings (a
fact that I learned to accept long ago when moving away from emacs' `C-w'
and `C-q').

This is all to say: cua-mode has its own set of problems as an example.
~Chad

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

Re: Suggested experimental test

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-03-23 15:42]:
> The context was the discussion of changes in key bindings.  If they
> are not changed by default, how else can such a change be made?

As a theme in Emacs Development it would allow easier testing without
changing defaults. But it includes Emacs Development only.

Another way could be as extension or package in ELPA, making a package
and publishing it in ELPA as:

experiment-001 -- would allow many Emacs users to test it, not just
developers. Package could supply feedback function. By pointing out
that it is experiment that needs user feedback, the results would be
richer with more facts from various Emacs versions as well.

That would be also one good way to ask users polls without influencing
their Emacs version.

If results are useful for some users, than a non-experimenting package
can be made that can be obtained from ELPA.

If results are appear to be useful for very many users, that could
then lead to new versions of Emacs.

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

  > > The context was the discussion of changes in key bindings.  If they
  > > are not changed by default, how else can such a change be made?

  > As a theme in Emacs Development it would allow easier testing without
  > changing defaults. But it includes Emacs Development only.

  > Another way could be as extension or package in ELPA, making a package
  > and publishing it in ELPA as:

If the new bindings use commands that already exist, and
the change is limited to the key bindings,
the simplest way is to add a command to alter those bindings.

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

[Yuri Khan]

On Tue, 23 Mar 2021 at 05:45, Dmitry Gutov <dgutov@yandex.ru> wrote:

> I think something like this is only worthwhile if we were changing a
> whole bunch of bindings. Like not just C-o, but also C-n and C-s, to
> their "other software" counterparts.

More importantly, we should have a bulletproof way to move things off
C-x and C-c. The workaround we have in cua-mode is time-sensitive and,
depending on network lag, I regularly get false negatives (switching
buffers on ‘C-x →’ when I meant to cut and move right) and false
positives (copy and overwrite region on ‘C-c C-c >’ when I meant to
‘python-indent-shift-right’).

Re: Suggested experimental test

[Dmitry Gutov]

On 23.03.2021 08:12, Yuri Khan wrote:
> On Tue, 23 Mar 2021 at 05:45, Dmitry Gutov<dgutov@yandex.ru>  wrote:
> 
>> I think something like this is only worthwhile if we were changing a
>> whole bunch of bindings. Like not just C-o, but also C-n and C-s, to
>> their "other software" counterparts.
> More importantly, we should have a bulletproof way to move things off
> C-x and C-c. The workaround we have in cua-mode is time-sensitive and,
> depending on network lag, I regularly get false negatives (switching
> buffers on ‘C-x →’ when I meant to cut and move right) and false
> positives (copy and overwrite region on ‘C-c C-c >’ when I meant to
> ‘python-indent-shift-right’).

I think there are basically two directions:

- Find two other C-<char> prefix key combinations to move the main 
prefix keymaps to. C-d and C-e come to mind (basically all other keys 
that are situated closer to Ctrl or Caps on a qwerty keyboard are all 
taken up by popular bindings such as C-a "select all" or C-s "save file").

- Go all the way to VS Code/Atom/Notepad/etc approach and depopulate 
these prefix maps. And then use two modifiers at a time for the 
important commands/prefix maps which we still need to have bindings. For 
example, that would move 'C-x v' to 'C-M-g' and 'C-x C-i' to 'C-M-o', or 
similar (Emacs is a lot more keyboard-driven than the other editors in 
this example, so a lot of our commands don't have direct counterparts to 
look up bindings of, and we'll need to improvise).

Or maybe we could combine these both in some productive fashion.

Not sure if that's the response you were looking for. Personally, I'm 
content with only using a small part of foreign conventions in my Emacs 
bindings and not looking to switch away. But if we're going to devise a 
proper solution for newcomer-friendly bindings, I don't think we should 
stop at just the four that cua-mode changes.

Re: Suggested experimental test

[Yuri Khan]

On Thu, 25 Mar 2021 at 06:41, Dmitry Gutov <dgutov@yandex.ru> wrote:

> > we should have a bulletproof way to move things off
> > C-x and C-c.
>
> I think there are basically two directions:
>
> - Find two other C-<char> prefix key combinations to move the main
> prefix keymaps to. C-d and C-e come to mind (basically all other keys
> that are situated closer to Ctrl or Caps on a qwerty keyboard are all
> taken up by popular bindings such as C-a "select all" or C-s "save file").

What, being close to (left) Ctrl on a QWERTY is/was a consideration
when choosing C-x and C-c? This makes sense, as much as it does for
Undo/Cut/Copy/Paste.

> - Go all the way to VS Code/Atom/Notepad/etc approach and depopulate
> these prefix maps. And then use two modifiers at a time for the
> important commands/prefix maps which we still need to have bindings. For
> example, that would move 'C-x v' to 'C-M-g' and 'C-x C-i' to 'C-M-o', or
> similar.

In my personal bindings, I do prefer C-M-, C-S- and M-S- combinations
to sequences. (Also function keys and their C- and S- combinations.)

> Or maybe we could combine these both in some productive fashion.
>
> Not sure if that's the response you were looking for. Personally, I'm
> content with only using a small part of foreign conventions in my Emacs
> bindings and not looking to switch away. But if we're going to devise a
> proper solution for newcomer-friendly bindings, I don't think we should
> stop at just the four that cua-mode changes.

I’m way past the newcomer stage but I have not and am not going to
adopt Emacs as my desktop environment. And, for me, consistency across
the desktop is important. So I want C-x for cut and C-c for copy, and
I might like to move their traditional maps to any of C-[abdefimnop;']
or maybe <menu> (because my keyboard has working arrow keys and Home
and End at positions that do not require me to move my wrists so I
don’t get the traditionally quoted benefit from C-[fbnp]).

But, while I can (mostly) rebind something to ctl-x-map, in order to
move things off C-c, I’d have to basically copy every mode’s map into
my configuration and replace C-c with <menu>. Alternatively, I could
use some key translation mechanism to pretend <menu> produces C-c and
C-c produces <XF86Copy> or some such, but I’m not sure if that would
also affect sequences where C-c is not the first key (and I’d probably
like it not to).

Re: Suggested experimental test

[Dmitry Gutov]

On 25.03.2021 08:12, Yuri Khan wrote:
> On Thu, 25 Mar 2021 at 06:41, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>>> we should have a bulletproof way to move things off
>>> C-x and C-c.
>>
>> I think there are basically two directions:
>>
>> - Find two other C-<char> prefix key combinations to move the main
>> prefix keymaps to. C-d and C-e come to mind (basically all other keys
>> that are situated closer to Ctrl or Caps on a qwerty keyboard are all
>> taken up by popular bindings such as C-a "select all" or C-s "save file").
> 
> What, being close to (left) Ctrl on a QWERTY is/was a consideration
> when choosing C-x and C-c? This makes sense, as much as it does for
> Undo/Cut/Copy/Paste.

It surely needs to be comfortable to press with one hand.

>> - Go all the way to VS Code/Atom/Notepad/etc approach and depopulate
>> these prefix maps. And then use two modifiers at a time for the
>> important commands/prefix maps which we still need to have bindings. For
>> example, that would move 'C-x v' to 'C-M-g' and 'C-x C-i' to 'C-M-o', or
>> similar.
> 
> In my personal bindings, I do prefer C-M-, C-S- and M-S- combinations
> to sequences. (Also function keys and their C- and S- combinations.)

Not my preference, but that seems to reflect the bindings I see "out 
there". So you could be a good person to gauge to alternative bindings 
theme.

> But, while I can (mostly) rebind something to ctl-x-map, in order to
> move things off C-c, I’d have to basically copy every mode’s map into
> my configuration and replace C-c with <menu>. Alternatively, I could
> use some key translation mechanism to pretend <menu> produces C-c and
> C-c produces <XF86Copy> or some such, but I’m not sure if that would
> also affect sequences where C-c is not the first key (and I’d probably
> like it not to).

Yeah, C-x seems easier, because at least built-in code uses ctl-x-map 
(which you can move wholesale) and 3rd party packages can be asked to.

But C-c doesn't have a dedicated keymap, so solving this seems like the 
first step. What could we do?

   (kbd (format "%s C-l" ctl-c-key-sequence) 'some-command)

?

Or maybe create a bogus ctrl-c keymap and then make sure to refer to its 
binding with something like

   (kbd "[C-c] C-l" 'some-command)

...I'm not sure, ideas welcome. Something backward-compatible would be 
ideal.

Re: Suggested experimental test

[Basil L. Contovounesios]

Dmitry Gutov <dgutov@yandex.ru> writes:

> But C-c doesn't have a dedicated keymap

It does: mode-specific-map.  See 'C-c' (heh) in the Elisp manual index.

-- 
Basil

Re: Suggested experimental test

[Dmitry Gutov]

On 25.03.2021 16:30, Basil L. Contovounesios wrote:
> Dmitry Gutov<dgutov@yandex.ru>  writes:
> 
>> But C-c doesn't have a dedicated keymap
> It does: mode-specific-map.  See 'C-c' (heh) in the Elisp manual index.

Oh, nice. Any idea how to take advantage of it for the purpose discussed?

If I compare the outputs of 'C-h v mode-specific-map' and 'C-c C-h', the 
former corresponds only to the "Global Bindings" section of the latter.

But all the Minor Mode Bindings and Major Mode Bindings apparently don't 
use it. Not in my configuration/session, at least.

Also, the manual says "its name provides useful information about ‘C-c’ 
in the output of ‘C-h b’ (‘display-bindings’)", but I don't see that.

Re: Suggested experimental test

[Yuri Khan]

On Thu, 25 Mar 2021 at 21:30, Basil L. Contovounesios <contovob@tcd.ie> wrote:

> > But C-c doesn't have a dedicated keymap
>
> It does: mode-specific-map.  See 'C-c' (heh) in the Elisp manual index.

Yeah, there is an empty keymap named ‘mode-specific-command-prefix’
that is globally bound to C-c. As far as I can tell, that keymap’s
sole purpose in life is making sure that ‘<f1> b’ lists “C-c
mode-specific-command-prefix” somewhere way down under “Global
bindings”.

None of the modes seem to bind anything in that map, and in fact that
would be counterproductive to them being modes.

Re: Suggested experimental test

[Yuri Khan]

On Thu, 25 Mar 2021 at 20:20, Dmitry Gutov <dgutov@yandex.ru> wrote:

> But C-c doesn't have a dedicated keymap, so solving this seems like the
> first step. What could we do?
>
>    (kbd (format "%s C-l" ctl-c-key-sequence) 'some-command)
>
> Or maybe create a bogus ctrl-c keymap and then make sure to refer to its
> binding with something like
>
>    (kbd "[C-c] C-l" 'some-command)
>
> ...I'm not sure, ideas welcome.

How about this:

* Introduce a virtual key, let’s call it <mode-specific>. Let’s
specifically *not* name it <key-formerly-known-as-C-c>.
* Have all modes use that as the prefix key for mode-specific
commands, instead of C-c.
* In the default configuration, translate C-c to <mode-specific>.

Proof of concept:

    $ emacs -Q

    (define-key help-mode-map (kbd "<mode-specific> <mode-specific>")
                #'help-follow-symbol)
    (define-key help-mode-map (kbd "<mode-specific> C-b") #'help-go-back)
    (define-key help-mode-map (kbd "<mode-specific> C-f") #'help-go-forward)
    (define-key key-translation-map (kbd "<menu>") (kbd "<mode-specific>"))
    ;; C-x C-e all of the above

    (define-key help-mode-map (kbd "C-c C-c") nil)
    (define-key help-mode-map (kbd "C-c C-b") nil)
    (define-key help-mode-map (kbd "C-c C-f") nil)
    (define-key help-mode-map (kbd "C-c") nil)
    ;; should be unneeded after all modes convert

    (global-set-key (kbd "C-c") #'copy-region-as-kill)
    (global-set-key (kbd "C-v") #'cua-paste)

    <f1> m C-x o
    ;; I’m now in a *Help* buffer listing currently enabled modes

    <f1> b
    ;; I’m now in a *Help* buffer listing bindings

    <menu> C-b
    ;; I’m back to modes

    <menu> C-f
    ;; I’m back to bindings

    S-<down> S-<down> S-<down> C-c
    C-x o C-v
    ;; I have a copy of a few lines from *Help* in my *scratch*

> Something backward-compatible would be
> ideal.

Hm, I don’t know. The above is definitely not backward-compatible. It
assumes a full conversion in Emacs and full cooperation from
third-party mode authors.

Re: Suggested experimental test

[Stefan Monnier]

> * Introduce a virtual key, let’s call it <mode-specific>. Let’s
> specifically *not* name it <key-formerly-known-as-C-c>.
> * Have all modes use that as the prefix key for mode-specific
> commands, instead of C-c.
> * In the default configuration, translate C-c to <mode-specific>.

Part of the difficulty in making key binding schemes more flexible is
that the keys you'll want to use within <mode-specific> will tend to
depend on the key to which <mode-specific> is bound.

E.g. if it's bound to `C-c` it's fairly convenient to have bindings
within it of the form `C-<letter>`, but if it's bound to `c` instead
(assuming a a modal key-binding scheme like vi) then using `C-<letter>`
within it is much less convenient.


        Stefan

Re: Suggested experimental test

[Dmitry Gutov]

On 25.03.2021 23:11, Stefan Monnier wrote:
> E.g. if it's bound to `C-c` it's fairly convenient to have bindings
> within it of the form `C-<letter>`, but if it's bound to `c` instead
> (assuming a a modal key-binding scheme like vi) then using `C-<letter>`
> within it is much less convenient.

Interesting example. I wanted to say nobody will bind it to 'c', but 
some people might decide to bind it to M-c instead.

Here's a thought: let's invent an extension of the kbd syntax which will 
allow us to specify a modifier indirectly based on an entry in 
key-translation-map. Like:

   (kbd "<mode-specific> <mode-specific-modifier>-c")

Even more backward-incompatible, but okay. But what to do if 
<mode-specific> has no modifiers, like <menu> in Yuri's example? 
Translate '<mode-specific-modifier>-c' to just 'c'? What happens to any 
other simple 'c' entry in that keymap? Do we "flip" it to, say, 'C-c'?

What happens if the user decides to bind <mode-specific> to 'C-d', and 
in my third-party package I choose 'C-c C-d' as a command binding? That 
seems like a popular one, inspired by SLIME. *And* I have another 
binding in there, 'C-c C-c'. Going along with the new feature, I'll 
write the first one like '<mode-specific> C-d' and the second one 
'<mode-specific> <mode-specific>'... right? That's a conflict. The only 
way of resolving such conflicts I can imagine is to also "flip" any 
'C-d' written verbatim and not as <mode-specific> back to C-c, the 
default <mode-specific> binding, when <mode-specific> is bound to 'C-d'. 
Which seems both tricky to implement and punishing to a lot of existing 
code that the user might try to use.

So maybe we should limit the scope of the effort and not try to solve 
all the inefficiencies, or we'll never make progress on this issue 
(after all, the main audience of this change are people who aren't so 
fond of key sequences; or at least not yet).

But better ideas welcome, of course.

Re: Suggested experimental test

[Stefan Kangas]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.03.2021 23:11, Stefan Monnier wrote:
>> E.g. if it's bound to `C-c` it's fairly convenient to have bindings
>> within it of the form `C-<letter>`, but if it's bound to `c` instead
>> (assuming a a modal key-binding scheme like vi) then using `C-<letter>`
>> within it is much less convenient.
>
> Interesting example. I wanted to say nobody will bind it to 'c', but
> some people might decide to bind it to M-c instead.
>
> Here's a thought: let's invent an extension of the kbd syntax which will
> allow us to specify a modifier indirectly based on an entry in
> key-translation-map. Like:
>
>    (kbd "<mode-specific> <mode-specific-modifier>-c")
>
> Even more backward-incompatible, but okay. But what to do if
> <mode-specific> has no modifiers, like <menu> in Yuri's example?
> Translate '<mode-specific-modifier>-c' to just 'c'? What happens to any
> other simple 'c' entry in that keymap? Do we "flip" it to, say, 'C-c'?

How about something like:

    (mode-kbd "k")         ; C-c k
    (mode-kbd "mod k")     ; C-c C-k
    (mode-kbd "mod2 k")    ; C-c M-k
    (mode-kbd "mod3 k")    ; C-c S-k

Then mod, mod2 and mod3 could be set to use whatever modifier you want.
And mode-kbd would use the correct prefix.

(BTW, it would be even nicer if we could evaluate such a form on
key lookup.)

Re: Suggested experimental test

[Dmitry Gutov]

On 26.03.2021 12:34, Stefan Kangas wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> On 25.03.2021 23:11, Stefan Monnier wrote:
>>> E.g. if it's bound to `C-c` it's fairly convenient to have bindings
>>> within it of the form `C-<letter>`, but if it's bound to `c` instead
>>> (assuming a a modal key-binding scheme like vi) then using `C-<letter>`
>>> within it is much less convenient.
>>
>> Interesting example. I wanted to say nobody will bind it to 'c', but
>> some people might decide to bind it to M-c instead.
>>
>> Here's a thought: let's invent an extension of the kbd syntax which will
>> allow us to specify a modifier indirectly based on an entry in
>> key-translation-map. Like:
>>
>>     (kbd "<mode-specific> <mode-specific-modifier>-c")
>>
>> Even more backward-incompatible, but okay. But what to do if
>> <mode-specific> has no modifiers, like <menu> in Yuri's example?
>> Translate '<mode-specific-modifier>-c' to just 'c'? What happens to any
>> other simple 'c' entry in that keymap? Do we "flip" it to, say, 'C-c'?
> 
> How about something like:
> 
>      (mode-kbd "k")         ; C-c k
>      (mode-kbd "mod k")     ; C-c C-k
>      (mode-kbd "mod2 k")    ; C-c M-k
>      (mode-kbd "mod3 k")    ; C-c S-k
> 
> Then mod, mod2 and mod3 could be set to use whatever modifier you want.
> And mode-kbd would use the correct prefix.

This looks nice and flexible, but probably doesn't address the essence 
of Stefan's complaint. Example:

If mode-specific-modifier is 'C-c', 'C-c C-k' seems like an easy-to-hit 
sequence, suitable for a frequently-used command.

If mode-specific-modifier is <menu> or <f2>, '<menu> C-k' is less easy 
to hit than '<menu> k', for example, and the latter binding might be 
preferable.

But the package author already has to make a choice between (mode-kbd 
"k") and (mode-kbd "mod k") for a given command without knowing 
mode-specific-modifier in advance.

> (BTW, it would be even nicer if we could evaluate such a form on
> key lookup.)

Yuri mentioned key-translation-map already. Perhaps it or a similar new 
mechanism could be employed.

Re: Suggested experimental test

[Dmitry Gutov]

On 25.03.2021 21:30, Yuri Khan wrote:
> On Thu, 25 Mar 2021 at 20:20, Dmitry Gutov <dgutov@yandex.ru> wrote:
> 
>> But C-c doesn't have a dedicated keymap, so solving this seems like the
>> first step. What could we do?
>>
>>     (kbd (format "%s C-l" ctl-c-key-sequence) 'some-command)
>>
>> Or maybe create a bogus ctrl-c keymap and then make sure to refer to its
>> binding with something like
>>
>>     (kbd "[C-c] C-l" 'some-command)
>>
>> ...I'm not sure, ideas welcome.
> 
> How about this:
> 
> * Introduce a virtual key, let’s call it <mode-specific>. Let’s
> specifically *not* name it <key-formerly-known-as-C-c>.
> * Have all modes use that as the prefix key for mode-specific
> commands, instead of C-c.
> * In the default configuration, translate C-c to <mode-specific>.
> 
> Proof of concept:
> 
>      $ emacs -Q
> 
>      (define-key help-mode-map (kbd "<mode-specific> <mode-specific>")
>                  #'help-follow-symbol)
>      (define-key help-mode-map (kbd "<mode-specific> C-b") #'help-go-back)
>      (define-key help-mode-map (kbd "<mode-specific> C-f") #'help-go-forward)
>      (define-key key-translation-map (kbd "<menu>") (kbd "<mode-specific>"))
>      ;; C-x C-e all of the above
> 
>      (define-key help-mode-map (kbd "C-c C-c") nil)
>      (define-key help-mode-map (kbd "C-c C-b") nil)
>      (define-key help-mode-map (kbd "C-c C-f") nil)
>      (define-key help-mode-map (kbd "C-c") nil)
>      ;; should be unneeded after all modes convert
> 
>      (global-set-key (kbd "C-c") #'copy-region-as-kill)
>      (global-set-key (kbd "C-v") #'cua-paste)
> 
>      <f1> m C-x o
>      ;; I’m now in a *Help* buffer listing currently enabled modes
> 
>      <f1> b
>      ;; I’m now in a *Help* buffer listing bindings
> 
>      <menu> C-b
>      ;; I’m back to modes
> 
>      <menu> C-f
>      ;; I’m back to bindings
> 
>      S-<down> S-<down> S-<down> C-c
>      C-x o C-v
>      ;; I have a copy of a few lines from *Help* in my *scratch*

This is a solid proposal. We can go with it, especially if we don't mind 
the key sequence ergonomics in keymaps, as well as backward incompatibility.

Perhaps we could instead do something with key-translation-map (or one 
of its friends) that works on existing keymaps?

The use of 'menu-item' allows us to filter based on whether the key is 
first in the sequence:

(define-key key-translation-map (kbd "<menu>") (kbd "C-c"))
(define-key key-translation-map (kbd "C-c")
   `(menu-item "" ,(kbd "<C-c-translated>")
               :filter my--head-of-sequence-p))
(global-set-key (kbd "<C-c-translated>") 'kill-ring-save)

(defun my--head-of-sequence-p (cmd)
   (if (> (length (this-command-keys-vector)) 1)
       (kbd "C-c")
     cmd))

This seems backward-compatible enough, but the main downside is that 
Emacs now says 'C-c-' in the echo area when you hit <menu>. Which must 
be confusing to the main target audience.

Re: Suggested experimental test

[Stefan Monnier]

> Perhaps we could instead do something with key-translation-map (or one of
> its friends) that works on existing keymaps?
>
> The use of 'menu-item' allows us to filter based on whether the key is first
> in the sequence:
>
> (define-key key-translation-map (kbd "<menu>") (kbd "C-c"))
> (define-key key-translation-map (kbd "C-c")
>   `(menu-item "" ,(kbd "<C-c-translated>")
>               :filter my--head-of-sequence-p))
> (global-set-key (kbd "<C-c-translated>") 'kill-ring-save)

While we can use such tricks, I think what we really want is to
abstract the keymap API such that we can provide keymaps whose elements
are computed dynamically.

There'd need to be at least 2 methods: `lookup-key`, and `map-keymap`,
and adding `where-is` would probably allow better behaviors (but could
introduce other problems given the way where-is currently works).

One application is to create a keymap (on function-key-map) that remaps
all the events of the form "modifiers + mouse-4" to "same-modifiers +
scroll-up".

Another would be a keymap that binds the same keys as some other keymap
except it requires some additional modifier or it removes a modifier, or
it capitalizes all the letters, or it transcribes all the cyrillic
letters to their "equivalent" ASCII, ...
We can already perform similar remappings via `key-translation-map` or
`function-key-map`, but these apply everywhere whereas if we could do them
inside a normal "key binding" keymap then it could be made to apply only
to bindings with a particular prefix.



        Stefan

Re: Suggested experimental test

[Dmitry Gutov]

Hi Stefan,

On 27.03.2021 02:02, Stefan Monnier wrote:
> While we can use such tricks, I think what we really want is to
> abstract the keymap API such that we can provide keymaps whose elements
> are computed dynamically.
> 
> There'd need to be at least 2 methods: `lookup-key`, and `map-keymap`,
> and adding `where-is` would probably allow better behaviors (but could
> introduce other problems given the way where-is currently works).
> 
> One application is to create a keymap (on function-key-map) that remaps
> all the events of the form "modifiers + mouse-4" to "same-modifiers +
> scroll-up".
> 
> Another would be a keymap that binds the same keys as some other keymap
> except it requires some additional modifier or it removes a modifier, or
> it capitalizes all the letters, or it transcribes all the cyrillic
> letters to their "equivalent" ASCII, ...

Could you give an example of how this facility will be used? Modes will 
be returning "generic" keymaps by using (mode-local-kbd "...") as Stefan 
K suggested?

Will easy-mmode-define-keymap return such keymaps? Or will the keymap 
values actually have the same structure, but behave differently because 
of augmented lookup-key, map-keymap, etc?

Re: Suggested experimental test

[Gregory Heytings]

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

That's unfortunate, but I see your point.  A few voices who complain 
loudly without even trying things are, alas, enough to prevent progress.

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

Thank you, Lars.

Re: Suggested experimental test

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> That's unfortunate, but I see your point.  A few voices who complain
> loudly without even trying things are, alas, enough to prevent
> progress.

Excessive volume does not influence anything (in the direction the
voices want to go).  At least not for me; quite the opposite.

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

Re: Suggested experimental test

[Alfred M. Szmidt]

   Excessive volume does not influence anything (in the direction the
   voices want to go).  At least not for me; quite the opposite.

If you are going to ignore input because you get input, why bother
with these "experiments" at all?

Re: Suggested experimental test

[Thierry Volpiatto]

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


Eli Zaretskii <eliz@gnu.org> writes:

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

Same here.

Here another use case (C-o is not == to C-e RET):

(setq fill-column 70)
(auto-fill-mode 1)

for some reasons you want to add fooooo word at eol 001 and insert a new
line between 001 and 002.

;; 001 aaaaa aaaaaa aaaaaaa aaaaaaa aaaaaaa aaaaaaa aaaaaaa aaaaaaa
;; 002 aaaaaaa aaaaaaa aaaaaaaaa aaaaaaaaa aaaaaaaaa aaaaaa aaaaa aaaaa

to endup with this:

;; 001 aaaaa aaaaaa aaaaaaa aaaaaaa aaaaaaa aaaaaaa aaaaaaa aaaaaaa fooooo

;; 002 aaaaaaa aaaaaaa aaaaaaaaa aaaaaaaaa aaaaaaaaa aaaaaa aaaaa aaaaa

Thanks to C-o C-n, otherwise you have to C-n C-a RET C-p after typing fooooo.


-- 
Thierry

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

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: gregory@heytings.org,  emacs-devel@gnu.org,  Stephan.Mueller@microsoft.com
> Date: Mon, 22 Mar 2021 20:13:49 +0100
> 
> 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.

That's true.  I use C-o in those cases as well.

> Perhaps the doc string of `RET' (i.e., `newline-and-indent' in most
> modes) should mention (and link to) to `C-o'?

I don't see why not.

Re: Suggested experimental test

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Perhaps the doc string of `RET' (i.e., `newline-and-indent' in most
>> modes) should mention (and link to) to `C-o'?
>
> I don't see why not.

Now done.

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

Re: Suggested experimental test

[Stefan Monnier]

>>> Perhaps the doc string of `RET' (i.e., `newline-and-indent' in most
>>> modes) should mention (and link to) to `C-o'?
>> I don't see why not.

Maybe because it already says:

    To just insert a newline, use \\[electric-indent-just-newline].


-- Stefan

Re: Suggested experimental test

[Lars Ingebrigtsen]

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

> Maybe because it already says:
>
>     To just insert a newline, use \\[electric-indent-just-newline].

Not here (in Emacs 28)...

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

Re: Suggested experimental test

[Stefan Monnier]

Lars Ingebrigtsen [2021-03-22 20:52:19] wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>> Maybe because it already says:
>>     To just insert a newline, use \\[electric-indent-just-newline].
> Not here (in Emacs 28)...

I guess this is a misunderstanding coming from:

    Perhaps the doc string of `RET' (i.e., `newline-and-indent' in most
    modes) should mention (and link to) to `C-o'?

RET is supposed to be bound to `newline` by default, pretty
much everywhere.  There are many modes which still bind RET to
`newline-and-indent`, but that's a historical accident that we should
fix because it disregards the user's choice to enable or disable
`electric-indent(-local)-mode`.

The docstring of `newline` (the thing bound to RET by default, AFAIC)
does include the line above, AFAICT.  I don't see a string need for
`newline-and-indent` to point to something else (like `open-line`) since
this is a command which should basically never be bound except by an
explicit choice of the end-user.


        Stefan

Re: Suggested experimental test

[Lars Ingebrigtsen]

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

> I guess this is a misunderstanding coming from:
>
>     Perhaps the doc string of `RET' (i.e., `newline-and-indent' in most
>     modes) should mention (and link to) to `C-o'?
>
> RET is supposed to be bound to `newline` by default, pretty
> much everywhere.  There are many modes which still bind RET to
> `newline-and-indent`, but that's a historical accident that we should
> fix because it disregards the user's choice to enable or disable
> `electric-indent(-local)-mode`.

And I had a

(global-set-key "\C-m" 'newline-and-indent)

at 3% in my .emacs file, which makes about 15 years old, I think, and I
had no idea that it was there.

> The docstring of `newline` (the thing bound to RET by default, AFAIC)
> does include the line above, AFAICT.  I don't see a string need for
> `newline-and-indent` to point to something else (like `open-line`) since
> this is a command which should basically never be bound except by an
> explicit choice of the end-user.

This end user had no recollection of doing so, so I think it still makes
sense to point to `C-o' 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>
> Cc: Eli Zaretskii <eliz@gnu.org>,  gregory@heytings.org,
>   Stephan.Mueller@microsoft.com,  emacs-devel@gnu.org
> Date: Mon, 22 Mar 2021 22:04:05 +0100
> 
> > RET is supposed to be bound to `newline` by default, pretty
> > much everywhere.  There are many modes which still bind RET to
> > `newline-and-indent`, but that's a historical accident that we should
> > fix because it disregards the user's choice to enable or disable
> > `electric-indent(-local)-mode`.
> 
> And I had a
> 
> (global-set-key "\C-m" 'newline-and-indent)
> 
> at 3% in my .emacs file, which makes about 15 years old, I think, and I
> had no idea that it was there.

I think this is because originally C-j was bound to newline-and-indent
(and RET to newline).  newline-and-indent is very handy in editing in
PL modes, but keyboards with a separate LFD key are long gone.  So
when the modern keyboards became omnipresent, people tended to rebind
RET to newline-and-indent, so that (a) that could invoke it easily and
naturally, and (b) to work similarly to the few other editors that had
such a functionality.

But then came the electric-indent thingy, and the simple world we had
then was lost forever...

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> ??? Including lisp-interaction-mode?

Heh.  

(1 2 |3 4)

and C-j in *scratch* gives me

(1 2 
2
3 4)

Which is kinda sorta natural (it evalued 2 and inserted it, and then did
a newline), but that sure is quirky, and is quite removed from "just
insert a newline".

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

>> ??? Including lisp-interaction-mode?
>
> Heh.  
>
> (1 2 |3 4)
>
> and C-j in *scratch* gives me

Oops, never mind -- C-j in that mode is `eval-print-last-sexp', which is
a totally different 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>
> Cc: Stephan.Mueller@microsoft.com,  yandros@gmail.com,
>   gregory@heytings.org,  Stefan Monnier <monnier@iro.umontreal.ca>,
>   emacs-devel@gnu.org
> Date: Mon, 22 Mar 2021 21:16:04 +0100
> 
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> >> ??? Including lisp-interaction-mode?
> >
> > Heh.  
> >
> > (1 2 |3 4)
> >
> > and C-j in *scratch* gives me
> 
> Oops, never mind -- C-j in that mode is `eval-print-last-sexp', which is
> a totally different thing.

Exactly my point.  Thus, "C-o C-n" is much more reliable.

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: yandros@gmail.com,  larsi@gnus.org,  emacs-devel@gnu.org,
>   gregory@heytings.org,  Stephan.Mueller@microsoft.com
> Date: Mon, 22 Mar 2021 16:49:26 -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?
> 
> lisp-interaction-mode is a weird beast, indeed.

But it is very popular, and is the first thing a user faces when he or
she starts Emacs.

Remember, this was the answer to the question "why not use C-j instead
of C-o with or without C-n?"

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

[Gregory Heytings]

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

Why should a control key must be reserved forever for that very specific 
purpose, and for that very specific purpose only, in the default Emacs 
bindings?  That's something that could be moved on, say, M-RET (and 
possibly improved).

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Mon, 22 Mar 2021 20:22:36 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: Lars Ingebrigtsen <larsi@gnus.org>, emacs-devel@gnu.org, 
>     Stephan.Mueller@microsoft.com
> 
> >>> 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.
> 
> Why should a control key must be reserved forever for that very specific 
> purpose, and for that very specific purpose only, in the default Emacs 
> bindings?

Opening an empty line is a very useful editing primitive, not unlike
going to the next line with RET.  Trying to change that will always
cause staunch resistance, especially when the purpose for which this
is done is vague and not perceived as important enough by enough
people.

Re: Suggested experimental test

[Gregory Heytings]

>>>>> 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.
>>
>> Why should a control key must be reserved forever for that very 
>> specific purpose, and for that very specific purpose only, in the 
>> default Emacs bindings?
>
> Opening an empty line is a very useful editing primitive, not unlike 
> going to the next line with RET.
>

I'd bet it is useful, as it is, only for 0.5% of Emacs users, perhaps even 
less.  No other editor I know has that feature.  And I'd bet that 90% of 
those 0.5% would be happier with a better open-line primitive, for example 
one which can be called when point is in the middle of a line, like "o" 
and "O" in vi.  The discussion showed that those who use it use it at BOL, 
and that it wasn't used alone, but as part of a sequence, for example C-a 
C-o or C-o C-n.  Nobody even mentioned the fact that open-line uses the 
fill-prefix and the left-margin.

As I said, an improved version of that command could for example be put on 
M-RET.  Here's an attempt:

(defun smart-open-line (&optional arg)
   (interactive "*p")
   (when (> arg 0)
     (beginning-of-line)
     (let ((p (point-marker)))
       (dotimes (_ arg) (insert "\n"))
       (goto-char p)))
   (when (< arg 0)
     (setq arg (abs arg))
     (beginning-of-line)
     (forward-line 1)
     (dotimes (_ arg) (insert "\n"))
     (forward-line -1)))
(global-set-key (kbd "M-RET") 'smart-open-line)

And even assuming that it is useful as it is, that doesn't answer the main 
question: why should a control character key be reserved forever for that 
very specific purpose, and for that very specific purpose only?

>
> Trying to change that will always cause staunch resistance, especially 
> when the purpose for which this is done is vague and not perceived as 
> important enough by enough people.
>

I could have clarified the purpose indeed, but the risk would have been to 
start two parallel discussions.

Re: Suggested experimental test

[Eli Zaretskii]

> Date: Tue, 23 Mar 2021 14:15:12 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> > Opening an empty line is a very useful editing primitive, not unlike 
> > going to the next line with RET.
> 
> I'd bet it is useful, as it is, only for 0.5% of Emacs users, perhaps even 
> less.  No other editor I know has that feature.

There's lot of good and useful stuff in Emacs that is not known to
"the crowd".  The right way of dealing with that is popularize it, not
delete it or make it harder or less convenient to use.  IMO, at least,
FWIW.

> And I'd bet that 90% of those 0.5% would be happier with a better
> open-line primitive, for example one which can be called when point
> is in the middle of a line, like "o" and "O" in vi.

You are welcome to add such a command, or find a clever way of
tweaking C-o to do that.  Then let's meet in, like, 20 years and see
how many percents of Emacs users like it or even know about it.

> The discussion showed that those who use it use it at BOL, 
> and that it wasn't used alone, but as part of a sequence, for example C-a 
> C-o or C-o C-n.  Nobody even mentioned the fact that open-line uses the 
> fill-prefix and the left-margin.

The discussion revealed more than that, but if you believe only 0.5%
find this command useful, how is that relevant?  If anything, it
reinforces my point above.

> And even assuming that it is useful as it is, that doesn't answer the main 
> question: why should a control character key be reserved forever for that 
> very specific purpose, and for that very specific purpose only?

I did try to answer that.

> > Trying to change that will always cause staunch resistance, especially 
> > when the purpose for which this is done is vague and not perceived as 
> > important enough by enough people.
> >
> 
> I could have clarified the purpose indeed, but the risk would have been to 
> start two parallel discussions.

Oh, I think I understand the reason.  It wasn't my mood that I was
describing, and you already know what I think about disputes about the
default key bindings.

Re: Suggested experimental test

[Bob Rogers]

   From: Gregory Heytings <gregory@heytings.org>
   Date: Tue, 23 Mar 2021 14:15:12 +0000

   > Opening an empty line is a very useful editing primitive, not unlike 
   > going to the next line with RET.

   I'd bet it is useful, as it is, only for 0.5% of Emacs users, perhaps
   even less.  No other editor I know has that feature . . .

True of oodles of Emacs features.

   And I'd bet that 90% of those 0.5% would be happier with a better
   open-line primitive, for example one which can be called when point
   is in the middle of a line . . .

I use it *mostly* in the middle of lines.  I think you'd lose that bet,
and probably the first as well.

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

Re: Suggested experimental test

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-03-23 17:17]:
> 
> > > > > > 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.
> > > 
> > > Why should a control key must be reserved forever for that very
> > > specific purpose, and for that very specific purpose only, in the
> > > default Emacs bindings?
> > 
> > Opening an empty line is a very useful editing primitive, not unlike
> > going to the next line with RET.
> > 
> 
> I'd bet it is useful, as it is, only for 0.5% of Emacs users, perhaps even
> less.  No other editor I know has that feature.

It cannot be argument here that other editors don't have features
built-in into Emacs. Those are known facts. Emacs is advanced
editor. Other editors simply don't have features of Emacs, unless they
are Emacs-like. But there are several Emacs-like editors: Edwin in MIT
Scheme, mg in OpenBSD, e3em, Zile, Zile on Guile, Emacs on Guile,
those are once that I use from time to time here, including as a
replacement for emacsclient (when something goes wrong). I have used
those multiple times during last month. More references:
https://wiki.gentoo.org/wiki/Project:Emacs/Emacs-like_editors

Now when you bet, I also bet you don't use Emacs-like editors, and I
am unsure how much you use Emacs beside those other editors you use. 

Another feature that many editors don't have is macro feature, editors
that do have macro features are always more advanced than
others. Because other editors do not have that feature, should we
disable macros in Emacs?

And then which other editors do you mention? Can we get the
disclosure? Your personal experiences should or could be reasoned to
understand those features you are referring to.

> And I'd bet that 90% of those 0.5% would be happier with a better
> open-line primitive, for example one which can be called when point
> is in the middle of a line, like "o" and "O" in vi.

I have mentioned my personal case and I said I would not like changing
default of C-o or getting habit with my personal customizations to
have C-o behave like O in vi. In relation to "o" in vi, I do not open
new line below the current one, but I agree that quicker key binding
would be nice. "o" from vi in Emacs is easily replaced with C-o as
instead of using the current line, then I would be simply using one
line below.

- "o" in vi -- frequently used, it opens new line after current line,
  regardless where is cursors located. In Emacs: go to one line below,
  beginning of line, press C-o

- "O" in vi - frequently used, opens new line before current line and
  places cursor at beginning of the line for writing, in Emacs, C-a
  C-o does the same.

Again, I would not like changing Emacs default behavior as for me who
works on various Emacs versions, including some older like few years
(OS never get updated on those computers) -- including using
Emacs-like editors frequently on remote VPS-es or remote computers,
sometimes on personal computer.

> The discussion showed that those who use it use it at BOL, and that
> it wasn't used alone, but as part of a sequence, for example C-a C-o
> or C-o C-n.  Nobody even mentioned the fact that open-line uses the
> fill-prefix and the left-margin.
> 
> As I said, an improved version of that command could for example be put on
> M-RET.  Here's an attempt:
> 
> (defun smart-open-line (&optional arg)
>   (interactive "*p")
>   (when (> arg 0)
>     (beginning-of-line)
>     (let ((p (point-marker)))
>       (dotimes (_ arg) (insert "\n"))
>       (goto-char p)))
>   (when (< arg 0)
>     (setq arg (abs arg))
>     (beginning-of-line)
>     (forward-fine 1)
>     (dotimes (_ arg) (insert "\n"))
>     (forward-line -1)))
> (global-set-key (kbd "M-RET") 'smart-open-line)

I have tried that version, it may be better than this one below that I
have ready -- but remember, I am not using it and do not want to
depend on it, that it does not change my finger work when I am working
on un-customized Emacs versions.

(defun my-C-o ()
  "Opens new line regardless where is cursor positioned."
  (interactive)
  (move-beginning-of-line nil)
  (open-line 1))

but I would like to ask not to bind M-RET to something by default in
Emacs, as it is used very efficiently in the package Hyperbole, and I
recommend that you try using Hyperbole to understand M-RET

> And even assuming that it is useful as it is, that doesn't answer
> the main question: why should a control character key be reserved
> forever for that very specific purpose, and for that very specific
> purpose only?

Because it is default for many years, learned and used by people and
adopted by other Emacs-like editors.

You can make then same question like why should C-a be used to jump to
beginning of the line or C-f to move one char forward. 

Nothing is forever.

Re: Suggested experimental test

[chad]

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

On Tue, Mar 23, 2021 at 1:10 AM Eli Zaretskii <eliz@gnu.org> wrote:

> > Why should a control key must be reserved forever for that very specific
> > purpose, and for that very specific purpose only, in the default Emacs
> > bindings?
>
> Opening an empty line is a very useful editing primitive, not unlike
> going to the next line with RET.  Trying to change that will always
> cause staunch resistance, especially when the purpose for which this
> is done is vague and not perceived as important enough by enough
> people.
>

Let's set aside the historical/hysterical impact for a second and look at
the input/effect table (which is why I asked for help understanding the
difference between "`C-o C-n' and `C-j' -- for which you all have my
thanks):

I take as given that "opening an empty line is a useful primitive", along
with "insert a newline at point" and also "insert a newline at point and
maybe do some context-specific DWIMish stuff". I think there's plenty of
support for this position, even for people who don't regularly perform all
of those operations. That gives us ~3 distinct solid effects (more on this
later).

On the input side, we sure want RET to be one of those ~3, and I think we
can agree that it's default should be the 2nd or maybe the 3rd effect. I
personally think that `C-j' is nicely intuitive for a newline-related
command, but that might be a sign of my age. M-RET is also very intuitive
for an alternative-newline command, seems to work in tty, and is used in a
large variety of other contexts (running the gamut from "Org mode in emacs"
to "editing inside spreadsheet cells"), so it seems like a solid choice.
From what I have seen, `C-o' has the main benefit that a large subset of
emacs users have been using it for a very long time, and the secondary
benefits of an mnemonic binding with "open line" and similarity (although
at least somewhat an uncanny-valley jarring one) to vi's 'o'. Both `C-j'
and `C-o' have a slight infelicity with being unused in other editing
environments, but that seems like a tertiary consideration to me.

To this, we can add  the historical wrinkles around electric-indent
recently brought up on this thread, which changed the C-j/RET pair from
newline/newline-and-indent to electric-newline-and-maybe-indent/newline --
note the functional swap. This thread contains some evidence of potential
issues left over from this change, i.e. mode bindings that seem like maybe
they should have been updated to match the "electric swap".

*Without getting into the conversation about changing defaults*, do we
generally agree that:
- These seem like the relevant operations
- These seem like the relevant potential keybinds (perhaps among others)
- That there is reason to investigate some of the bindings that are
currently in emacs-28 to see if they are confusing when combined with the
current "electric newline" bindings?

Thanks in advance,
~Chad

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

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.

Re: Suggested experimental test

[Jose A. Ortega Ruiz]

On Mon, Mar 22 2021, Lars Ingebrigtsen wrote:

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

I use C-o very, very often, to the point that i am sure that i will
pretty soon rebind it to its former meaning (and lose easy accesibility
to the new map, most possibly to my disadvantage, but old habits die
hard).  Something similar happened to me with M-g, if memory serves, but
admittedly here the fact that repeating it "will work" might ameliorate
my reaction.

Cheers,
jao
-- 
Sometimes I think we're alone in the universe, and sometimes I think we're
not. In either case, the idea is quite staggering.
 -Arthur C Clarke, writer (1917- )

Re: Suggested experimental test

[Sean Whitton]

Hello Gregory,

On Sun 21 Mar 2021 at 10:48AM GMT, Gregory Heytings wrote:

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

To be honest, changing C-o feels like changing C-y -- in fact, I
probably type C-o more often than I type C-y.

-- 
Sean Whitton

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