Concern about new binding.

Concern about new binding.

[Ergus]

Hi: 

In a recent commit I see that the C-x g binding was taken for
revert-buffer.

I suppose this should have been discussed previously, unless I don't
find the thread... but I have some concerns about this.

1) In general `C-x g` is used by magit; I know this is not a priority
(cause magit is an external package), but magit is a very popular
package.

2) In some threads before we have discussed that relative short
combinations must be reserved to maps in order to economize them... 

3) In spite of revert-buffer is a very useful command it is useless in
many conditions like when auto-revert-mode is enable... so maybe it
makes sense to bind it to something longer (ex: C-x g r)??

There are more commands that could be set in a map inside C-x g IMHO:
toggle-read-only
revert-buffer-with-fine-grain
something to enable/disable font-lock
  etc

This way instead of limiting; could open a big spot to set useful
commands. I understand that longer commands are harder to discover, but
hopefully we could have which-key in the next release? 

I hope I am writing this soon enough that the author could consider
revert this change maybe with something more "general" does it makes
sense??

Best,
Ergus.

Concern about new binding.

[Kévin Le Gouguec]

Ergus <spacibba@aol.com> writes:

> I suppose this should have been discussed previously, unless I don't
> find the thread...

See bug#46151.

IIUC the initial request was to have a way to revert shell output
buffers; somewhere along the way the usefulness of a global binding for
revert-buffer was brought up, various options were discussed, a decision
was taken, and here we are.

Re: Concern about new binding.

[Óscar Fuentes]

Kévin Le Gouguec <kevin.legouguec@gmail.com> writes:

> Ergus <spacibba@aol.com> writes:
>
>> I suppose this should have been discussed previously, unless I don't
>> find the thread...
>
> See bug#46151.
>
> IIUC the initial request was to have a way to revert shell output
> buffers; somewhere along the way the usefulness of a global binding for
> revert-buffer was brought up, various options were discussed, a decision
> was taken, and here we are.

The title of that bug report is "Set revert-buffer-function in shell
command output buffers", no hint about discussing global keybindings.

So the effective policy is that either one reads each and every message
in emacs-bugs (which probably requires too much time even for some of
the most active emacs developers and would be a waste of time for the
most part) or be left excluded from such debates.

Re: Concern about new binding.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 02 Feb 2021 19:47:41 +0100
> 
> So the effective policy is that either one reads each and every message
> in emacs-bugs (which probably requires too much time even for some of
> the most active emacs developers and would be a waste of time for the
> most part) or be left excluded from such debates.

There are more sophisticated possibilities than just these two
extremities.  Text processing and tagging is a well developed
discipline these days, and Emacs is an ideal environment for that.  If
you cannot afford reading everything, but still want to be involved in
discussing stuff that matters to you, how about setting up filters for
that?

Re: Concern about new binding.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Óscar Fuentes <ofv@wanadoo.es>
>> Date: Tue, 02 Feb 2021 19:47:41 +0100
>> 
>> So the effective policy is that either one reads each and every message
>> in emacs-bugs (which probably requires too much time even for some of
>> the most active emacs developers and would be a waste of time for the
>> most part) or be left excluded from such debates.
>
> There are more sophisticated possibilities than just these two
> extremities.  Text processing and tagging is a well developed
> discipline these days, and Emacs is an ideal environment for that.  If
> you cannot afford reading everything, but still want to be involved in
> discussing stuff that matters to you, how about setting up filters for
> that?

I have no idea about how to effectively implement those filters, apart
from implementing an advanced A.I., but then I would prefer dedicating
the next 30 years of my life to something else.

Re: Concern about new binding.

[Eli Zaretskii]

> From: Óscar Fuentes <ofv@wanadoo.es>
> Date: Tue, 02 Feb 2021 20:00:14 +0100
> 
> I have no idea about how to effectively implement those filters, apart
> from implementing an advanced A.I., but then I would prefer dedicating
> the next 30 years of my life to something else.

Well, then maybe someone will volunteer to do this job for you and
others, and call people's attention to discussions on the bug list
that might interest you and others.

Re: Concern about new binding.

[Óscar Fuentes]

Eli Zaretskii <eliz@gnu.org> writes:

>> I have no idea about how to effectively implement those filters, apart
>> from implementing an advanced A.I., but then I would prefer dedicating
>> the next 30 years of my life to something else.
>
> Well, then maybe someone will volunteer to do this job for you and
> others, and call people's attention to discussions on the bug list
> that might interest you and others.

That would be a remarkable project indeed, because often I don't know
that a topic is relevant to me until I see it popping out in some forum.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > I have no idea about how to effectively implement those filters,
> apart
> > from implementing an advanced A.I., but then I would prefer
> dedicating
> > the next 30 years of my life to something else.
> 
> Well, then maybe someone will volunteer to do this job for you and
> others, and call people's attention to discussions on the bug list
> that might interest you and others.

This seems like a cop-out, to me.

To me, the solution is for bug discussions to
be managed (particularly by anyone who intends
to actually make some change to Emacs) to stop
and move some more general discussion, which
has moved beyond the OP, to emacs-devel.

Oscar's point was that the OP request was
limited, and the result of the bug thread was
to make a much wider-ranging change to Emacs,
not a _necessary_ change to fix the specific
bug.

The right way to handle that (IMO) would have
been to move that wider discussion to emacs-devel.
Let the discussion here decide what changes,
if any, to make.  At least expose more eyeballs
to the wider question at hand.

(That's happening now - for this one, but the
changes were already made, without wider
discussion.)

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Tue, 2 Feb 2021 22:14:02 +0000
> 
> > > I have no idea about how to effectively implement those filters,
> > apart
> > > from implementing an advanced A.I., but then I would prefer
> > dedicating
> > > the next 30 years of my life to something else.
> > 
> > Well, then maybe someone will volunteer to do this job for you and
> > others, and call people's attention to discussions on the bug list
> > that might interest you and others.
> 
> This seems like a cop-out, to me.

The Emacs developers are volunteers doing this job on their own free
time and as much as their resources allow.  When there's something the
community would like to be done that the developers cannot afford
doing, it is customary to call for volunteers to fill that niche.
That's the spirit in Free Software projects developed by volunteers,
and there's nothing wrong with that, certainly not something that
deserves derogatory remarks such as the one above.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > > > I have no idea about how to effectively implement
> > > > those filters, apart from implementing an advanced
> > > > A.I., but then I would prefer dedicating
> > > > the next 30 years of my life to something else.
> > >
> > > Well, then maybe someone will volunteer to do this job for you and
> > > others, and call people's attention to discussions on the bug list
> > > that might interest you and others.
> >
> > This seems like a cop-out, to me.
> 
> The Emacs developers are volunteers doing this job on their own free
> time and as much as their resources allow.  When there's something the
> community would like to be done that the developers cannot afford
> doing, it is customary to call for volunteers to fill that niche.
> That's the spirit in Free Software projects developed by volunteers,
> and there's nothing wrong with that, certainly not something that
> deserves derogatory remarks such as the one above.

You quoted out of context and went off on something else.

My point was that, instead of relying on _anyone_
doing the suggested new job, it should be everyone's
job in a bug-thread to move a discussion to emacs-devel
if it ranges beyond the bug/improvement in question (and
if it's to be continued at all), and especially if it
seems to be leading toward a choice of whether to make
wider changes.

Not having everyone accept _that_ responsibility, and
instead expecting some designated person to alone be
responsible for calling emacs-devel attention to bug-list
discussions that might be of interest, would seem to be a
cop-out, yes - by all of us.  And in particular by anyone
in a bug thread who might be tempted to go ahead and make
changes wider than the bug.  Let's please try not to
change big things in bug threads anymore.

There's nothing derogatory, toward anyone, in what I
wrote.  Quite the contrary.  Let's all assume this
responsibility, and not push it onto some new role. 

I called for us to manage bug threads in this regard,
and not just expect some dedicated town-crier to alert
emacs-devel.  Let's together try to move discussion to
emacs-devel when it goes beyond a particular bug and
starts discussing wider possible changes.

That's the problem to solve: move relevant discussion
to emacs-devel.  You proposed designating someone to
be responsible for that.  I said that would seem to
be a cop-out; we should all be responsible, and in
particular anyone considering making a change wider
than what the bug calls for.  Emacs-devel is the right
place to discuss possible changes that are big.  More
eyeballs, more ideas, more corrections.

RE: [External] : Re: Concern about new binding.

[Eli Zaretskii]

On February 3, 2021 6:44:01 AM GMT+02:00, Drew Adams <drew.adams@oracle.com> wrote:
> 
> > > > Well, then maybe someone will volunteer to do this job for you
> and
> > > > others, and call people's attention to discussions on the bug
> list
> > > > that might interest you and others.
> > >
> > > This seems like a cop-out, to me.
> > 
> > The Emacs developers are volunteers doing this job on their own free
> > time and as much as their resources allow.  When there's something
> the
> > community would like to be done that the developers cannot afford
> > doing, it is customary to call for volunteers to fill that niche.
> > That's the spirit in Free Software projects developed by volunteers,
> > and there's nothing wrong with that, certainly not something that
> > deserves derogatory remarks such as the one above.
> 
> You quoted out of context and went off on something else.
> 
> My point was that, instead of relying on _anyone_
> doing the suggested new job, it should be everyone's
> job in a bug-thread to move a discussion to emacs-devel
> if it ranges beyond the bug/improvement in question (and
> if it's to be continued at all), and especially if it
> seems to be leading toward a choice of whether to make
> wider changes.

IME, there's no "we" in volunteer based Free Software projects such as this one.  Saying "we should do this-and-that" or "this-and-that should be everyone's job" has only one consequence: that no one will do it.  The only way it could work is to interpret "we" as meaning the head maintainers.  I thought you were using this only sensible meaning of "we", and responded to that.

But if you believe that just saying "we should" will get the thing done, then you have said that already, and so we should simply wait for it to happen, because "we all" will do it.  Right?

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > My point was that, instead of relying on _anyone_
> > doing the suggested new job, it should be everyone's
> > job in a bug-thread to move a discussion to emacs-devel
> > if it ranges beyond the bug/improvement in question (and
> > if it's to be continued at all), and especially if it
> > seems to be leading toward a choice of whether to make
> > wider changes.
> 
> IME, there's no "we" in volunteer based Free Software projects such as
> this one.  Saying "we should do this-and-that" or "this-and-that should
> be everyone's job" has only one consequence: that no one will do it.

Currently, someone _is_ doing something.
Someone is making changes that range
beyond the needs/request of particular
bug/improvement reported.

That's what should be fixed, IMO.  Let's
stop doing that.  Instead of just making
some such wide-ranging change, start a
discussion on emacs-devel.

Anyone in a bug discussion can do that.
And it _especially_ behooves anyone who's
thinking about instead just making a
change without such wider discussion.

Designating a single volunteer to follow
all bug threads, and signal to emacs-devel
whenever s?he thinks the wider list is
relevant, is (IMO) not too likely to help.
But if you as maintainer think that that's
the solution, go for it.

There's a _problem_.  I don't think what
you proposed sounds like a great solution.
I'll be happy to be proven wrong.  The
point is to fix the problem, somehow.

I suggested instead that those _actually_
participating in a given bug thread monitor
themselves - that bug discussion - and DTRT:

 1. Don't just make a wider change.
 2. Do start a discussion on emacs-devel
    about the wider question.

> The only way it could work is to interpret "we" as meaning the head
> maintainers.  I thought you were using this only sensible meaning of
> "we", and responded to that.
> 
> But if you believe that just saying "we should" will get the thing
> done, then you have said that already, and so we should simply wait for
> it to happen, because "we all" will do it.  Right?

IMO, it starts by #1: those who've been
making wide changes in bug threads refrain
from doing that.  And yes, #2: everyone in
bug threads start to think more about not
making such changes, and instead moving
wide discussions to emacs-devel.

Just one opinion.

Re: [External] : Re: Concern about new binding.

[Stefan Monnier]

> Currently, someone _is_ doing something.

I'm so glad someone is, indeed.


        Stefan

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "ofv@wanadoo.es" <ofv@wanadoo.es>,
>         "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>
> Date: Wed, 3 Feb 2021 16:03:32 +0000
> 
> > IME, there's no "we" in volunteer based Free Software projects such as
> > this one.  Saying "we should do this-and-that" or "this-and-that should
> > be everyone's job" has only one consequence: that no one will do it.
> 
> Currently, someone _is_ doing something.
> Someone is making changes that range
> beyond the needs/request of particular
> bug/improvement reported.

The prerogative to decide whether some solution is or isn't within the
needs of a problem belongs to the maintainers.  If you want to be part
of this decision-making process, please volunteer to join the
maintenance team.  Otherwise, you will have to trust us to make those
decisions.

> That's what should be fixed, IMO.  Let's
> stop doing that.  Instead of just making
> some such wide-ranging change, start a
> discussion on emacs-devel.

I'm okay with someone -- anyone -- starting a discussion on
emacs-devel about anything being discussed on the bug list.  Just
don't expect Lars and myself to do it every time -- or even most of
the time.  We have too much on our plates to afford doing this
additional job, which we consider much less important than actually
working on the issues.

> I suggested instead that those _actually_
> participating in a given bug thread monitor
> themselves - that bug discussion - and DTRT:
> 
>  1. Don't just make a wider change.
>  2. Do start a discussion on emacs-devel
>     about the wider question.

Once again, these decisions are our prerogative.  Your suggestions are
noted, but are unlikely to be implemented, unless someone volunteers
to start these discussions when people think they should be started.
This has been said already, time and again, so please stop reiterating
the same unfair demands, and instead consider helping us more,
especially where you are motivated to help -- in making more
discussions on emacs-devel.

> > But if you believe that just saying "we should" will get the thing
> > done, then you have said that already, and so we should simply wait for
> > it to happen, because "we all" will do it.  Right?
> 
> IMO, it starts by #1: those who've been
> making wide changes in bug threads refrain
> from doing that.

We won't!  Your demands are out of line.  We are here to develop
Emacs, and we will continue doing that as best as we can, unless the
community thinks we are doing harm, in which case the community should
simply ask us to step down.

Re: [External] : Re: Concern about new binding.

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

  > My point was that, instead of relying on _anyone_

any one person, I think that means.

  > doing the suggested new job, it should be everyone's
  > job in a bug-thread to move a discussion to emacs-devel
  > if it ranges beyond the bug/improvement in question (and
  > if it's to be continued at all), and especially if it
  > seems to be leading toward a choice of whether to make
  > wider changes.

I think this shoula also apply to considering a feature
that would be an incompatibility, or would voilate
established conventions and patterns.

Incompatibilities include changing the behavior of a series of keys
which isn't erroneous (for instance, C-x o o or C-x o ,).

An example of violating a pattern is defining C-x followed by a
capital letter to mean something different from the corresponding
lower-case letter.


-- 
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: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: eliz@gnu.org, ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Fri, 05 Feb 2021 00:46:12 -0500
> 
> I think this shoula also apply to considering a feature
> that would be an incompatibility, or would voilate
> established conventions and patterns.
> 
> Incompatibilities include changing the behavior of a series of keys
> which isn't erroneous (for instance, C-x o o or C-x o ,).
> 
> An example of violating a pattern is defining C-x followed by a
> capital letter to mean something different from the corresponding
> lower-case letter.

I think keeping these patterns could be a good idea, but if we want
these patterns not to be violated, we need to document them first.
Right now, none of these two patterns are documented (AFAICT), and at
least for me it was a surprise to learn that they are patterns we are
supposed to try not to break.

Re: [External] : Re: Concern about new binding.

[Robert Pluim]

>>>>> On Fri, 05 Feb 2021 09:54:49 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >> Incompatibilities include changing the behavior of a series of keys
    >> which isn't erroneous (for instance, C-x o o or C-x o ,).
    >> 
    >> An example of violating a pattern is defining C-x followed by a
    >> capital letter to mean something different from the corresponding
    >> lower-case letter.

    Eli> I think keeping these patterns could be a good idea, but if we want
    Eli> these patterns not to be violated, we need to document them first.
    Eli> Right now, none of these two patterns are documented (AFAICT), and at
    Eli> least for me it was a surprise to learn that they are patterns we are
    Eli> supposed to try not to break.

I can understand why we should avoid changing C-x o o behaviour, but
what's the rationale for the capital letter after C-x rule? Itʼs not
like Iʼm likely to type a capital by mistake (and eg edebug already
doesnʼt follow this rule, since it binds 'C-x X <letter>' commands).

Robert

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: rms@gnu.org,  ofv@wanadoo.es,  drew.adams@oracle.com,  emacs-devel@gnu.org
> Date: Fri, 05 Feb 2021 11:04:24 +0100
> 
> I can understand why we should avoid changing C-x o o behaviour, but
> what's the rationale for the capital letter after C-x rule? Itʼs not
> like Iʼm likely to type a capital by mistake (and eg edebug already
> doesnʼt follow this rule, since it binds 'C-x X <letter>' commands).

Richard explained that up-thread; perhaps he could expand his
explanation.  I believe it has to do with the possibility that you
hold the Shift key knowing that it won't matter.

In any case, if we decide we want to keep this rule, we will explain
its rationale in the manual.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> what's the rationale for the capital letter
> after C-x rule? Itʼs not like Iʼm likely to
> type a capital by mistake (and eg edebug already
> doesnʼt follow this rule, since it binds
> 'C-x X <letter>' commands).

I too see no good reason for making a rule about
capital letters - so far.  I think all letters
should be handled the same.

So I think it should be OK to define both
`C-x f' and `C-x F', `C-x l' and `C-x L', etc.
And it should be OK to define any such sequences
as prefix keys.

I don't think we've heard arguments yet as to
why this shouldn't be the case.

(And as you point out, there are already many
such lower-and-upper examples, at least across
3rd-party code.)

Re: [External] : Re: Concern about new binding.

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

  > I can understand why we should avoid changing C-x o o behaviour, but
  > what's the rationale for the capital letter after C-x rule?

I think the reason is the simplicity of C-x -- that users should not
have to remember one meaning for C-x a and one for C-x A, one for C-x
b and one for C-x B, and so on.

That's not a super-important reason.  It would not be a terrible loss
to eliminate that rule.  And if there were only one capital letter
with a special meaning after C-x, that would not be a great cost.
But I don't think it would remain just one for very long.


-- 
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: [External] : Re: Concern about new binding.

[Robert Pluim]

>>>>> On Sun, 07 Feb 2021 00:33:08 -0500, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> I can understand why we should avoid changing C-x o o behaviour, but
    >> what's the rationale for the capital letter after C-x rule?

    Richard> I think the reason is the simplicity of C-x -- that users should not
    Richard> have to remember one meaning for C-x a and one for C-x A, one for C-x
    Richard> b and one for C-x B, and so on.

To me C-x a and C-x A (or rather C-x-S a) are different key strokes
the same way C-x a and C-x b are, but I guess itʼs possible others see
things differently.

    Richard> That's not a super-important reason.  It would not be a terrible loss
    Richard> to eliminate that rule.  And if there were only one capital letter
    Richard> with a special meaning after C-x, that would not be a great cost.
    Richard> But I don't think it would remain just one for very long.

I think youʼre right there: 26 new possible keymaps, luxury!

Robert

Re: [External] : Re: Concern about new binding.

[Ergus]

On Sun, Feb 07, 2021 at 02:22:53PM +0100, Robert Pluim wrote:
>
>I think youʼre right there: 26 new possible keymaps, luxury!
>
Yes!, but please, let's economize them as much as possible ;p

>Robert
>

RE: [External] : Re: Concern about new binding.

[Drew Adams]

>   > I can understand why we should avoid changing C-x o o behaviour,
>   > but what's the rationale for the capital letter after C-x rule?
> 
> I think the reason is the simplicity of C-x -- that users should not
> have to remember one meaning for C-x a and one for C-x A, one for C-x
> b and one for C-x B, and so on.

I can understand that.  That reason is a bit similar
to why `case-fold-search' is t by default, I guess.

And it could be considered similar to what we do wrt
"shift translation" - (elisp) `Key Sequence Input'.

On the other hand, the argument about needing to
_remember_ is not too strong IMO.  (That's perhaps
especially the case nowadays, with better, including
incremental, help with key bindings.)

If there are separate bindings for `C-x a' and
`C-x A', I think it's pretty much always the case
(and I expect likely always will be the case) that
the `C-x a' binding was introduced first to Emacs,
and it will likely be bound to the more commonly
used of the two commands.  And a user who uses
either and expects the other will soon enough
discover the existence of both, I think.

There are a limited number of easy-to-use keys.
I favor allowing both upper- and lowercase keys in
this context, even keys that Emacs binds by default.
(Just one opinion.)

> That's not a super-important reason.  It would not be a terrible loss
> to eliminate that rule.  And if there were only one capital letter
> with a special meaning after C-x, that would not be a great cost.
> But I don't think it would remain just one for very long.

I too don't think there would remain just one for
long.  But I also don't think having multiple such
is an important problem/inconvenience.

Re: [External] : Re: Concern about new binding.

[Yuri Khan]

On Fri, 5 Feb 2021 at 17:06, Robert Pluim <rpluim@gmail.com> wrote:

> what's the rationale for the capital letter after C-x rule? Itʼs not
> like Iʼm likely to type a capital by mistake (and eg edebug already
> doesnʼt follow this rule, since it binds 'C-x X <letter>' commands).

A practical reason could be Caps Lock. When it’s on, Ctrl+X still
produces C-x, but the following letter key produces a capital
character. Having C-x X different from C-x x would introduce a modal
error where all bindings suddenly change depending on Caps Lock.

(This is another manifestation of the wrongness of binding sequences
of _characters_ rather than _keys_. But that’s what we are stuck with
because of backward compatibility with terminals and terminal
emulators.)

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > My point was that, instead of relying on _anyone_
> 
> any one person, I think that means.

Yes, that's what I meant.  Thx.

Re: Concern about new binding.

[Dmitry Gutov]

On 02.02.2021 20:53, Eli Zaretskii wrote:
> There are more sophisticated possibilities than just these two
> extremities.  Text processing and tagging is a well developed
> discipline these days, and Emacs is an ideal environment for that.  If
> you cannot afford reading everything, but still want to be involved in
> discussing stuff that matters to you, how about setting up filters for
> that?

That implies reading email inside Emacs. Not everyone can do that.

And also a significant amount of work for setting this up, duplicated by 
everybody.

Re: Concern about new binding.

[Eli Zaretskii]

> Cc: emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Tue, 2 Feb 2021 21:07:47 +0200
> 
> On 02.02.2021 20:53, Eli Zaretskii wrote:
> > There are more sophisticated possibilities than just these two
> > extremities.  Text processing and tagging is a well developed
> > discipline these days, and Emacs is an ideal environment for that.  If
> > you cannot afford reading everything, but still want to be involved in
> > discussing stuff that matters to you, how about setting up filters for
> > that?
> 
> That implies reading email inside Emacs. Not everyone can do that.

No, not necessarily.  There are text-processing and indexing tools
outside of Emacs.

> And also a significant amount of work for setting this up, duplicated by 
> everybody.

If you want to be intimately involved in development decisions,
there's always some price to pay.  It should be expected.

Re: Concern about new binding.

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

  > There are more sophisticated possibilities than just these two
  > extremities.  Text processing and tagging is a well developed
  > discipline these days, and Emacs is an ideal environment for that.

Has anyone tried actually doing this?  I don't know of a way.
I read mail with Rmail.

-- 
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: Concern about new binding.

[Sean Whitton]

Hello,

On Fri 05 Feb 2021 at 12:46AM -05, Richard Stallman wrote:

> [[[ 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. ]]]
>
>   > There are more sophisticated possibilities than just these two
>   > extremities.  Text processing and tagging is a well developed
>   > discipline these days, and Emacs is an ideal environment for that.
>
> Has anyone tried actually doing this?  I don't know of a way.
> I read mail with Rmail.

Yes, you can do it with notmuch and its Emacs interface, notmuch.el.

You can do whatever you want.  For example, I have an elisp function to
mute (== any new messages to the thread are marked as read immediately)
all unread threads I haven't touched, but avoid muting threads where I
read messages, so I'll see new messages that later come into those
threads.  That's just one example; if you're willing to write the elisp
you can probably make it happen.

-- 
Sean Whitton

Re: Concern about new binding.

[Dmitry Gutov]

On 05.02.2021 09:11, Sean Whitton wrote:
> You can do whatever you want.  For example, I have an elisp function to
> mute (== any new messages to the thread are marked as read immediately)
> all unread threads I haven't touched, but avoid muting threads where I
> read messages, so I'll see new messages that later come into those
> threads.  That's just one example; if you're willing to write the elisp
> you can probably make it happen.

The common objection here is that bug#46151 started about one thing 
(upon which a number of people would be willing to mute it), but then 
concluded with something pretty different.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> The common objection here is that bug#46151 started about one thing
> (upon which a number of people would be willing to mute it), but then
> concluded with something pretty different.

Exactly.

Re: Concern about new binding.

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

  > You can do whatever you want.  For example, I have an elisp function to
  > mute (== any new messages to the thread are marked as read immediately)
  > all unread threads I haven't touched, but avoid muting threads where I
  > read messages, so I'll see new messages that later come into those
  > threads.  That's just one example; if you're willing to write the elisp
  > you can probably make it happen.

How would I direct notmuch to recognize all messages which were sent
to bug-gnu-emacs but not emacs-devel, and propose a change in the
Emacs user interface?  The second criterion seems to require
humanlike understanding, not text processing.


-- 
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: Concern about new binding.

[Sean Whitton]

Hello Richard,

On Sun 07 Feb 2021 at 12:33AM -05, Richard Stallman wrote:

> [[[ 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. ]]]
>
>   > You can do whatever you want.  For example, I have an elisp function to
>   > mute (== any new messages to the thread are marked as read immediately)
>   > all unread threads I haven't touched, but avoid muting threads where I
>   > read messages, so I'll see new messages that later come into those
>   > threads.  That's just one example; if you're willing to write the elisp
>   > you can probably make it happen.
>
> How would I direct notmuch to recognize all messages which were sent
> to bug-gnu-emacs but not emacs-devel, and propose a change in the
> Emacs user interface?  The second criterion seems to require
> humanlike understanding, not text processing.

notmuch has a system for committing tags on messages under a namespace
to a git repository.  So any contributor could tag a message as
"emacs:interface_change" and then your local notmuch would be configured
to include messages tagged with that in the same view as emacs-devel
messages.

-- 
Sean Whitton

Re: Concern about new binding.

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

  > notmuch has a system for committing tags on messages under a namespace
  > to a git repository.  So any contributor could tag a message as
  > "emacs:interface_change" and then your local notmuch would be configured
  > to include messages tagged with that in the same view as emacs-devel
  > messages.

For such a repo to operate, it would have to be used by a community.
If enough people use it, it could do its job.

How would I fetch new messages from that repo so as to actually read
them?

(I am not sure what notmuch is.)

-- 
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: Concern about new binding.

[Matt Armstrong]

Richard Stallman <rms@gnu.org> writes:

> [[[ 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. ]]]
>
>   > notmuch has a system for committing tags on messages under a namespace
>   > to a git repository.  So any contributor could tag a message as
>   > "emacs:interface_change" and then your local notmuch would be configured
>   > to include messages tagged with that in the same view as emacs-devel
>   > messages.
>
> For such a repo to operate, it would have to be used by a community.
> If enough people use it, it could do its job.
>
> How would I fetch new messages from that repo so as to actually read
> them?
>
> (I am not sure what notmuch is.)

I think to understand this sufficiently well, one must understand
notmuch's basic design.

(notmuch is under the GPL and I believe it is run as a GNU project --
when I submitted patches they asked me for FSF papers -- but don't hold
me to that)

At its core notmuch is a search engine over an email store. The email
store must be one file per message, stored on the local disk. Notmuch
"crawls" that and maintains a database that supports fast retrieval much
like a search engine does. On top of this there are email clients --
initially just for Emacs, others followed. The searches can query over
the message body, the usual header fields, and a set of user specified
tags. This architecture is fast enough that no server needs to run -- it
operates as a command line utility, where each search is a separate
invocation. I am omitting many subleties the sake of brevity.

Notmuch is popular among people who prefer processing their email with
tags/labels, instead of folders. In notmuch, a message's tags are
primary, and its location on disk is secondary (but it, too, can be a
search criteria if desired).

Because notmuch supports custom tags on messages, it can also be used to
keep track of arbitrary states associated with messages, such as read,
unread, flagged, etc. In addition to this, the user can use (mostly)
arbitrary strings as tags. With this flexibility it is not a stretch to
imagine a user treating their notmuch mail store as a bug database.

From there, you could also imagine https://debbugs.gnu.org/ re-written
to use notmuch to store its state. This leads me to
https://notmuchmail.org/nmbug/ -- which is effectively just that. The
notmuch project uses itself to manage its own bug database. Developers
interact with the database using notmuch, change state by modifying tags
on messages, and synchronize those tags using a synchronization approach
built on top of git.

For this to work well, individuals need:

 a) a full local copy of the email history for the bug system.
 b) a current copy of the tags (the bug db metadata)

The primary difference between this notmuch base bug database and Emacs'
current debbugs is distributed git vs a central server.

Which brings me to: if the point is to make certain kinds of bugs more
discoverable, adding that feture to debbugs is another option. For
example, if the bugs tagged "interface change" were interesting, debbugs
could send updates for such bugs to an "interface change" mailing list
that interested people could subscribe to.

Personally, I think these ideas are okay to contemplate, but I suspect
these approaches are more work than the benefits they bring. In all
projects I've ever worked on there has never been a clear algorithm for
separating what should and should not be discussed in a broader
audience, and the core maintainers are constantly having to balancing
the need to just make a decision vs. the desire to cultivate an
inclusive decision making process.

Re: Concern about new binding.

[Sean Whitton]

Hello Matt,

Thank you for your message -- there are however a few misunderstandings
which I'll try to clear up.

On Sun 07 Feb 2021 at 09:41PM -08, Matt Armstrong wrote:

> (notmuch is under the GPL and I believe it is run as a GNU project --
> when I submitted patches they asked me for FSF papers -- but don't hold
> me to that)

It is not an FSF project.  There is no copyright assignment.

> From there, you could also imagine https://debbugs.gnu.org/ re-written
> to use notmuch to store its state. This leads me to
> https://notmuchmail.org/nmbug/ -- which is effectively just that. The
> notmuch project uses itself to manage its own bug database. Developers
> interact with the database using notmuch, change state by modifying tags
> on messages, and synchronize those tags using a synchronization approach
> built on top of git.
>
> For this to work well, individuals need:
>
>  a) a full local copy of the email history for the bug system.
>  b) a current copy of the tags (the bug db metadata)

No, individuals definitely do not require a full local copy of
everything stored in the bug system for nmbug to work.  You do need the
git repository containing all the tags, but it is fine to only have some
of the messages (e.g. only recent messages).

I suggest thinking of the nmbug tagging as independent of debbugs state,
at least to begin with.  I think they're mostly solving different
problems.

> Which brings me to: if the point is to make certain kinds of bugs more
> discoverable, adding that feture to debbugs is another option. For
> example, if the bugs tagged "interface change" were interesting, debbugs
> could send updates for such bugs to an "interface change" mailing list
> that interested people could subscribe to.

Well, you'd have to have debbugs mail the entire bug log to that mailing
list at the point at which it gets tagged, which seems a bit awkward.
The nmbug approach does not involve sending any messages in order to
communicate a tagging of the thread.

-- 
Sean Whitton

Re: Concern about new binding.

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Sun, 07 Feb 2021 23:06:25 -0700
> Cc: ofv@wanadoo.es, eliz@gnu.org, emacs-devel@gnu.org
> 
> > Which brings me to: if the point is to make certain kinds of bugs more
> > discoverable, adding that feture to debbugs is another option. For
> > example, if the bugs tagged "interface change" were interesting, debbugs
> > could send updates for such bugs to an "interface change" mailing list
> > that interested people could subscribe to.
> 
> Well, you'd have to have debbugs mail the entire bug log to that mailing
> list at the point at which it gets tagged, which seems a bit awkward.

That shouldn't be necessary: we have Gnus and Rmail commands to
download the entire bug DB as a series of folders, and thereafter the
messages can be manipulated locally.  See the debbugs package in ELPA.

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Mon 08 Feb 2021 at 05:14PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Sun, 07 Feb 2021 23:06:25 -0700
>> Cc: ofv@wanadoo.es, eliz@gnu.org, emacs-devel@gnu.org
>>
>> > Which brings me to: if the point is to make certain kinds of bugs more
>> > discoverable, adding that feture to debbugs is another option. For
>> > example, if the bugs tagged "interface change" were interesting, debbugs
>> > could send updates for such bugs to an "interface change" mailing list
>> > that interested people could subscribe to.
>>
>> Well, you'd have to have debbugs mail the entire bug log to that mailing
>> list at the point at which it gets tagged, which seems a bit awkward.
>
> That shouldn't be necessary: we have Gnus and Rmail commands to
> download the entire bug DB as a series of folders, and thereafter the
> messages can be manipulated locally.  See the debbugs package in ELPA.

Ah thanks.

I wrote some integration between debbugs and notmuch.el for use in the
Debian project, but it's not very good, and perhaps I can replace it
with some of that code.

-- 
Sean Whitton

Re: Concern about new binding.

[Matt Armstrong]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Hello Matt,
>
> Thank you for your message -- there are however a few misunderstandings
> which I'll try to clear up.

[...]

Thank you for the clarifications.

[...]

> No, individuals definitely do not require a full local copy of
> everything stored in the bug system for nmbug to work. You do need the
> git repository containing all the tags, but it is fine to only have
> some of the messages (e.g. only recent messages).

It may be useful to step away from discussing mechanism, and discuss the
problem and use case.

The problem statement as I understand it is this: a person wishes to
monitor Emacs development by subscribing to emacs-devel. They also wish
to know of "interesting" discussions taking place in Emacs bug reports.

Today, the practical options are:

 a) personally subscribe to bug-gnu-emacs and either read every email or
    write sophisticated filters tuned to their personal interests (this
    is the "AI" problem).

 b) rely on the people conducting the bug discussions to move the
    discussion to emacs-devel when "appropriate." This is a manual
    process.

I don't yet see a consensus that mechanism (b) has been inadequate as a
whole, but exploring alternatives can't hurt.


> I suggest thinking of the nmbug tagging as independent of debbugs
> state, at least to begin with. I think they're mostly solving
> different problems.

Ok. I see your point and agree.


>> Which brings me to: if the point is to make certain kinds of bugs
>> more discoverable, adding that feture to debbugs is another option.
>> For example, if the bugs tagged "interface change" were interesting,
>> debbugs could send updates for such bugs to an "interface change"
>> mailing list that interested people could subscribe to.
>
> Well, you'd have to have debbugs mail the entire bug log to that
> mailing list at the point at which it gets tagged, which seems a bit
> awkward. The nmbug approach does not involve sending any messages in
> order to communicate a tagging of the thread.

I don't think debbugs necessarily needs to email the entire history of
the bug to emacs-devel. If it simply supported a way to cc'd bug emails
from that point forward, to emacs-devel, that could be sufficient to
hold the desired discussions in a broader context.

A benefit to modifying debbugs is that it is a minimal change to
existing workflows.

A solution based on notmuch has the drawback that people must use
notmuch. I think that may be too much to ask, for too little benefit (in
this specific use case -- I think notmuch itself is great).

Re: Concern about new binding.

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

Thank you (and Sean Whitton) for explaining notmuch to me.

  > Which brings me to: if the point is to make certain kinds of bugs more
  > discoverable, adding that feture to debbugs is another option. For
  > example, if the bugs tagged "interface change" were interesting, debbugs
  > could send updates for such bugs to an "interface change" mailing list
  > that interested people could subscribe to.

I see an important advantage in that approach: each person does not
have to switch to using notmuch as per normal way of reading mail.
If enough people make a habit of tagging interface change proposals
in that data base, it would be a reliable way of finding those messages.
I would use it that way.

The drawback for me of switching to notmuch for my incoming mail is
that my incoming mail would be a lot bigger that way.  I currently
saye inbox files, so I have hundreds of incoming messages in one file.
One directory which covers almost 1000 days from Aug 2017 to Feb 2020
is 13gig.  With one message per file it could be several times that
size.

(Can anyone tell me an easy way to split an inbox file into separate
messages one per file?  I will test it and see how much bigger it gets.)

However, doing this only for bug-gnu-emacs mail, and only for the last
month or so, would not cause disk space problem.  That approach should
be feasible.

It would still depend on various participants to mark feature proposals
in the bug dataase.  Forwarding a message to emacs-devel to move those
threads there is just as easy as tagging it.


-- 
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: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: spwhitton@spwhitton.name, ofv@wanadoo.es, eliz@gnu.org,
> 	emacs-devel@gnu.org
> Date: Tue, 09 Feb 2021 01:03:16 -0500
> 
> (Can anyone tell me an easy way to split an inbox file into separate
> messages one per file?  I will test it and see how much bigger it gets.)

Do you have the 'formail' program on your system?  It can do that.

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Sun 07 Feb 2021 at 10:43PM -05, Richard Stallman wrote:

> How would I fetch new messages from that repo so as to actually read
> them?

You don't -- you receive the mail in the usual way, by subscribing to
bug-gnu-emacs.  But you would have that mail get delivered to a folder
you don't normally read, but which notmuch still indexes.

Then when you pull from the repo of tag information, you can ask notmuch
to show you all messages it knows about which are from emacs-devel, and
have one of the tags you are interested in.

> (I am not sure what notmuch is.)

Since you're already familiar with mairix: notmuch is pretty much a more
featureful mairix.  In particular, it has a powerful Emacs interface.
So you can treat the results of a search as if they are a folder of mail
to read.

-- 
Sean Whitton

Re: Concern about new binding.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2021-02-07 08:34]:
> [[[ 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. ]]]
> 
>   > You can do whatever you want.  For example, I have an elisp function to
>   > mute (== any new messages to the thread are marked as read immediately)
>   > all unread threads I haven't touched, but avoid muting threads where I
>   > read messages, so I'll see new messages that later come into those
>   > threads.  That's just one example; if you're willing to write the elisp
>   > you can probably make it happen.
> 
> How would I direct notmuch to recognize all messages which were sent
> to bug-gnu-emacs but not emacs-devel, and propose a change in the
> Emacs user interface?  The second criterion seems to require
> humanlike understanding, not text processing.

References:
https://notmuchmail.org/searching/

Operators

Xapian implements the usual operators and a few more that are useful when searching e-mails.

Note: The operators need not be capitalized for notmuch, so 'NOT' and 'not' are equivalent. The capitalized form is used below only for readability
'+' and '-'

    notmuch search +term1

will only return results that contain 'term1'.

    notmuch search -term2

will return results that do not contain 'term2'. '+' and '-' can also be used on bracketed expressions or phrases (see below).
AND and NOT

notmuch search term1 AND term2

will return results that contain both 'term1' and 'term2'.

If no explicit operator is provided all search terms are connected by an implicit AND, so these two searches:

    notmuch search term1 AND term2
    notmuch search term1 term2

are equivalent.

    notmuch search term1 NOT term2

will return results that contain 'term1' but do not contain 'term2'. For a query that looks more like natural language you can also use AND NOT

    notmuch search term1 AND NOT term2

Re: Concern about new binding.

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

Thanks for explaining the search operators, but I still don't see how
to do this:

> How would I direct notmuch to recognize all messages which were sent
> to bug-gnu-emacs but not emacs-devel, and propose a change in the
> Emacs user interface?  The second criterion seems to require
> humanlike understanding, not text processing.

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

Rmail filter, or using sieve - was Re: Concern about new binding.

[Jean Louis]

* Richard Stallman <rms@gnu.org> [2021-02-13 06:27]:
> [[[ 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. ]]]
> 
> Thanks for explaining the search operators, but I still don't see how
> to do this:
> 
> > How would I direct notmuch to recognize all messages which were sent
> > to bug-gnu-emacs but not emacs-devel, and propose a change in the
> > Emacs user interface?  The second criterion seems to require
> > humanlike understanding, not text processing.

With `notmuch' I cannot help much. `notmuch' and `mu' tools are
indexers of email, so they index it into the database and offer query
searches.

Reference:
https://www.djcbsoftware.nl/code/mu/

`notmuch' never worked for me, so I use `mu' tools. I am using Maildir
format and you probably not.

But the concept on how it works could also probably work in `notmuch'
I just did not yet see the package for Emacs and how it works.

In general, I would just create a hyperlink or function of that kind
that uses the query, so if program is `mu' or function name requires
QUERY as parameter, I would juse use parameter name similar like:

(to:bug-gnu-emacs OR cc:bug-gnu-emacs) NOT emacs-devel

But in general, as that is simple search, I would not be using indexed
database. I would use filtering. I do not know `rmail' functionality,
I believe it does read headers as some meta data. I may be wrong.

I am reading emails as following:

- on server side, all emails TO:/CC: for emacs-devel go to folder
  emacs-devel, they do not mix with gnu-help-emacs and other mailing
  lists

- if email still goes to one of them there will be some mixtures, but
  minimized

- when I read then emacs-devel with mutt, to filter out those sent to
  gnu-help-emacs I just filter by query (I press `l'):

  "! ~C help-gnu-emacs"

  as ~C stands both for TO: field and CC: fields and ~ stands for
  NOT. So filtering is easy and mutt read headers before opening all
  messages.

From that view point it would be best to implement display filter or
listing filter in RMAIL. 

I can read here:
https://www.emacswiki.org/emacs/Rmail

that back in time existed variable `rmail-message-filter' Maybe
similar variable could be introduced to Rmail today.

I can see there exists spam filter functionality:

,----
| rsf-definitions-alist is a variable defined in ‘rmail-spam-filter.el’.
| Its value is nil
| 
|   You can customize this variable.
| 
| Documentation:
| A list of rules (definitions) matching spam messages.
| Each rule is an alist, with elements of the form (FIELD . REGEXP).
| The recognized FIELDS are: from, to, subject, content-type,
| x-spam-status, and contents.  The "contents" element refers to
| the entire text of the message; all the other elements refer to
| message headers of the same name.
`----

I would rather include there `cc' field as well, and maybe `header'
field as well.

Then I assume that spam functionality moves spam to (defcustom
rsf-file "~/XRMAIL-SPAM"

The same functionality could be generalized to have a definition of
the filter in a list and to define where to save such emails.

You could as well use spam functionality to move or copy some messages
to separate file and read them from the newly generated file. You
could chane `rsf-file' variable to some other name while using such
temporarily spam filter that basically sorts messages you wants.

But I am not sure if Rmail's spam filter supports negative match, like
NOT help-gnu-emacs

Easier would be to use `mutt' temporarily as then you could filter out
right away specific emails, including save them into separate
folders. You could later read same mailboxes by using Rmail.

Another solution would be to use `sieve' from GNU Mailutils to sort
messages in various folders. Then you would invoke the sieve command,
messages would be sorted and you would use rmail as usual to read them
and answer them.

The sieve script would be something like this below, but may syntax
may be wrong:


,----
| require "fileinto";
| 
| if address ["to", "cc"] "emacs-devel@gnu.org" and address ["to", "cc"]
|        not "help-gnu-emacs@gnu.org" {
|        fileinto "INBOX.only-emacs-devel";
| }
`----

You would then read INBOX.only-emacs-devel as it would not include
those others.

The sieve script you would run as:

$ sieve -f /home/rms/INBOX-OR-RMAIL my-sieve-script

and then invoke sieve when you need it.

I am including Sergey Poznyakoff as he is maintainer of GNU Mailutils
and can comment on this request better.

Jean

Re: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Fri, 05 Feb 2021 00:46:21 -0500
> 
>   > There are more sophisticated possibilities than just these two
>   > extremities.  Text processing and tagging is a well developed
>   > discipline these days, and Emacs is an ideal environment for that.
> 
> Has anyone tried actually doing this?  I don't know of a way.
> I read mail with Rmail.

I'd start with M-s (assuming you prepared in advance a suitable regexp
that matches any keywords you are interested in).

Re: Concern about new binding.

[Eli Zaretskii]

> Date: Fri, 05 Feb 2021 10:02:11 +0200
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> 
> > From: Richard Stallman <rms@gnu.org>
> > Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> > Date: Fri, 05 Feb 2021 00:46:21 -0500
> > 
> >   > There are more sophisticated possibilities than just these two
> >   > extremities.  Text processing and tagging is a well developed
> >   > discipline these days, and Emacs is an ideal environment for that.
> > 
> > Has anyone tried actually doing this?  I don't know of a way.
> > I read mail with Rmail.
> 
> I'd start with M-s (assuming you prepared in advance a suitable regexp
> that matches any keywords you are interested in).

Another alternative is mairix.el.

And if no existing Emacs feature fits the bill, how about posting a
list of requirements for such filtering?  It may be high time for
having such mail-filtering capabilities in Emacs.

Re: Concern about new binding.

[Robert Pluim]

>>>>> On Fri, 05 Feb 2021 10:46:40 +0200, Eli Zaretskii <eliz@gnu.org> said:

    Eli> And if no existing Emacs feature fits the bill, how about posting a
    Eli> list of requirements for such filtering?  It may be high time for
    Eli> having such mail-filtering capabilities in Emacs.

(info "(gnus) Scoring")

Re: Concern about new binding.

[Richard Stallman]

Mairix does the job, but my outgoing mail is in a format that Mairix
can't read.

A few weeks ago I changed the format into something I hope Mairix can
understand, I have not had time to test Mairix on that input.

I also have not had time to commit those changes.


-- 
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: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> cc: rms@gnu.org
> Date: Sun, 07 Feb 2021 00:43:15 -0500
> 
> Mairix does the job, but my outgoing mail is in a format that Mairix
> can't read.

I thought we were talking about your _incoming_ mail, and that is in
the form of mbox files, which Mairix does understand.

Re: Concern about new binding.

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

  > I thought we were talking about your _incoming_ mail, and that is in
  > the form of mbox files, which Mairix does understand.

Sorry, you're right about that.  I hoped before to use mairix
instead of grep to search my mail, and it failed because it
could not handle my outgoing mail.  However, for this one
purpose, mairix is usable.

But I don't see how a textual search can detect these messages.

-- 
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: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: ofv@wanadoo.es, emacs-devel@gnu.org
> Date: Sun, 07 Feb 2021 22:44:00 -0500
> 
>   > I thought we were talking about your _incoming_ mail, and that is in
>   > the form of mbox files, which Mairix does understand.
> 
> Sorry, you're right about that.  I hoped before to use mairix
> instead of grep to search my mail, and it failed because it
> could not handle my outgoing mail.  However, for this one
> purpose, mairix is usable.
> 
> But I don't see how a textual search can detect these messages.

That depends on your criteria for "interesting" messages.  I cannot
possibly know that.  How would you do that by examining the messages
themselves?

In any case, measures such as Mairix don't have to have 100% accuracy,
they just need to lower the volume of email you aren't interested in
enough to make the difference.

Re: Concern about new binding.

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

  > I'd start with M-s (assuming you prepared in advance a suitable regexp
  > that matches any keywords you are interested in).

That may sound adequate in the abstract, but I can't see how a bounded
list of words would reliably find me all the messages I need to read.
If you think this is easy, I challenge you to find them.


-- 
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: [External] : Re: Concern about new binding.

[Drew Adams]

> The title of that bug report is "Set revert-buffer-function in shell
> command output buffers", no hint about discussing global keybindings.
> 
> So the effective policy is that either one reads each and every message
> in emacs-bugs (which probably requires too much time even for some of
> the most active emacs developers and would be a waste of time for the
> most part) or be left excluded from such debates.

Yup, this is a problem (IMO).

IMHO, developments outside the purview of a given
bug report should NOT be undertaken without either
(1) filing another bug report to cover that new
subject or (2) opening a discussion in mailing
list emacs-devel.

There are far too many consequential developments
being done now in the context of bug threads.  My
guess is that this is (at least sometimes) to make
an end-run around the need for wider discussion.

Eli has even hinted that that's the case, I think,
by saying that discussion in emacs-devel can be
never-ending (my paraphrase of what I recall).

Re: Concern about new binding.

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

  > See bug#46151.

  > IIUC the initial request was to have a way to revert shell output
  > buffers; somewhere along the way the usefulness of a global binding for
  > revert-buffer was brought up, various options were discussed, a decision
  > was taken, and here we are.

Did that discussion happen entirely within that bug thread?

-- 
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: Concern about new binding.

[Kévin Le Gouguec]

Richard Stallman <rms@gnu.org> writes:

>   > See bug#46151.
>
>   > IIUC the initial request was to have a way to revert shell output
>   > buffers; somewhere along the way the usefulness of a global binding for
>   > revert-buffer was brought up, various options were discussed, a decision
>   > was taken, and here we are.
>
> Did that discussion happen entirely within that bug thread?

I do not remember seeing any message on emacs-devel about this topic
before Ergus started this thread.

Re: Concern about new binding.

[Eli Zaretskii]

On February 3, 2021 8:08:13 AM GMT+02:00, "Kévin Le Gouguec" <kevin.legouguec@gmail.com> wrote:
> Richard Stallman <rms@gnu.org> writes:
> 
> >   > See bug#46151.
> >
> >   > IIUC the initial request was to have a way to revert shell
> output
> >   > buffers; somewhere along the way the usefulness of a global
> binding for
> >   > revert-buffer was brought up, various options were discussed, a
> decision
> >   > was taken, and here we are.
> >
> > Did that discussion happen entirely within that bug thread?
> 
> I do not remember seeing any message on emacs-devel about this topic
> before Ergus started this thread.

FTR, that bug report was a feature request (and for a new key binding at that), so the fact it ended up introducing a new key binding shouldn't surprise anyone.

It is of course OK to start here a discussion about any change that could have unintended or adverse consequences, as Ergus did in this case.  I see nothing wrong with having such discussions after the change is installed.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > > Did that discussion happen entirely within that bug thread?
> >
> > I do not remember seeing any message on emacs-devel about this topic
> > before Ergus started this thread.

That's my recollection also.

> FTR, that bug report was a feature request (and for a new key binding
> at that), so the fact it ended up introducing a new key binding
> shouldn't surprise anyone.

It was about a particular mode, not about a
global key for reverting buffers in general.

That's the problem: the discussion of a narrow
feature request and possible solutions turned
into a wider discussion.  _And_ someone there
decided to change Emacs to add a global key
for reverting buffers.

That a bug/enhancement discussion can range
wider is not unusual or bad.  But when it
comes to making wide-ranging changes to Emacs
it's maybe time to move that wider discussion
to emacs-devel.  That's the point (IMO).

> It is of course OK to start here a discussion about any change that
> could have unintended or adverse consequences, as Ergus did in this
> case.  I see nothing wrong with having such discussions after the
> change is installed.

100% agreement.  It's not too late to discuss
this, and to remove that new key binding.

IMO, the binding should be removed until/unless
the discussion here leads to a decision to add
it back again.

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "spacibba@aol.com" <spacibba@aol.com>
> Date: Wed, 3 Feb 2021 16:12:01 +0000
> 
> > FTR, that bug report was a feature request (and for a new key binding
> > at that), so the fact it ended up introducing a new key binding
> > shouldn't surprise anyone.
> 
> It was about a particular mode, not about a
> global key for reverting buffers in general.

The original suggestion was about a minor mode, but while discussing
the solution, several people agreed that a more general solution would
make sense.  There's nothing wrong here.  It's entirely within a
legitimate process of discussing a proposal for an improvement, and
it's entirely adequate for the maintainers to decide they prefer a
more general solution to what originally was a more narrow one.

> That's the problem: the discussion of a narrow
> feature request and possible solutions turned
> into a wider discussion.  _And_ someone there
> decided to change Emacs to add a global key
> for reverting buffers.

There's no problem here, none.  This is how Emacs development worked
for decades, and this is how it works now.  Please stop
misrepresenting a completely legitimate process of deciding on a
solution as if it were some kind of coup d'état.  It isn't.  Nothing
untowardly happened during the discussions of that issue, and the
decision was entirely adequate.

> That a bug/enhancement discussion can range
> wider is not unusual or bad.  But when it
> comes to making wide-ranging changes to Emacs
> it's maybe time to move that wider discussion
> to emacs-devel.  That's the point (IMO).

The "maybe" part assumes some space for a judgment call, so it's
unclear to me why you claim that the decision not to start such a
discussion ahead of the commit must necessarily be wrong.

> > It is of course OK to start here a discussion about any change that
> > could have unintended or adverse consequences, as Ergus did in this
> > case.  I see nothing wrong with having such discussions after the
> > change is installed.
> 
> 100% agreement.  It's not too late to discuss
> this, and to remove that new key binding.

Then what is the problem, exactly? what are you arguing about, when
the discussion _was_ started, and _is_ happening?

> IMO, the binding should be removed until/unless
> the discussion here leads to a decision to add
> it back again.

Please wait till the discussion comes to its conclusion.

Re: [External] : Re: Concern about new binding.

[spacibba--- via Emacs development discussions.]

>
>> IMO, the binding should be removed until/unless
>> the discussion here leads to a decision to add
>> it back again.
>
>Please wait till the discussion comes to its conclusion.

In my short experience here; when discussions start like this; then
there is never a conclusion. They just slowly stop and no change is made
at the end. I someone insists after some time, the again the same...

In 3 years I have more than 30 examples...

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> Date: Wed, 3 Feb 2021 19:01:42 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org,
> 	kevin.legouguec@gmail.com, rms@gnu.org
> 
> >
> >> IMO, the binding should be removed until/unless
> >> the discussion here leads to a decision to add
> >> it back again.
> >
> >Please wait till the discussion comes to its conclusion.
> 
> In my short experience here; when discussions start like this; then
> there is never a conclusion. They just slowly stop and no change is made
> at the end. I someone insists after some time, the again the same...
> 
> In 3 years I have more than 30 examples...

I don't think I understand what you are saying.  You started this
discussion.  If you don't like how discussions happen here, why did
you start it?

Re: [External] : Re: Concern about new binding.

[Ergus]

On Wed, Feb 03, 2021 at 08:14:34PM +0200, Eli Zaretskii wrote:
>> Date: Wed, 3 Feb 2021 19:01:42 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org,
>> 	kevin.legouguec@gmail.com, rms@gnu.org
>>
>> >
>> >> IMO, the binding should be removed until/unless
>> >> the discussion here leads to a decision to add
>> >> it back again.
>> >
>> >Please wait till the discussion comes to its conclusion.
>>
>> In my short experience here; when discussions start like this; then
>> there is never a conclusion. They just slowly stop and no change is made
>> at the end. I someone insists after some time, the again the same...
>>
>> In 3 years I have more than 30 examples...
>
>I don't think I understand what you are saying.  You started this
>discussion.  If you don't like how discussions happen here, why did
>you start it?
>
I didn't want to start any discussion. I thought that the discussion had
already taken place but I couldn't find it. 

My problem is not the discussion itself, not even the final result; but
that when it becomes a "discussion" nothing finally happens FWIS. Either
if it is a general discussion like "modernizing emacs" or a very
specific one like this.

I think Gregory already proposed the best approach, but now people are
arguing about Magit, projectile or philosophical questions.

IMHO, I would prefer that after a deadline you make a decision (even if
it is the opposite to what I expect) and close it. Otherwise it becomes
a never ending collections of emails with no final results...

Best,
Ergus

Re: [External] : Re: Concern about new binding.

[Stefan Kangas]

Ergus <spacibba@aol.com> writes:

> My problem is not the discussion itself, not even the final result; but
> that when it becomes a "discussion" nothing finally happens FWIS. Either
> if it is a general discussion like "modernizing emacs" or a very
> specific one like this.

I mean, sure.  Please help by sending patches, and more will get done.

FWIW, I'm working in silence on an improved splash screen, but since I
do this in my spare time I tend to work on what strikes my fancy for the
day, and progress is consequently fairly slow.  I have some other
project ideas from the "modernizing Emacs" discussion, but again only
limited time.

> IMHO, I would prefer that after a deadline you make a decision (even if
> it is the opposite to what I expect) and close it. Otherwise it becomes
> a never ending collections of emails with no final results...

I guess there is nothing to make a final decision about unless someone
threatens with a patch.  Please do that more.  :-)

Re: [External] : Re: Concern about new binding.

[Ergus]

On Wed, Feb 03, 2021 at 06:41:50PM -0600, Stefan Kangas wrote:
>Ergus <spacibba@aol.com> writes:
>
>> My problem is not the discussion itself, not even the final result; but
>> that when it becomes a "discussion" nothing finally happens FWIS. Either
>> if it is a general discussion like "modernizing emacs" or a very
>> specific one like this.
>
>I mean, sure.  Please help by sending patches, and more will get done.
>
>FWIW, I'm working in silence on an improved splash screen, but since I
>do this in my spare time I tend to work on what strikes my fancy for the
>day, and progress is consequently fairly slow.  I have some other
>project ideas from the "modernizing Emacs" discussion, but again only
>limited time.
>
>> IMHO, I would prefer that after a deadline you make a decision (even if
>> it is the opposite to what I expect) and close it. Otherwise it becomes
>> a never ending collections of emails with no final results...
>
>I guess there is nothing to make a final decision about unless someone
>threatens with a patch.  Please do that more.  :-)

Could we revert the previous one then?? That's the first part of my
question.

The second is to send a new functionality patch; but for that a second
decision needs to be made. Do we add a map? do we let it free? Do we
bind it somewhere else?

Gregory made a reasonable proposal IMO, but some other users prefer to
keep it free (so simply revert the patch)... To send a patch I need to
know what to do... 

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> Date: Thu, 4 Feb 2021 08:00:33 +0100
> From: Ergus <spacibba@aol.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, kevin.legouguec@gmail.com, rms@gnu.org,
> 	drew.adams@oracle.com, emacs-devel@gnu.org
> 
> >I guess there is nothing to make a final decision about unless someone
> >threatens with a patch.  Please do that more.  :-)
> 
> Could we revert the previous one then?? That's the first part of my
> question.

I'd prefer to find a binding to which people could agree, because that
would leave fewer people unhappy.  The two candidates proposed till
now are "C-x G" and "C-x M-u".

Re: Concern about new binding.

[Gregory Heytings]

>>> I guess there is nothing to make a final decision about unless someone 
>>> threatens with a patch.  Please do that more.  :-)
>>
>> Could we revert the previous one then?? That's the first part of my 
>> question.
>
> I'd prefer to find a binding to which people could agree, because that 
> would leave fewer people unhappy.  The two candidates proposed till now 
> are "C-x G" and "C-x M-u".
>

You forgot the proposal to which the mail you are replying to explicitly 
refers.  So I'll copy it here again: it is to make "C-x g" a keymap for 
buffer-related operations, with in particular "C-x g r" bound to 
revert-buffer:

C-x g c = clone-buffer
C-x g d = diff-buffers
C-x g f = fit-frame-to-buffer
C-x g h = hexl-mode
C-x g i = insert-buffer
C-x g l = font-lock-mode
C-x g n = rename-buffer
C-x g r = revert-buffer
C-x g R = revert-buffer-with-fine-grain
C-x g t = toggle-truncate-lines
...

BTW, Richard replied to the "C-x G" proposal: "Letters following C-x are 
not case-sensitive.  That is a systematic rule.  That rule is not sacred; 
for a good enough reason, we could break it.  But this is not an important 
reason; it is not sufficient reason to break a rule."

Re: Concern about new binding.

[Eli Zaretskii]

> Date: Thu, 04 Feb 2021 15:56:33 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> >>> I guess there is nothing to make a final decision about unless someone 
> >>> threatens with a patch.  Please do that more.  :-)
> >>
> >> Could we revert the previous one then?? That's the first part of my 
> >> question.
> >
> > I'd prefer to find a binding to which people could agree, because that 
> > would leave fewer people unhappy.  The two candidates proposed till now 
> > are "C-x G" and "C-x M-u".
> >
> 
> You forgot the proposal to which the mail you are replying to explicitly 
> refers.

No, I didn't forget.  I just prefer to solve a problem by the simplest
fix, and introducing a whole new set of bindings seems more complex
than strictly needed.  That proposal also didn't seem to have too many
supporters.

But I'm okay with that as well, if it will be deemed as an acceptable
fix.

> BTW, Richard replied to the "C-x G" proposal: "Letters following C-x are 
> not case-sensitive.  That is a systematic rule.  That rule is not sacred; 
> for a good enough reason, we could break it.  But this is not an important 
> reason; it is not sufficient reason to break a rule."

I keep that in mind as well.  But if enough people are okay with "C-x G"
we might decide to break that rule here anyway.

Re: Concern about new binding.

[Gregory Heytings]

>>> I'd prefer to find a binding to which people could agree, because that 
>>> would leave fewer people unhappy.  The two candidates proposed till 
>>> now are "C-x G" and "C-x M-u".
>>
>> You forgot the proposal to which the mail you are replying to 
>> explicitly refers.
>
> No, I didn't forget.  I just prefer to solve a problem by the simplest 
> fix, and introducing a whole new set of bindings seems more complex than 
> strictly needed.
>

The proposal is only to use "C-x g r" for "revert-buffer" and C-x g R" for 
"revert-buffer-with-fine-grain", leaving room for other buffer-related 
operations.  These bindings are also hard to type by accident.

The other proposed bindings are there only to demonstrate that the keymap 
would not remain empty.

Re: Concern about new binding.

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

  > > BTW, Richard replied to the "C-x G" proposal: "Letters following C-x are 
  > > not case-sensitive.  That is a systematic rule.  That rule is not sacred; 
  > > for a good enough reason, we could break it.  But this is not an important 
  > > reason; it is not sufficient reason to break a rule."

  > I keep that in mind as well.  But if enough people are okay with "C-x G"
  > we might decide to break that rule here anyway.

Let's first look for other solutions which are good enough
don't break a rule.

Perhaps not making a new binding for revert-buffer is an adequate solution.

-- 
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: Concern about new binding.

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> You forgot the proposal to which the mail you are replying to
> explicitly refers.  So I'll copy it here again: it is to make "C-x g"
> a keymap for buffer-related operations, with in particular "C-x g r"
> bound to revert-buffer:
>
> C-x g c = clone-buffer
> C-x g d = diff-buffers
> C-x g f = fit-frame-to-buffer
> C-x g h = hexl-mode
> C-x g i = insert-buffer
> C-x g l = font-lock-mode
> C-x g n = rename-buffer
> C-x g r = revert-buffer
> C-x g R = revert-buffer-with-fine-grain
> C-x g t = toggle-truncate-lines

Of the alternative key bindings proposed, I like this the best.  I'd
prefer `C-x g g' for revert-buffer, though -- it's more in like with the
`g' binding in `special-mode-map', and `revert-buffer' is a command
you're likely to want to execute a number of times (in some cases),
while the rest of these are less keyboard-mashey.

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

Re: Concern about new binding.

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 04 Feb 2021 17:46:19 +0100
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org
> 
> > C-x g c = clone-buffer
> > C-x g d = diff-buffers
> > C-x g f = fit-frame-to-buffer
> > C-x g h = hexl-mode
> > C-x g i = insert-buffer
> > C-x g l = font-lock-mode
> > C-x g n = rename-buffer
> > C-x g r = revert-buffer
> > C-x g R = revert-buffer-with-fine-grain
> > C-x g t = toggle-truncate-lines
> 
> Of the alternative key bindings proposed, I like this the best.

Then maybe this is what we should do.

Re: Concern about new binding.

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> Of the alternative key bindings proposed, I like this the best.
>
> Then maybe this is what we should do.

Sure, but there's no hurry -- waiting a few more days to see whether
anybody has a better idea is OK.

The one concern about the `C-x g' binding is that Magit already
recommends it, but it's unclear to me how many people actually use it,
and what it's bound to.  Is it just a global binding for `M-x magit'?

Presumably Magit users who've bound it to that will continue to do so...
and then they'll miss the new binding(s) under `C-x g', but I guess
that's up to each individual user.

So I don't know whether this is something we should worry about.

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

Re: Concern about new binding.

[Joost Kremers]

On Thu, Feb 04 2021, Lars Ingebrigtsen wrote:
> The one concern about the `C-x g' binding is that Magit already
> recommends it, but it's unclear to me how many people actually use it,
> and what it's bound to.  Is it just a global binding for `M-x magit'?

`magit-status`, to be exact. (Though `magit` is an alias for `magit-status`.)

> Presumably Magit users who've bound it to that will continue to do so...

Well... The thing is, Magit nowadays sets up `C-x g` (and two other bindings) by
default, but *only* if those keys aren't already bound to something else. So once
Emacs starts binding `C-x g` to something by default, the binding won't work for
magit anymore. User who are used to using `C-x g` for `magit-status` will
suddenly find themselves reverting buffers when they upgrade their Emacs.

FYI, details about Magit's default bindings are here:

https://magit.vc/manual/magit/Default-Bindings.html#Default-Bindings

> So I don't know whether this is something we should worry about.

I suspect it will lead to countless confused users asking numerous questions on
every available help forum. Also, given that many Magit tutorials on the web
mention `C-x g`, and assuming that many of them won't be updated, it's likely
new users will be confused by this for years to come.

Whether the latter should be a concern is debatable, of course: we all have to
contend with outdated information on the web. But given the way Magit handles
its bindings right now, it would be good to give the Magit maintainers a
heads-up if the new binding is kept, so they can decide how to deal with it.


-- 
Joost Kremers
Life has its moments

Re: Concern about new binding.

[Lars Ingebrigtsen]

Joost Kremers <joostkremers@fastmail.fm> writes:

> Well... The thing is, Magit nowadays sets up `C-x g` (and two other
> bindings) by default, but *only* if those keys aren't already bound to
> something else.

Well, that makes the situation more ticklish than I thought.  Could we
convince them to bind `C-x g' unconditionally, I wonder?

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

Re: Concern about new binding.

[Basil L. Contovounesios]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Joost Kremers <joostkremers@fastmail.fm> writes:
>
>> Well... The thing is, Magit nowadays sets up `C-x g` (and two other
>> bindings) by default, but *only* if those keys aren't already bound to
>> something else.
>
> Well, that makes the situation more ticklish than I thought.  Could we
> convince them to bind `C-x g' unconditionally, I wonder?

They've already done so: https://github.com/magit/magit/discussions/4311

The package's main entrypoint, magit-status, used to be bound to 'C-x g'
by default if the key was unbound.

It is now additionally rebound if bound to revert-buffer.

-- 
Basil

Re: Concern about new binding.

[Lars Ingebrigtsen]

"Basil L. Contovounesios" <contovob@tcd.ie> writes:

>> Well, that makes the situation more ticklish than I thought.  Could we
>> convince them to bind `C-x g' unconditionally, I wonder?
>
> They've already done so: https://github.com/magit/magit/discussions/4311
>
> The package's main entrypoint, magit-status, used to be bound to 'C-x g'
> by default if the key was unbound.
>
> It is now additionally rebound if bound to revert-buffer.

Great!  It shows that the magit people as so responsive that we don't
have to worry, and can just go ahead and bind `C-x g' as planned.

...

JUST KIDDING.

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

Re: Concern about new binding.

[Kévin Le Gouguec]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The one concern about the `C-x g' binding is that Magit already
> recommends it, but it's unclear to me how many people actually use it,
> and what it's bound to.  Is it just a global binding for `M-x magit'?
>
> Presumably Magit users who've bound it to that will continue to do so...
> and then they'll miss the new binding(s) under `C-x g', but I guess
> that's up to each individual user.

To clarify:

- C-x g is bound to magit-status, which is Magit's main entry point,

- Magit includes an autoloaded form that binds C-x g if
    - that key sequence is not bound to anything else, and
    - magit-status is not already bound, and
    - the user hasn't set an explicit "dont-do-that" variable.

(Same goes for two other bindings: C-x M-g for magit-dispatch, and C-c
M-g for magit-file-dispatch.)

So adding a default binding for C-x g *will* change how Magit behaves in
its default configuration.


I struggle to form a solid stance about the change under discussion:

- I wouldn't find it outlandish for Magit to do something similar to
  rg.el: provide a function (say magit-enable-default-bindings) that
  users can call in their init file to easily setup some bindings under
  a prefix (that would default to C-c g).

- I wouldn't mind C-x g (or C-x g g, or C-x g r) being bound to
  revert-buffer.

- I find C-x g somewhat awkward as a prefix for buffer commands.  Not
  really mnemonic, at least.

Re: Concern about new binding.

[Thibaut Verron]

2021-02-04 22:00 UTC+01:00, Kévin Le Gouguec <kevin.legouguec@gmail.com>:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> The one concern about the `C-x g' binding is that Magit already
>> recommends it, but it's unclear to me how many people actually use it,
>> and what it's bound to.  Is it just a global binding for `M-x magit'?
>>
>> Presumably Magit users who've bound it to that will continue to do so...
>> and then they'll miss the new binding(s) under `C-x g', but I guess
>> that's up to each individual user.
>
> To clarify:
>
> - C-x g is bound to magit-status, which is Magit's main entry point,
>
> - Magit includes an autoloaded form that binds C-x g if
>     - that key sequence is not bound to anything else, and
>     - magit-status is not already bound, and
>     - the user hasn't set an explicit "dont-do-that" variable.
>
> (Same goes for two other bindings: C-x M-g for magit-dispatch, and C-c
> M-g for magit-file-dispatch.)
>
> So adding a default binding for C-x g *will* change how Magit behaves in
> its default configuration.
>
>
> I struggle to form a solid stance about the change under discussion:
>
> - I wouldn't find it outlandish for Magit to do something similar to
>   rg.el: provide a function (say magit-enable-default-bindings) that
>   users can call in their init file to easily setup some bindings under
>   a prefix (that would default to C-c g).

So to be clear, we would ask hundreds/thousands/whatever of users to
add a change to their init file and possibly change a binding they use
daily, in order to either make room for, or override a binding they
mostly never asked for?

If revert-buffer is to be a new binding (with others or not) is it not
worth trying to find a keymap which does not conflict with one of the
(if not the) most popular of emacs' 3rd party packages?

> - I find C-x g somewhat awkward as a prefix for buffer commands.  Not
>   really mnemonic, at least.

Whereas it is a good mnemonic for 'G'it.

Re: Concern about new binding.

[Kévin Le Gouguec]

Thibaut Verron <thibaut.verron@gmail.com> writes:

>> - I wouldn't find it outlandish for Magit to do something similar to
>>   rg.el: provide a function (say magit-enable-default-bindings) that
>>   users can call in their init file to easily setup some bindings under
>>   a prefix (that would default to C-c g).
>
> So to be clear, we would ask hundreds/thousands/whatever of users to
> add a change to their init file and possibly change a binding they use
> daily, in order to either make room for, or override a binding they
> mostly never asked for?

I've used Magit daily for years, and I call magit-status through C-x g
dozens of times an hour.  It is very much ingrained in my muscle memory,
and it would take me a lot of frustrating misinputs to retrain myself to
use another binding.

In the grand scheme of things though, and for the sake of more
consistent conventions across the package ecosystem, I wouldn't fault
Emacs maintainers for reclaiming a binding that, IMO, is their
prerogative to make use of, so long as whatever C-x g ends up being
bound to makes some sort of sense and/or is useful.

Re: Concern about new binding.

[Jean Louis]

* Kévin Le Gouguec <kevin.legouguec@gmail.com> [2021-02-05 01:03]:
> Thibaut Verron <thibaut.verron@gmail.com> writes:
> 
> >> - I wouldn't find it outlandish for Magit to do something similar to
> >>   rg.el: provide a function (say magit-enable-default-bindings) that
> >>   users can call in their init file to easily setup some bindings under
> >>   a prefix (that would default to C-c g).
> >
> > So to be clear, we would ask hundreds/thousands/whatever of users to
> > add a change to their init file and possibly change a binding they use
> > daily, in order to either make room for, or override a binding they
> > mostly never asked for?
> 
> I've used Magit daily for years, and I call magit-status through C-x g
> dozens of times an hour.  It is very much ingrained in my muscle memory,
> and it would take me a lot of frustrating misinputs to retrain myself to
> use another binding.

You could upgrade the muscle memory and just switch to C-c g or
something else. When I was playing with prefixes I have discovered
that I just have to split memorizing the prefix and letters behind and
whatever prefix I change or introduce I can use it again with those
letters behind.

I have just tried it and changed my favorit prefix from `s-p' to `C-c
p' and I do not even think about the `C-p p' when invoking it, that
goes fast as I have put `C-c p' in the prefix slot of the muscle
memory and all other keys in the map slot of the muscle memory. I have
no other way to express me but that is about how it is.

I could change prefix to F5 and have the same effect. Try it out.

Here is how I have defined my map.

(define-prefix-command 'cf-map)
(global-set-key (kbd "s-p") 'cf-map)

but then today I have changed it to:

(global-set-key (kbd "C-c p") 'cf-map)

and

(global-set-key (kbd "<f5>") 'cf-map)

and I can equally and without problems invoke {<f5> j} to find people
by their phone number or {C-c p j} to do the same.

So now I just need to know one time, like 1 second to remember what is
the prefix. It does not matter, I can now press {C-c p j} to find
people in the database by using the phone number ot {C-c p L} to list
all the recently entered people into the database. It may look complex
or sound complex. My practical use case is simple. Switching from
prefix to prefix is easy for me.

Try it out. Excercise few times. Maybe you discover something new.

Jean

Re: Concern about new binding.

[Kévin Le Gouguec]

Jean Louis <bugs@gnu.support> writes:

>> I've used Magit daily for years, and I call magit-status through C-x g
>> dozens of times an hour.  It is very much ingrained in my muscle memory,
>> and it would take me a lot of frustrating misinputs to retrain myself to
>> use another binding.
>
> You could upgrade the muscle memory and just switch to C-c g or
> something else.

(Note that, in the part of the message you left out, I said I wouldn't
mind Emacs maintainers binding C-x g to something new, as I consider it
to be their prerogative.)

> Try it out. Excercise few times. Maybe you discover something new.

FWIW, I've spent this past week with

    (my/define-prefix-command my/magit-map
      "Keymap for Magit commands."
      '(("c" magit-file-dispatch)
        ("f" magit-find-file)
        ("g" magit-status)
        ("x" magit-dispatch)))

    (global-set-key (kbd "C-c g") 'my/magit-map)

… and been none the worse for wear.  What "frustrating misinputs" I had
were mostly due to forgetting to "git pull" my dotfiles on another
computer.

Re: Concern about new binding.

[Gregory Heytings]

>
> Presumably Magit users who've bound it to that will continue to do so... 
> and then they'll miss the new binding(s) under `C-x g', but I guess 
> that's up to each individual user.
>
> So I don't know whether this is something we should worry about.
>

There is always the possibility to use another free C-x LETTER slot.  The 
other ones are c j w x y.  (A few symbols are also free, for example # / % 
: _ !.)

Re: Concern about new binding.

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> There is always the possibility to use another free C-x LETTER slot.
> The other ones are c j w x y.  (A few symbols are also free, for
> example # / % : _ !.)

Perhaps `C-x x <letter>' would be nice for these buffer-related
commands?  It's not exactly mnemonic, but it has a certain ring to it.

Any major packages that have claimed the `C-x x' binding, then?

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

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> Perhaps `C-x x <letter>' would be nice for these buffer-related
> commands?  It's not exactly mnemonic, but it has a certain ring to it.
> 
> Any major packages that have claimed the `C-x x' binding, then?

Please, no.  I had a zillion bindings on prefix
key `C-x p' for Bookmark+.

Then, recently, you grabbed that key for Project,
paying no attention to my requests to please not
do that.  Maybe my packages don't count for you
as "any major packages", but they count to me.

When you did that, I moved all of my `C-x p' keys
to prefix key `C-x x'.  And now?  You want to
take over `C-x x' also.

When will this stop?  Can't we please have a
_moratorium__ on Emacs using up, with default
bindings, the few remaining unused keys?

You guys are now desperately _looking_ for some
commands that you might be able to clump together
on a prefix key, just because you've decided to
waste a default binding on `revert-buffer'.

You have a solution in search of a problem.

35+ years Emacs lived without a default binding
for `revert-buffer'.  Now, suddenly you can't
do without one.
___


https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkPrefixKeys
___


Global Bindings Starting With C-x x:
key             binding
---             -------

C-x x C-b       bmkp-previous-bookmark-repeat
C-x x C-f       bmkp-next-bookmark-repeat
C-x x C-j       bmkp-jump-to-list
C-x x C-k       bmkp-delete-bookmarks
C-x x C-l       bmkp-switch-to-bookmark-file-this-file/buffer
C-x x RET       bmkp-toggle-autonamed-bookmark-set/delete
C-x x C-n       bmkp-next-bookmark-this-file/buffer-repeat
C-x x C-p       bmkp-previous-bookmark-this-file/buffer-repeat
C-x x C-s       bmkp-save-bookmarks-this-file/buffer
C-x x C-u       bmkp-unlight-bookmark-here
C-x x ESC       Prefix Command
C-x x ,         bmkp-this-file/buffer-bmenu-list
C-x x 0         bmkp-empty-file
C-x x 2         bmkp-clone-bookmark
C-x x 5         bookmark-jump-other-frame
C-x x :         bmkp-choose-navlist-of-type
C-x x =         bmkp-bookmarks-lighted-at-point
C-x x ?         bmkp-describe-bookmark-lighted-here
C-x x B         bmkp-choose-navlist-from-bookmark-list
C-x x E         bmkp-edit-bookmark-record
C-x x H         bmkp-light-bookmarks
C-x x I         bookmark-insert-location
C-x x K         bmkp-set-desktop-bookmark
C-x x L         bmkp-switch-bookmark-file-create
C-x x M         bookmark-set-no-overwrite
C-x x N         bmkp-navlist-bmenu-list
C-x x U         bmkp-unlight-bookmarks
C-x x a         Prefix Command
C-x x b         bmkp-previous-bookmark-repeat
C-x x c         Prefix Command
C-x x d         bookmark-delete
C-x x e         edit-bookmarks
C-x x f         bmkp-next-bookmark-repeat
C-x x g         bookmark-jump
C-x x h         bmkp-light-bookmark-this-buffer
C-x x i         bookmark-insert
C-x x j         bookmark-jump
C-x x l         bookmark-load
C-x x m         bmkp-bookmark-set-confirm-overwrite
C-x x n         bmkp-next-bookmark-this-file/buffer-repeat
C-x x o         bookmark-jump-other-window
C-x x p         bmkp-previous-bookmark-this-file/buffer-repeat
C-x x q         bookmark-jump-other-window
C-x x r         bmkp-edit-bookmark-name-and-location
C-x x s         bookmark-save
C-x x t         Prefix Command
C-x x u         bmkp-unlight-bookmark-this-buffer
C-x x w         bookmark-write
C-x x x         bmkp-toggle-autotemp-on-set
C-x x y         bmkp-set-bookmark-file-bookmark
C-x x <C-down>  bmkp-next-lighted-this-buffer-repeat
C-x x <C-up>    bmkp-previous-lighted-this-buffer-repeat
C-x x <delete>                  bmkp-delete-bookmarks
C-x x <deletechar>              bmkp-delete-bookmarks
C-x x <deleteline>              bmkp-delete-bookmarks
C-x x <down>                    bmkp-next-bookmark-this-file/buffer-repeat
C-x x <kp-delete>               bmkp-delete-bookmarks
C-x x <left>                    bmkp-previous-bookmark-repeat
C-x x <next>                    bmkp-next-bookmark-w32-repeat
C-x x <prior>                   bmkp-previous-bookmark-w32-repeat
C-x x <right>                   bmkp-next-bookmark-repeat
C-x x <up>      bmkp-previous-bookmark-this-file/buffer-repeat
C-x x <wheel-down>              bmkp-next-bookmark-this-file/buffer-repeat
C-x x <wheel-up>                bmkp-previous-bookmark-this-file/buffer-repeat

C-x x t C-y     bmkp-paste-add-tags
C-x x t ESC     Prefix Command
C-x x t +       Prefix Command
C-x x t -       Prefix Command
C-x x t 0       bmkp-remove-all-tags
C-x x t V       bmkp-set-tag-value-for-navlist
C-x x t c       bmkp-copy-tags
C-x x t d       bmkp-remove-tags-from-all
C-x x t e       bmkp-edit-tags
C-x x t l       bmkp-list-all-tags
C-x x t p       bmkp-paste-add-tags
C-x x t q       bmkp-paste-replace-tags
C-x x t r       bmkp-rename-tag
C-x x t v       bmkp-set-tag-value

C-x x c C-k     bmkp-wrap-bookmark-with-last-kbd-macro
C-x x c RET     bmkp-toggle-autonamed-bookmark-set/delete
C-x x c ESC     Prefix Command
C-x x c F       bmkp-make-function-bookmark
C-x x c K       bmkp-set-desktop-bookmark
C-x x c M       bookmark-set
C-x x c a       bmkp-autofile-set
C-x x c f       bmkp-file-target-set
C-x x c m       bmkp-bookmark-set-confirm-overwrite
C-x x c s       bmkp-set-sequence-bookmark
C-x x c u       bmkp-url-target-set
C-x x c y       bmkp-set-bookmark-file-bookmark

C-x x a B       bmkp-annotate-all-bookmarks-this-file/buffer
C-x x a S       bookmark-show-all-annotations
C-x x a a       bmkp-annotate-bookmark
C-x x a b       bmkp-annotate-bookmark-this-file/buffer
C-x x a e       bookmark-edit-annotation
C-x x a s       bookmark-show-annotation

C-x x M-w       bmkp-set-snippet-bookmark

C-x x t M-w     bmkp-copy-tags

C-x x t - a     bmkp-untag-a-file
C-x x t - b     bmkp-remove-tags

C-x x t + a     bmkp-tag-a-file
C-x x t + b     bmkp-add-tags

C-x x c M-w     bmkp-set-snippet-bookmark

Re: [External] : Re: Concern about new binding.

[Karl Fogel]

Drew is making a good point here (I realize he sounds a bit 
annoyed, but I can sympathize).  His proposal make sense -- or at 
any rate, there's a good proposal easily derived from what he's 
saying.

If Emacs were to declare that from this point forward it will 
leave all currently-unbound `C-x LETTER' unbound, and *recommend* 
that packages not bind them by default either, then we'd have a 
few more very convenient keybindings left over for users.

A package could still suggest `C-x SOME-SPECIFIC-LETTER' as a 
binding for some entry point in the package, and even provide 
convenience mechanisms to cause that binding to happen.

We can't easil survey users about their bindings, but anecdotally 
it seem like a lot of people -- not only Drew -- have been using 
those last few remaining slots under `C-x' for their own favorite 
things.  (The fact that some packages also use that space is a 
clue that people consider that space to be desirable real estate 
in the mental keymap universe.)

This isn't about Magit per se -- it's bigger than Magit.  However, 
this proposal would make it somewhat more okay for Magit to 
continue binding `C-x g' by default too.  While Magit wouldn't be 
following the new recommendation either, at least Magit would not 
have to worry about clobbering some existing binding.  Given that 
Magit is so popular and so many people are accustomed to that 
binding already, this is still a decent outcome in the specific 
case of Magit anyway.  (The fact that Magit also binds `C-x M-g' 
by default is a separate headache, but that doesn't have to be 
resolved for this proposal to be considered.)

These days, when we decide to make a new global function binding 
in default Emacs, it's hard to imagine how the new binding could 
be *so* important that it must take over one of the existing free 
convenient slots and yet somehow not be important enough for us to 
just replace some other less important binding (thus leaving the 
free space free). 

I'm not saying that scenario couldn't happen, but it's going to be 
rare.  It's certainly not happening in the case of 
`revert-buffer'.  I mean, let's ask ourselves: if having 
`revert-buffer' on a convenient key isn't important enough to 
replace some other little-used binding, how on earth can it be 
important enough to replace one of the free bindings?  After all, 
those free bindings aren't *actually* free -- users are using them 
for lots of things of their own choosing!

Emacs has always rewarded users who learn to customize their 
keybindings.  Let's make it possible for that reward to be as 
large as possible by guaranteeing them some conveniently free 
slots for their favorite functions and keymap prefixes.

The `C-c LETTER' space is great, but it's only 26 letters.  I used 
them up long ago, and I'm sure I'm not alone.  Having 4 or 5 more 
letters under `C-x' would be a significant boost.

Best regards, -Karl 

On 05 Feb 2021, Drew Adams wrote:
>> Perhaps `C-x x <letter>' would be nice for these buffer-related
>> commands?  It's not exactly mnemonic, but it has a certain ring to it.
>> 
>> Any major packages that have claimed the `C-x x' binding, then?
>
>Please, no.  I had a zillion bindings on prefix
>key `C-x p' for Bookmark+.
>
>Then, recently, you grabbed that key for Project,
>paying no attention to my requests to please not
>do that.  Maybe my packages don't count for you
>as "any major packages", but they count to me.
>
>When you did that, I moved all of my `C-x p' keys
>to prefix key `C-x x'.  And now?  You want to
>take over `C-x x' also.
>
>When will this stop?  Can't we please have a
>_moratorium__ on Emacs using up, with default
>bindings, the few remaining unused keys?
>
>You guys are now desperately _looking_ for some
>commands that you might be able to clump together
>on a prefix key, just because you've decided to
>waste a default binding on `revert-buffer'.
>
>You have a solution in search of a problem.
>
>35+ years Emacs lived without a default binding
>for `revert-buffer'.  Now, suddenly you can't
>do without one.
>___
>
>
>https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkPrefixKeys
>___
>
>
>Global Bindings Starting With C-x x:
>key             binding
>---             -------
>
>C-x x C-b       bmkp-previous-bookmark-repeat
>C-x x C-f       bmkp-next-bookmark-repeat
>C-x x C-j       bmkp-jump-to-list
>C-x x C-k       bmkp-delete-bookmarks
>C-x x C-l       bmkp-switch-to-bookmark-file-this-file/buffer
>C-x x RET       bmkp-toggle-autonamed-bookmark-set/delete
>C-x x C-n       bmkp-next-bookmark-this-file/buffer-repeat
>C-x x C-p       bmkp-previous-bookmark-this-file/buffer-repeat
>C-x x C-s       bmkp-save-bookmarks-this-file/buffer
>C-x x C-u       bmkp-unlight-bookmark-here
>C-x x ESC       Prefix Command
>C-x x ,         bmkp-this-file/buffer-bmenu-list
>C-x x 0         bmkp-empty-file
>C-x x 2         bmkp-clone-bookmark
>C-x x 5         bookmark-jump-other-frame
>C-x x :         bmkp-choose-navlist-of-type
>C-x x =         bmkp-bookmarks-lighted-at-point
>C-x x ?         bmkp-describe-bookmark-lighted-here
>C-x x B         bmkp-choose-navlist-from-bookmark-list
>C-x x E         bmkp-edit-bookmark-record
>C-x x H         bmkp-light-bookmarks
>C-x x I         bookmark-insert-location
>C-x x K         bmkp-set-desktop-bookmark
>C-x x L         bmkp-switch-bookmark-file-create
>C-x x M         bookmark-set-no-overwrite
>C-x x N         bmkp-navlist-bmenu-list
>C-x x U         bmkp-unlight-bookmarks
>C-x x a         Prefix Command
>C-x x b         bmkp-previous-bookmark-repeat
>C-x x c         Prefix Command
>C-x x d         bookmark-delete
>C-x x e         edit-bookmarks
>C-x x f         bmkp-next-bookmark-repeat
>C-x x g         bookmark-jump
>C-x x h         bmkp-light-bookmark-this-buffer
>C-x x i         bookmark-insert
>C-x x j         bookmark-jump
>C-x x l         bookmark-load
>C-x x m         bmkp-bookmark-set-confirm-overwrite
>C-x x n         bmkp-next-bookmark-this-file/buffer-repeat
>C-x x o         bookmark-jump-other-window
>C-x x p         bmkp-previous-bookmark-this-file/buffer-repeat
>C-x x q         bookmark-jump-other-window
>C-x x r         bmkp-edit-bookmark-name-and-location
>C-x x s         bookmark-save
>C-x x t         Prefix Command
>C-x x u         bmkp-unlight-bookmark-this-buffer
>C-x x w         bookmark-write
>C-x x x         bmkp-toggle-autotemp-on-set
>C-x x y         bmkp-set-bookmark-file-bookmark
>C-x x <C-down>  bmkp-next-lighted-this-buffer-repeat
>C-x x <C-up>    bmkp-previous-lighted-this-buffer-repeat
>C-x x <delete>                  bmkp-delete-bookmarks
>C-x x <deletechar>              bmkp-delete-bookmarks
>C-x x <deleteline>              bmkp-delete-bookmarks
>C-x x <down>                    bmkp-next-bookmark-this-file/buffer-repeat
>C-x x <kp-delete>               bmkp-delete-bookmarks
>C-x x <left>                    bmkp-previous-bookmark-repeat
>C-x x <next>                    bmkp-next-bookmark-w32-repeat
>C-x x <prior>                   bmkp-previous-bookmark-w32-repeat
>C-x x <right>                   bmkp-next-bookmark-repeat
>C-x x <up>      bmkp-previous-bookmark-this-file/buffer-repeat
>C-x x <wheel-down>              bmkp-next-bookmark-this-file/buffer-repeat
>C-x x <wheel-up>                bmkp-previous-bookmark-this-file/buffer-repeat
>
>C-x x t C-y     bmkp-paste-add-tags
>C-x x t ESC     Prefix Command
>C-x x t +       Prefix Command
>C-x x t -       Prefix Command
>C-x x t 0       bmkp-remove-all-tags
>C-x x t V       bmkp-set-tag-value-for-navlist
>C-x x t c       bmkp-copy-tags
>C-x x t d       bmkp-remove-tags-from-all
>C-x x t e       bmkp-edit-tags
>C-x x t l       bmkp-list-all-tags
>C-x x t p       bmkp-paste-add-tags
>C-x x t q       bmkp-paste-replace-tags
>C-x x t r       bmkp-rename-tag
>C-x x t v       bmkp-set-tag-value
>
>C-x x c C-k     bmkp-wrap-bookmark-with-last-kbd-macro
>C-x x c RET     bmkp-toggle-autonamed-bookmark-set/delete
>C-x x c ESC     Prefix Command
>C-x x c F       bmkp-make-function-bookmark
>C-x x c K       bmkp-set-desktop-bookmark
>C-x x c M       bookmark-set
>C-x x c a       bmkp-autofile-set
>C-x x c f       bmkp-file-target-set
>C-x x c m       bmkp-bookmark-set-confirm-overwrite
>C-x x c s       bmkp-set-sequence-bookmark
>C-x x c u       bmkp-url-target-set
>C-x x c y       bmkp-set-bookmark-file-bookmark
>
>C-x x a B       bmkp-annotate-all-bookmarks-this-file/buffer
>C-x x a S       bookmark-show-all-annotations
>C-x x a a       bmkp-annotate-bookmark
>C-x x a b       bmkp-annotate-bookmark-this-file/buffer
>C-x x a e       bookmark-edit-annotation
>C-x x a s       bookmark-show-annotation
>
>C-x x M-w       bmkp-set-snippet-bookmark
>
>C-x x t M-w     bmkp-copy-tags
>
>C-x x t - a     bmkp-untag-a-file
>C-x x t - b     bmkp-remove-tags
>
>C-x x t + a     bmkp-tag-a-file
>C-x x t + b     bmkp-add-tags
>
>C-x x c M-w     bmkp-set-snippet-bookmark

Re: [External] : Re: Concern about new binding.

[Jose A. Ortega Ruiz]

On Thu, Feb 04 2021, Karl Fogel wrote:

[...]

> Emacs has always rewarded users who learn to customize their
> keybindings.  Let's make it possible for that reward to be as large as
> possible by guaranteeing them some conveniently free slots for their
> favorite functions and keymap prefixes.

I honestly don't understand this reasoning.  Please bear with me.

Say today you have C-x g bound to a favourite command of yours.  How
would emacs 28 binding it by default to revert-buffer interfere with
your emacs usage?  Would that limit you in any way?  Chances are you
won't even notice (if you're setting it unconditionally in your
init.el).

By contrast, by our prohibiting binding any subset of keys to anything
at all, users who don't (or can't) customize their emacses will never
have any use for those "free" bindings, and will never have a more
convenient way of accessing, say, revert-buffer.

How are we making user's lives more convenient by prohibiting to emacs
maintainers (or library writers, for that matter) to use any currently
unbound slot for a new binding?

jao
-- 
We are usually convinced more easily by reasons we have found
ourselves than by those which have occurred to others.
  -Blaise Pascal, philosopher and mathematician (1623-1662)

Re: [External] : Re: Concern about new binding.

[Karl Fogel]

On 05 Feb 2021, Jose A. Ortega Ruiz wrote:
>I honestly don't understand this reasoning.  Please bear with me. 
>Say today you have C-x g bound to a favourite command of yours. 
>How would emacs 28 binding it by default to revert-buffer 
>interfere with your emacs usage?  Would that limit you in any 
>way?  Chances are you won't even notice (if you're setting it 
>unconditionally in your init.el).   By contrast, by our 
>prohibiting binding any subset of keys to anything at all, users 
>who don't (or can't) customize their emacses will never have any 
>use for those "free" bindings, and will never have a more 
>convenient way of accessing, say, revert-buffer.   How are we 
>making user's lives more convenient by prohibiting to emacs 
>maintainers (or library writers, for that matter) to use any 
>currently unbound slot for a new binding? 

Ah, I can answer this.  It has to do with protecting investment.

When I custom-bind a command to a key, I am making an investment 
in finger memory.  For example, I have `revert-buffer' on `C-c r' 
(because I use `revert-buffer' a lot), and I chose `C-c r' 
precisely because it was in the reserved space for user-chosen 
keybindings.  That way I could be sure Emacs would never bind some 
other useful new function there.

Imagine if Emacs *were* to bind some other useful new function 
there by default.  Then I would face a hard choice: give up my 
finger memory for `revert-buffer' (by moving my binding for it to 
somewhere else), or custom-bind Emacs's new useful function to 
some key different than where Emacs wanted to put it.

Neither option is attractive.  The reason why the former option is 
bad is obvious.  But the reason why the latter option is bad is 
maybe a little bit more subtle:

Every such decision (to move a default Emacs keybinding to 
somewhere else) will cause me to diverge a bit further from 
default Emacs, and that divergence has overhead costs.  For 
example, when teaching others or talking about Emacs with them, 
now my Emacs's default bindings are slightly different from 
theirs, which will cause confusion.  Or sometimes I have to 
operate temporarily on a remote machine where my .emacs isn't 
available.  Or I'm reading someone's post on emacs-devel and they 
talk about invoking a command by naming the keystroke they used, 
and I have to figure out what command they meant.  Etc.

So this is why I stopped overriding keybindings in Emacs's default 
space years ago.  Now I (mostly) limit myself to the `C-c LETTER' 
universe, and in some cases made prefix maps there.

I wouldn't want to conditionally bind a custom function to 'C-x g' 
even when the binding I am replacing is one I don't care about 
(imagine, for the sake of discussion, that I don't care about 
`revert-buffer').  First of all, divergence has inherent costs as 
explained above.  Second, Emacs might some day replace the binding 
that I don't care about with one that I like, and then I would 
face the choice where if I want to make a new finger-memory in the 
default keyspace, I would have to change an existing 
finger-memory.

Whereas if Emacs promises never to bind something I might care 
about on a key, then I'm free to make finger-memory investments in 
that key, secure in the knowledge that the only potential source 
of future hard choices will be me (well, me and maybe some 
third-party package maintainers), not Emacs itself.

Does that explain better why I want Emacs to declare that it will 
never use certain convenient and currently-empty keybindings by 
default?

Best regards,
-Karl

Re: [External] : Re: Concern about new binding.

[jao]

On Fri, Feb 05 2021, Karl Fogel wrote:

> On 05 Feb 2021, Jose A. Ortega Ruiz wrote:
> Ah, I can answer this.  It has to do with protecting investment.
>
> When I custom-bind a command to a key, I am making an investment
> in finger memory.  For example, I have `revert-buffer' on `C-c r'
> (because I use `revert-buffer' a lot), and I chose `C-c r'
> precisely because it was in the reserved space for user-chosen
> keybindings.  That way I could be sure Emacs would never bind some
> other useful new function there.
>
> Imagine if Emacs *were* to bind some other useful new function
> there by default.  Then I would face a hard choice: give up my
> finger memory for `revert-buffer' (by moving my binding for it to
> somewhere else), or custom-bind Emacs's new useful function to
> some key different than where Emacs wanted to put it.

Oh, but "moving the binding of revert-buffer" is not what we're
discussing. We're discussing (or, well, /i/ was discussing, perhaps i
misunderstood) assigning a currently unbound command to a currently
unassigned key.

> Every such decision (to move a default Emacs keybinding to
> somewhere else) will cause me to diverge a bit further from
> default Emacs,

Yes, i agree that /moving/ an already assigned binding to a "free" key
is a bad idea.  I was thinking of creating new ones.

> and that divergence has overhead costs.  For example, when teaching
> others or talking about Emacs with them, now my Emacs's default
> bindings are slightly different from theirs, which will cause
> confusion.  Or sometimes I have to operate temporarily on a remote
> machine where my .emacs isn't available.

I think that especially in that scenario (no .emacs available) i'd
prefer this new command to be bound somewhere, be it reserved or not,
because without your .emacs and without allowing emacs to occupy it,
those "free" bindings won't be available to anyone.

> Or I'm reading someone's post on emacs-devel and they
> talk about invoking a command by naming the keystroke they used,
> and I have to figure out what command they meant.  Etc.
>
> So this is why I stopped overriding keybindings in Emacs's default
> space years ago.  Now I (mostly) limit myself to the `C-c LETTER'
> universe, and in some cases made prefix maps there.
>
> I wouldn't want to conditionally bind a custom function to 'C-x g'
> even when the binding I am replacing is one I don't care about
> (imagine, for the sake of discussion, that I don't care about
> `revert-buffer').  First of all, divergence has inherent costs as
> explained above.

Well, i gladly diverge in that sense, and occupy any existing binding
that i never use with a personal one that i use 10 times an hour (or
even once a day, or a week).  And, at the same time, i'd rather see
(say) C-x r bound to a command that the emacs maintainers find useful,
than empty--on behalf of vanilla emacs users without heavy
customizations (which include, i suppose, a majority of newbies).

> Second, Emacs might some day replace the binding that I don't care
> about with one that I like, and then I would face the choice where if
> I want to make a new finger-memory in the default keyspace, I would
> have to change an existing finger-memory.

Yes, replacing is bad, we agree on that.  (I hope i'm right and
replacing was never on the table).

> Whereas if Emacs promises never to bind something I might care
> about on a key, then I'm free to make finger-memory investments in
> that key, secure in the knowledge that the only potential source
> of future hard choices will be me (well, me and maybe some
> third-party package maintainers), not Emacs itself.
>
> Does that explain better why I want Emacs to declare that it will
> never use certain convenient and currently-empty keybindings by
> default?

Yes, thank you.  I hope i've also been able to clarify a bit my (in some
ways, opposite) perspective (BTW, for 3rd-party libraries, my stance is
quite different; i think they should never define any top-level
keybinding, and put instead all their commands in a keymap with a
configurable prefix, whose value would be asked on first interactive
use, informing the user of what commands her prefix choice is
overriding.  but that's wishful thinking :)).

Cheers,
jao
-- 
He is a hard man who is only just, and a sad one who is only
wise. -Voltaire, philosopher (1694-1778)

Re: [External] : Re: Concern about new binding.

[Karl Fogel]

On 06 Feb 2021, jao wrote:
>On Fri, Feb 05 2021, Karl Fogel wrote: 
>> On 05 Feb 2021, Jose A. Ortega Ruiz wrote: Ah, I can answer 
>> this.  It has to do with protecting investment. 
>> 
>> When I custom-bind a command to a key, I am making an 
>> investment in finger memory.  For example, I have 
>> `revert-buffer' on `C-c r' (because I use `revert-buffer' a 
>> lot), and I chose `C-c r' precisely because it was in the 
>> reserved space for user-chosen keybindings.  That way I could 
>> be sure Emacs would never bind some other useful new function 
>> there. 
>> 
>> Imagine if Emacs *were* to bind some other useful new function 
>> there by default.  Then I would face a hard choice: give up my 
>> finger memory for `revert-buffer' (by moving my binding for it 
>> to somewhere else), or custom-bind Emacs's new useful function 
>> to some key different than where Emacs wanted to put it. 
> Oh, but "moving the binding of revert-buffer" is not what we're 
>discussing. We're discussing (or, well, /i/ was discussing, 
>perhaps i misunderstood) assigning a currently unbound command to 
>a currently unassigned key. 

Sure, but my answer to your question is still the same answer.

I'm arguing that Emacs make explicit commitments about keeping 
some keyspaces free in the default distribution, in order to favor 
users who are likely to make long-term investments in custom 
keybindings.

It already does this with `C-c LETTER', of course.  I'm just 
saying let's make the same commitment a few more places.  The 
justification for this would be to create more places where users 
will feel safe to make finger-memory investments.

>> Every such decision (to move a default Emacs keybinding to 
>> somewhere else) will cause me to diverge a bit further from 
>> default Emacs, 
> Yes, i agree that /moving/ an already assigned binding to a 
>"free" key is a bad idea.  I was thinking of creating new ones. 

I hope it was clear, but just in case it wasn't: my paragraph was 
talking about *me*, the user, moving a recently-changed default 
Emacs keybinding to somewhere else, just in my Emacs, in order to 
preserve a custom binding in its current place.  And I was just 
explaining why even though any user is free to do this, it still 
has costs for that user, and therefore we should try to help users 
not be in the position of facing that choice.

You stated elsewhere that you think Emacs should never replace an 
existing default keybinding with a different default keybinding. 
I don't know if we have that policy, but if we do, then the 
problem I'm worried about would not exist, that's true.
 
>[...]
>
>Well, i gladly diverge in that sense, and occupy any existing 
>binding that i never use with a personal one that i use 10 times 
>an hour (or even once a day, or a week).  And, at the same time, 
>i'd rather see (say) C-x r bound to a command that the emacs 
>maintainers find useful, than empty--on behalf of vanilla emacs 
>users without heavy customizations (which include, i suppose, a 
>majority of newbies). 

This is a genuine difference of opinion, yes.  There are good 
arguments on both sides here, I think.

My argument has long been that Emacs should prioritize the needs 
of investment-oriented users.  That is, to make Emacs slightly 
worse for the investment-oriented users in order to make it better 
for those who are unlikely to invest is usually the wrong 
decision.

You wrote "newbies" above, but I think it's important to 
distinguish between two kinds of newbies: the investment-oriented 
ones, and the ones who are unlikely to invest.  Your assertion is 
true for the latter kind, but not the former.  Some newbies will 
*eventually* be highly invested users who are looking in the 
crowded keymap landscape for some free space to put their 
customizations :-).
 
>Yes, thank you.  I hope i've also been able to clarify a bit my 
>(in some ways, opposite) perspective (BTW, for 3rd-party 
>libraries, my stance is quite different; i think they should 
>never define any top-level keybinding, and put instead all their 
>commands in a keymap with a configurable prefix, whose value 
>would be asked on first interactive use, informing the user of 
>what commands her prefix choice is overriding.  but that's 
>wishful thinking :)). 

Yes, you did succeed in clarifying, and I appreciate it!

Best regards,
-Karl

Re: [External] : Re: Concern about new binding.

[Jean Louis]

* Karl Fogel <kfogel@red-bean.com> [2021-02-06 02:39]:
> On 05 Feb 2021, Jose A. Ortega Ruiz wrote:
> > I honestly don't understand this reasoning.  Please bear with me. Say
> > today you have C-x g bound to a favourite command of yours. How would
> > emacs 28 binding it by default to revert-buffer interfere with your
> > emacs usage?  Would that limit you in any way?  Chances are you won't
> > even notice (if you're setting it unconditionally in your init.el).   By
> > contrast, by our prohibiting binding any subset of keys to anything at
> > all, users who don't (or can't) customize their emacses will never have
> > any use for those "free" bindings, and will never have a more convenient
> > way of accessing, say, revert-buffer.   How are we making user's lives
> > more convenient by prohibiting to emacs maintainers (or library writers,
> > for that matter) to use any currently unbound slot for a new binding?
> 
> Ah, I can answer this.  It has to do with protecting investment.
> 
> When I custom-bind a command to a key, I am making an investment in finger
> memory.  For example, I have `revert-buffer' on `C-c r' (because I use
> `revert-buffer' a lot), and I chose `C-c r' precisely because it was in the
> reserved space for user-chosen keybindings.  That way I could be sure Emacs
> would never bind some other useful new function there.

I was thinking same as you some time before until somebody on Help GNU
Emacs mailing list has shown me how person uses the prefix key.

Then I have switched my mental model of remembering the whole key on
just remembering the key coming after the prefix. Instead of {s-p p} I
would remember just that prefix is s-p and key is p separated from
each other. Now that what people call "muscle memory" has separate
slots, one for prefix and one for keys there after. If I change prefix
to {C-i i} or {C-p} now I can do whatever comes there after like {C-i
i p} or {C-p p} instead of {s-p p} without problems. I have now about
15 keys after the s-p prefix, but changing prefix would not disturb me
due to the expansion of the slots in my muscle memory. ;-)

> Every such decision (to move a default Emacs keybinding to somewhere else)
> will cause me to diverge a bit further from default Emacs, and that
> divergence has overhead costs.

Exactly. The cost on global users is much. I can imagine plethora of
bugs files in Debian GNU/Linux and other GNU/Linux distributions,
questions on Reddit and other sites where people try to find their old
default key binding. Changing very default key bindings causes more
than just a butterfly effect.

But there are those others default key bindings that are not very
defaults. Like M-z that I could not found in use in Emacs-like
editors, it was not considered important to implement it in Zile, e3,
mg.

Jean

Re: [External] : Re: Concern about new binding.

[Dmitry Gutov]

On 12.02.2021 11:07, Jean Louis wrote:
> I can imagine plethora of
> bugs files in Debian GNU/Linux and other GNU/Linux distributions,
> questions on Reddit and other sites where people try to find their old
> default key binding.

But when Emacs's audience dwindles even more due to aging and no new 
user inflow, we'll be fine.

The volume of bug reports will be going down to zero, after all.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> Drew is making a good point here (I realize he sounds a bit
> annoyed, but I can sympathize).  His proposal make sense -- or at
> any rate, there's a good proposal easily derived from what he's
> saying.
> 
> If Emacs were to declare that from this point forward it will
> leave all currently-unbound `C-x LETTER' unbound, and *recommend*
> that packages not bind them by default either, then we'd have a
> few more very convenient keybindings left over for users.
> 
> A package could still suggest `C-x SOME-SPECIFIC-LETTER' as a
> binding for some entry point in the package, and even provide
> convenience mechanisms to cause that binding to happen.
> 
> We can't easil survey users about their bindings, but anecdotally
> it seem like a lot of people -- not only Drew -- have been using
> those last few remaining slots under `C-x' for their own favorite
> things.  (The fact that some packages also use that space is a
> clue that people consider that space to be desirable real estate
> in the mental keymap universe.)
> 
> This isn't about Magit per se -- it's bigger than Magit.  However,
> this proposal would make it somewhat more okay for Magit to
> continue binding `C-x g' by default too.  While Magit wouldn't be
> following the new recommendation either, at least Magit would not
> have to worry about clobbering some existing binding.  Given that
> Magit is so popular and so many people are accustomed to that
> binding already, this is still a decent outcome in the specific
> case of Magit anyway.  (The fact that Magit also binds `C-x M-g'
> by default is a separate headache, but that doesn't have to be
> resolved for this proposal to be considered.)
> 
> These days, when we decide to make a new global function binding
> in default Emacs, it's hard to imagine how the new binding could
> be *so* important that it must take over one of the existing free
> convenient slots and yet somehow not be important enough for us to
> just replace some other less important binding (thus leaving the
> free space free).
> 
> I'm not saying that scenario couldn't happen, but it's going to be
> rare.  It's certainly not happening in the case of
> `revert-buffer'.  I mean, let's ask ourselves: if having
> `revert-buffer' on a convenient key isn't important enough to
> replace some other little-used binding, how on earth can it be
> important enough to replace one of the free bindings?  After all,
> those free bindings aren't *actually* free -- users are using them
> for lots of things of their own choosing!
> 
> Emacs has always rewarded users who learn to customize their
> keybindings.  Let's make it possible for that reward to be as
> large as possible by guaranteeing them some conveniently free
> slots for their favorite functions and keymap prefixes.
> 
> The `C-c LETTER' space is great, but it's only 26 letters.  I used
> them up long ago, and I'm sure I'm not alone.  Having 4 or 5 more
> letters under `C-x' would be a significant boost.

I agree with all that Karl wrote, and the way he
expressed it.

I would, however, emphasize a distinction between
(1) users and 3rd-party libraries and (2) the code
of vanilla Emacs.

While I think it's positive for 3rd-party libraries
to only _suggest_ such bindings, I don't think that
needs to, or should be, part of the convention.  I
think, instead, that the "rule" should just be that
vanilla Emacs should (modulo important reasons) not
grab any more such key bindings.

The problem, at least so far, and I think in general,
is not really competition for scarce keys among 3rd
party libraries.  The problem is vanilla Emacs
using up the space of possible key bindings for its
default keys.  Some library, even a very popular one
such as Magit, binding some `C-x <something>' key is
not a big problem.  Use of that library is optional.
When vanilla Emacs claims a key for a (default)
binding, that act has a lot more clout.
___

I'd also like to see such a moratorium imposed for
_all_ additional keys, not just `C-x <something>'
prefix keys, and not just other multiple-key prefix
keys.

IOW, I'd like to see vanilla Emacs try harder not
to bind new keys by default.  Keys are just too
scarce now, and users and libraries need keys too.
___

Finally, let me offer another controversial
suggestion, which could offer help in another
direction.

If we were to reexamine Emacs default key bindings
in general, at first ignoring existing habits etc.
(but later taking them into account), we could, I
think, find some existing default keys that could
helpfully be repurposed for something more useful.

In particular, we could take some keys that are
repeating (just hold down the key to repeat the
command) but that are currently wasted on
non-repeating commands, and either reassign those
keys or change their commands to in fact be
repeating.

Even more useful/important would be to take some
such keys, which could usefully be used as prefix
keys, and make them such.  Consolidate multiple
commands, which today waste multiple keys, onto
a given prefix key.

Even just a little such reconsidering/refactoring
work could provide considerable benefit.

Of course, yes, the discussion might involve
considerable churn.  It would maybe help to
start with concrete suggestion of keys that some
think might be recuperated because they're
currently a bit "wasted".

One that comes to my mind, but I offer it only
as an example, not because I care much to get
rid of its binding in particular, is `C-o'.
It's repeatable, but is it very useful?  (And
it doesn't make use of a negative prefix arg.)

There are also keys that fit well into our
mnemonic scheme, but that maybe have outlived
their usefulness - as default bindings.

I'm thinking of `C-t', for example.

Yes, I do use `C-t', and it can be handy (and
yes, you can repeat it, to transport a char
forward incrementally - but not backward).

But hey, it's a wonderful key, and frankly,
isn't it a bit wasted bound to `transpose-chars'?
Imagine it as a prefix key, or used repetitively
for something more useful than transposing chars.

Again, I don't care about `C-o' or `C-t'.  I
mention those just to give an idea.  There are,
I think, keys currently bound by default that
could be put to better use.  A refactoring of
Emacs default key bindings could free up some
key "space".

Yes, at the cost of some finger memory and habit.
And yes, we might have trouble finding consensus.
And yes, discussion could range too wide and
lead nowhere.

But it could also be a good thing to try.

Re: [External] : Re: Concern about new binding.

[Jean Louis]

* Karl Fogel <kfogel@red-bean.com> [2021-02-05 07:14]:
> The `C-c LETTER' space is great, but it's only 26 letters.  I used them up
> long ago, and I'm sure I'm not alone.  Having 4 or 5 more letters under
> `C-x' would be a significant boost.

As personal recommendation you can still use the `menu' key between
the right Ctrl and Alt as prefix (I believe it would work as prefix),
then there is Super key between Ctrl and Alt that can be used as
prefix and I use it frequently, then there is Caps Lock that can be
used as prefix.

I guess none of them would work so easily in console mode. I wish that
Emacs alone could bring solution to recognize Super key in console
mode without fiddling with system settings, that would provide many
new prefixes.

Jean

Re: [External] : Re: Concern about new binding.

[Thibaut Verron]

2021-02-12 9:53 UTC+01:00, Jean Louis <bugs@gnu.support>:
> * Karl Fogel <kfogel@red-bean.com> [2021-02-05 07:14]:
>> The `C-c LETTER' space is great, but it's only 26 letters.  I used them
>> up
>> long ago, and I'm sure I'm not alone.  Having 4 or 5 more letters under
>> `C-x' would be a significant boost.
>
> As personal recommendation you can still use the `menu' key between
> the right Ctrl and Alt as prefix (I believe it would work as prefix),
> then there is Super key between Ctrl and Alt that can be used as
> prefix and I use it frequently, then there is Caps Lock that can be
> used as prefix.
>
> I guess none of them would work so easily in console mode. I wish that
> Emacs alone could bring solution to recognize Super key in console
> mode without fiddling with system settings, that would provide many
> new prefixes.
>
> Jean

Another problem with using more modifiers is that there are other
applications than Emacs which need/define shortcuts, and they are not
necessarily as easy to remap as in Emacs. A typical example is the
window manager. In addition, international users typically need a
compose key, which takes yet another modifier.

Re: Concern about new binding.

[Juri Linkov]

> There is always the possibility to use another free C-x LETTER slot.
> The other ones are c j w x y.  (A few symbols are also free, for example #
> / % : _ !.)

Or 'C-x r v' with the mnemonics rv = ReVert.

Re: Concern about new binding.

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> There is always the possibility to use another free C-x LETTER slot.
>> The other ones are c j w x y.  (A few symbols are also free, for example #
>> / % : _ !.)
>
> Or 'C-x r v' with the mnemonics rv = ReVert.

Hm...  makes sense, but the `C-x r' keymap is mostly register commands
(with a sprinkling of bookmark commands (which are related, I guess),
and rectangle commands (which aren't))...

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

Re: Concern about new binding.

[Juri Linkov]

>> Or 'C-x r v' with the mnemonics rv = ReVert.
>
> Hm...  makes sense, but the `C-x r' keymap is mostly register commands
> (with a sprinkling of bookmark commands (which are related, I guess),
> and rectangle commands (which aren't))...

So currently `r' in `C-x r' stands for `register' and `rectangle'
that have unrelated mnemonics, and `bookmark' slightly related to
`register'.

Then adding another meaning for `r' in `C-x r' is not quite bad.

It seems the least controversial among all variants would be
`C-x r e' where "re" is the prefix of the command "re"vert-buffer
that is also free on the `C-x r' map and easier to type than `C-x r v'.

Re: Concern about new binding.

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> It seems the least controversial among all variants would be
> `C-x r e' where "re" is the prefix of the command "re"vert-buffer
> that is also free on the `C-x r' map and easier to type than `C-x r v'.

I like `C-x r e' -- it has pretty good mnemonics, and it's not too
cumbersome to type.

I also like the idea of adding a new prefix command for buffer-related
commands.  The list of proposed commands we could bind there was pretty
compelling -- it had a whole bunch of commands that (I think) people use
somewhat frequently, and grouping them that way will help with
discovery, I think.

`C-x x' seems to be in the running here, and is pretty
convenient to type.  If we go with `C-x x', then I guess `C-x x g' would
be the binding for `revert-buffer', I guess?  (To mimic the `g' in
special-mode-map.)

I asked whether `C-x x' had been claimed by any major package, and I
didn't see any response to that, so I'm guessing not?

So I'm going to do the `C-x x' thing, I think.

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

Re: Concern about new binding.

[Gregory Heytings]

>
> I asked whether `C-x x' had been claimed by any major package, and I 
> didn't see any response to that, so I'm guessing not?
>

For the record, there was one response: Drew said he recently moved his 
bookmark+ bindings from the prefix key "C-x p" to the "C-x x" prefix key, 
when "C-x p" was taken by "project".

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> I asked whether `C-x x' had been claimed by any major package,
> and I didn't see any response to that, so I'm guessing not?

What qualifies as a "major package" for you,
Lars?  I guess Bookmark+ doesn't.  What does?

> So I'm going to do the `C-x x' thing, I think.

First pushed out of `C-x p', and now `C-x x'.
What's next?

___


"How can you keep on moving unless you migrate too?
 They tell ya to keep on moving, but migrate you must not do
 The only reason for moving, and the reason why I roam
 Is to move to a new location and find myself a home"

  - Woody Guthrie

https://genius.com/Ry-cooder-how-can-you-keep-moving-unless-you-migrate-too-lyrics

Re: Concern about new binding.

[Juri Linkov]

> I like `C-x r e' -- it has pretty good mnemonics, and it's not too
> cumbersome to type.
>
> I also like the idea of adding a new prefix command for buffer-related
> commands.  The list of proposed commands we could bind there was pretty
> compelling -- it had a whole bunch of commands that (I think) people use
> somewhat frequently, and grouping them that way will help with
> discovery, I think.
>
> `C-x x' seems to be in the running here, and is pretty
> convenient to type.  If we go with `C-x x', then I guess `C-x x g' would
> be the binding for `revert-buffer', I guess?  (To mimic the `g' in
> special-mode-map.)

I don't know, what was the reason for freeing `C-x x' some time ago?
In etc/NEWS.22:

  ** The register compatibility key bindings (deprecated since Emacs 19)
  have been removed:
    C-x /   point-to-register (Use: C-x r SPC)
    C-x j   jump-to-register  (Use: C-x r j)
    C-x x   copy-to-register  (Use: C-x r s)
    C-x g   insert-register   (Use: C-x r i)

What if some package becomes popular in the future and wants to claim
the `C-x x' prefix map that has good mnemonics for it?  Such as
xwidgets.

In no one has such plans in the foreseeable future, then it would be
reasonable to use the new prefix map to bind as many keys as possible.
There are many frequently used commands that are still unbound.  Then
we could group the keys by categories, e.g.:

Buffer-related commands:
C-x x b r - revert-buffer
C-x x b R - revert-buffer-with-fine-grain
C-x x b n - rename-buffer
C-x x b u - rename-uniquely
C-x x b c - clone-buffer
C-x x b i - insert-buffer

File-related commands:
C-x x f a - append-to-file
...

Window-related commands:
C-x x w p - previous-window-any-frame
...

Re: Concern about new binding.

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> In no one has such plans in the foreseeable future, then it would be
> reasonable to use the new prefix map to bind as many keys as possible.
> There are many frequently used commands that are still unbound.  Then
> we could group the keys by categories, e.g.:
>
> Buffer-related commands:
> C-x x b r - revert-buffer
> C-x x b R - revert-buffer-with-fine-grain
> C-x x b n - rename-buffer
> C-x x b u - rename-uniquely
> C-x x b c - clone-buffer
> C-x x b i - insert-buffer
>
> File-related commands:
> C-x x f a - append-to-file

Sounds logical, but there's diminishing returns the longer the
keystrokes get.

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

Re: Concern about new binding.

[Lars Ingebrigtsen]

And I've now moved the binding to `C-x x g', which should un-annoy Magit
users.

There's been suggestions for other buffer-related commands to put on the
`C-x x' keymap, and I'm adding a few of those, too.  Feel free to make
further suggestions.

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

Re: Concern about new binding.

[Ergus]

On Sun, Feb 07, 2021 at 01:39:13PM +0100, Lars Ingebrigtsen wrote:
>And I've now moved the binding to `C-x x g', which should un-annoy Magit
>users.
>
Very thanks!!!

>There's been suggestions for other buffer-related commands to put on the
>`C-x x' keymap, and I'm adding a few of those, too.  Feel free to make
>further suggestions.
>
Maybe it makes sense (now that we have this map) to move there
read-only-mode, enable/disable-undo.

I am not formally proposing any of them, just mentioning some that could
make sense.

The first one could (in long therm of course) release `C-x C-q` for
other future purposes.

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

Re: Concern about new binding.

[Lars Ingebrigtsen]

Ergus <spacibba@aol.com> writes:

> Maybe it makes sense (now that we have this map) to move there
> read-only-mode, enable/disable-undo.
>
> I am not formally proposing any of them, just mentioning some that could
> make sense.
>
> The first one could (in long therm of course) release `C-x C-q` for
> other future purposes.

I wouldn't rule it completely out, but moving keystrokes is a touchy
subject...  and especially for something like `C-x C-q' (that I think
people have in their muscle memory), it's an uphill battle.

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

Re: Concern about new binding.

[Teemu Likonen]

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

* 2021-02-07 21:44:21+0100, Lars Ingebrigtsen wrote:

> Ergus <spacibba@aol.com> writes:
>> Maybe it makes sense (now that we have this map) to move there
>> read-only-mode, enable/disable-undo.

> I wouldn't rule it completely out, but moving keystrokes is a touchy
> subject...  and especially for something like `C-x C-q' (that I think
> people have in their muscle memory), it's an uphill battle.

read-only-mode could be added to "C-x x" map for consistency and perhaps
for easier find but the command would remain (forever?) in the old key
"C-x C-q".

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> And I've now moved the binding to `C-x x g', which should un-annoy
> Magit users.
> 
> There's been suggestions for other buffer-related commands to put on
> the `C-x x' keymap, and I'm adding a few of those, too.  Feel free to make
> further suggestions.

Please don't bind `C-x x' by default.  That's
my suggestion.

Bookmark+ uses `C-x x' (having been forced off
of `C-x p').

Re: [External] : Re: Concern about new binding.

[Ergus]

On Sun, Feb 07, 2021 at 06:43:31PM +0000, Drew Adams wrote:
>> And I've now moved the binding to `C-x x g', which should un-annoy
>> Magit users.
>>
>> There's been suggestions for other buffer-related commands to put on
>> the `C-x x' keymap, and I'm adding a few of those, too.  Feel free to make
>> further suggestions.
>
>Please don't bind `C-x x' by default.  That's
>my suggestion.
>
>Bookmark+ uses `C-x x' (having been forced off
>of `C-x p').
>
What if (just getting crazy) you consider adding some/most of the
bookmark+ functionalities to vanilla and they will go in the `C-x r` map
with the other bookmark commands (C-x r b, C-x r m and so on)???  Like
diredx for dired or and many other examples...

Even extending the current `C-x r` is a better choice than taking a
binding only for this... It will help to discover the commands when
using which-key for example and avoid the user learn and sacrifice
another prefix combination.

I don't want to argue about this, it is just a suggestion because I
wanted to use bookmark+ long time ago, but I finally never tried it
because 1) it is not in elpa or melpa or vanilla (so I will need to
manually maintain it updates) and 2) because I will have to sacrifice a
binding just for it...

It is just my opinion... 

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> What if (just getting crazy) you consider adding
> some/most of the bookmark+ functionalities to vanilla

I've offered any and all of it, multiple times, for
decades.  I've offered all of my code.

> they will go in the `C-x r` map with the other
> bookmark commands (C-x r b, C-x r m and so on)???
> Like diredx for dired or and many other examples...

There are 13 keys on `C-x r' for registers, 9 for
rectangles, and 4 for bookmarks.  Those 3 groups
don't really belong on the same prefix key, IMO.
(They could be on different prefix keys under
`C-x r' - or somewhere else.)

None of this has anything to do with the general
argument to have more keys, including prefix keys,
and including all `C-x <whatever>' prefix keys,
kept available for 3rd-party code, i.e. not bound
by default by Emacs.

Limited remaining keyspace is a problem that needs
a solution, no matter which solution someone might
prefer for it.  That problem exists independently
of any solution I might prefer for it.  It's a
problem that's essentially been ignored, so far.

> I wanted to use bookmark+ long time ago, but ...
> I will have to sacrifice a binding just for it...

No, you don't have to.  You can easily prevent any
bindings at all for its commands.  You can bind
any of its commands to any keys you like.  And you
can easily customize the prefix keys to use, even
without fiddling with key bindings: options
`bmkp-bookmark-map-prefix-keys',
`bmkp-jump-map-prefix-keys', and
`bmkp-jump-other-window-map-prefix-keys'.

(It's also fine not to use Bookmark+.)

Re: [External] : Re: Concern about new binding.

[Alfred M. Szmidt]

   There are 13 keys on `C-x r' for registers, 9 for
   rectangles, and 4 for bookmarks.  Those 3 groups
   don't really belong on the same prefix key, IMO.
   (They could be on different prefix keys under
   `C-x r' - or somewhere else.)

Once upon a time, all those lived in a different space.  E.g., the
register commands used to be on C-x s (point-to-register), C-x j
(jump-to-register), C-x x (copy-to-register) and C-x g
(insert-register).  But to consolidate all of them, and free up many
C-x N keys, they got moved to C-x r N.

Re: Concern about new binding.

[Karthik Chikmagalur]

Is the rationale for choosing `C-x x' as the prefix for buffer related
commands merely that `C-x g' is popular among magit users? Neither `C-x
g' nor `C-x x' are mnemonic for buffer-related commands, though. I can
think of a couple of alternatives, including `C-x M-b' as the prefix for
buffer commands. If there's a decision to add similar file-related
keybindings in the future (`rename-file', etc), it can neatly slot into
a `C-x M-f' keymap.

A secondary issue is the choice of keys in ctl-x-x-map:

1. `C-x x n': clone-buffer

Shouldn't this be `C-x x c' for consistency with the similar binding for
`clone-indirect-buffer-other-window' (`C-x 4 c')? The two commands are
even bound five lines apart in lisp/bindings.el!

2. `C-x x u': rename-uniquely

I would guess `u' is mostly mnemonic for undo in most users' minds. Does
this command need to be bound at all?

Lars Ingebrigtsen <larsi@gnus.org> writes:

> And I've now moved the binding to `C-x x g', which should un-annoy Magit
> users.
>
> There's been suggestions for other buffer-related commands to put on the
> `C-x x' keymap, and I'm adding a few of those, too.  Feel free to make
> further suggestions.
>
> -- 
> (domestic pets only, the antidote for overdose, milk.)
>    bloggy blog: http://lars.ingebrigtsen.no

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Tue 09 Feb 2021 at 03:22PM -08, Karthik Chikmagalur wrote:

> Is the rationale for choosing `C-x x' as the prefix for buffer related
> commands merely that `C-x g' is popular among magit users? Neither `C-x
> g' nor `C-x x' are mnemonic for buffer-related commands, though. I can
> think of a couple of alternatives, including `C-x M-b' as the prefix for
> buffer commands. If there's a decision to add similar file-related
> keybindings in the future (`rename-file', etc), it can neatly slot into
> a `C-x M-f' keymap.
>
> A secondary issue is the choice of keys in ctl-x-x-map:
>
> 1. `C-x x n': clone-buffer
>
> Shouldn't this be `C-x x c' for consistency with the similar binding for
> `clone-indirect-buffer-other-window' (`C-x 4 c')? The two commands are
> even bound five lines apart in lisp/bindings.el!

Indirect clones and non-indirect clones are quite different.

There is already a convention to use 'n' for a non-indirect clone -- see
M-n in Info-mode.

-- 
Sean Whitton

Re: Concern about new binding.

[Karthik Chikmagalur]

> Indirect clones and non-indirect clones are quite different.
>
> There is already a convention to use 'n' for a non-indirect clone -- see
> M-n in Info-mode.

I see, I was unaware of this. Thank you for letting me know.

Do you also intend to bind `C-x x c' to `clone-indirect-buffer' then?

Karthik

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Mon 15 Feb 2021 at 06:13PM -08, Karthik Chikmagalur wrote:

>> Indirect clones and non-indirect clones are quite different.
>>
>> There is already a convention to use 'n' for a non-indirect clone -- see
>> M-n in Info-mode.
>
> I see, I was unaware of this. Thank you for letting me know.
>
> Do you also intend to bind `C-x x c' to `clone-indirect-buffer' then?

Personally I'm happy with C-x 4 c but if you think it makes sense to
have both you could open a bug.

-- 
Sean Whitton

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Sat 06 Feb 2021 at 10:56AM +01, Lars Ingebrigtsen wrote:

> Juri Linkov <juri@linkov.net> writes:
>
>> It seems the least controversial among all variants would be
>> `C-x r e' where "re" is the prefix of the command "re"vert-buffer
>> that is also free on the `C-x r' map and easier to type than `C-x r v'.
>
> I like `C-x r e' -- it has pretty good mnemonics, and it's not too
> cumbersome to type.
>
> I also like the idea of adding a new prefix command for buffer-related
> commands.  The list of proposed commands we could bind there was pretty
> compelling -- it had a whole bunch of commands that (I think) people use
> somewhat frequently, and grouping them that way will help with
> discovery, I think.
>
> `C-x x' seems to be in the running here, and is pretty
> convenient to type.  If we go with `C-x x', then I guess `C-x x g' would
> be the binding for `revert-buffer', I guess?  (To mimic the `g' in
> special-mode-map.)
>
> I asked whether `C-x x' had been claimed by any major package, and I
> didn't see any response to that, so I'm guessing not?
>
> So I'm going to do the `C-x x' thing, I think.

I'm sorry for more bikeshedding, but may I suggest using C-x c instead
of C-x x?  

I just spent some time trying to repeatedly type C-x x followed by some
letter and I found that I kept typing C-x C-x by mistake.  Perhaps
others will have the same tendency.

It also has the mnemonic that C-c C-something typically act
on the current buffer, and we're talking about current buffer commands.

-- 
Sean Whitton

Re: Concern about new binding.

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Date: Sat, 06 Feb 2021 12:32:36 -0700
> Cc: Gregory Heytings <gregory@heytings.org>, emacs-devel@gnu.org
> 
> I'm sorry for more bikeshedding, but may I suggest using C-x c instead
> of C-x x?  
> 
> I just spent some time trying to repeatedly type C-x x followed by some
> letter and I found that I kept typing C-x C-x by mistake.

What will happen if you by mistake type "C-x C-c"?

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Sat 06 Feb 2021 at 09:58PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Date: Sat, 06 Feb 2021 12:32:36 -0700
>> Cc: Gregory Heytings <gregory@heytings.org>, emacs-devel@gnu.org
>>
>> I'm sorry for more bikeshedding, but may I suggest using C-x c instead
>> of C-x x?
>>
>> I just spent some time trying to repeatedly type C-x x followed by some
>> letter and I found that I kept typing C-x C-x by mistake.
>
> What will happen if you by mistake type "C-x C-c"?

Well, it's about equally as annoying, as you'll get a "Really exit
Emacs" message.

In my case this doesn't tend to happen as by the time I've moved my
fingers from being ready to type 'x' to being ready to type 'c', my
other hand has released the control key.

Just sharing my experience -- not sure whether it will apply to others.

-- 
Sean Whitton

Re: Concern about new binding.

[Eli Zaretskii]

> From: Sean Whitton <spwhitton@spwhitton.name>
> Cc: larsi@gnus.org, juri@linkov.net, gregory@heytings.org, emacs-devel@gnu.org
> Date: Sat, 06 Feb 2021 13:09:40 -0700
> 
> > What will happen if you by mistake type "C-x C-c"?
> 
> Well, it's about equally as annoying, as you'll get a "Really exit
> Emacs" message.

By default, "C-x C-c" doesn't ask any questions, it just kills Emacs.
You may be lucky if you have live sub-processes or net connections
running, or unsaved file edits.  But what if you don't?  Puff! there
goes the session.

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Sat 06 Feb 2021 at 10:20PM +02, Eli Zaretskii wrote:

>> From: Sean Whitton <spwhitton@spwhitton.name>
>> Cc: larsi@gnus.org, juri@linkov.net, gregory@heytings.org, emacs-devel@gnu.org
>> Date: Sat, 06 Feb 2021 13:09:40 -0700
>>
>> > What will happen if you by mistake type "C-x C-c"?
>>
>> Well, it's about equally as annoying, as you'll get a "Really exit
>> Emacs" message.
>
> By default, "C-x C-c" doesn't ask any questions, it just kills Emacs.
> You may be lucky if you have live sub-processes or net connections
> running, or unsaved file edits.  But what if you don't?  Puff! there
> goes the session.

Ah, apologies, I got mixed up about the defaults.

I withdraw my C-x c suggestion.

-- 
Sean Whitton

Re: Concern about new binding.

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> I'm sorry for more bikeshedding, but may I suggest using C-x c instead
> of C-x x?  
>
> I just spent some time trying to repeatedly type C-x x followed by some
> letter and I found that I kept typing C-x C-x by mistake.  Perhaps
> others will have the same tendency.
>
> It also has the mnemonic that C-c C-something typically act
> on the current buffer, and we're talking about current buffer commands.

After trying it a bit, `C-x c' is indeed a bit easier to type than
`C-x x', but as Eli says, it's a bit more dangerous...  At least
`C-x C-x' is a harmless command.

But speaking of `C-c' -- I just tried `C-c C-h' (to get a list of
bindings under `C-c'), and all I got was:

Global Bindings Starting With C-c:
key             binding
---             -------

And nothing more.  Same for `C-c C-x C-h'.  And it's this way in Emacs
25.1, too...

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

Re: Concern about new binding.

[Gregory Heytings]

>
> But speaking of `C-c' -- I just tried `C-c C-h' (to get a list of 
> bindings under `C-c'), and all I got was:
>
> Global Bindings Starting With C-c:
> key             binding
> ---             -------
>
> And nothing more.  Same for `C-c C-x C-h'.  And it's this way in Emacs 
> 25.1, too...
>

C-c is a restricted key, C-c LETTER is for users, C-c C-LETTER is for 
major modes, C-c SYMBOL is for minor modes.  By definition none of these 
can go in the (default) global-map.  If you type C-c C-h in a buffer 
visiting a C file you'll see some bindings, but still no global bindings.

Re: Concern about new binding.

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> And nothing more.  Same for `C-c C-x C-h'.  And it's this way in
>> Emacs 25.1, too...
>
> C-c is a restricted key, C-c LETTER is for users, C-c C-LETTER is for
> major modes, C-c SYMBOL is for minor modes.  By definition none of
> these can go in the (default) global-map.  If you type C-c C-h in a
> buffer visiting a C file you'll see some bindings, but still no global
> bindings.

Right.  That `C-c C-x' doesn't signal an error is somewhat odd,
though (which was the one I was really wondering about).

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

Re: Concern about new binding.

[Gregory Heytings]

>>> And nothing more.  Same for `C-c C-x C-h'.  And it's this way in Emacs 
>>> 25.1, too...
>>
>> C-c is a restricted key, C-c LETTER is for users, C-c C-LETTER is for 
>> major modes, C-c SYMBOL is for minor modes.  By definition none of 
>> these can go in the (default) global-map.  If you type C-c C-h in a 
>> buffer visiting a C file you'll see some bindings, but still no global 
>> bindings.
>
> Right.  That `C-c C-x' doesn't signal an error is somewhat odd, though 
> (which was the one I was really wondering about).
>

Indeed.  It seems that C-x is considered as a prefix key when it is not 
defined.  C-x 8 C-x, C-x n C-x, M-g C-x or M-s C-x do the same, for 
example.

Re: Concern about new binding.

[Andreas Schwab]

On Feb 06 2021, Lars Ingebrigtsen wrote:

> That `C-c C-x' doesn't signal an error is somewhat odd, though

Because C-x is a prefix key on the key-translation-map.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Sat 06 Feb 2021 at 09:37PM +01, Lars Ingebrigtsen wrote:

> Sean Whitton <spwhitton@spwhitton.name> writes:
>
>> I'm sorry for more bikeshedding, but may I suggest using C-x c instead
>> of C-x x?
>>
>> I just spent some time trying to repeatedly type C-x x followed by some
>> letter and I found that I kept typing C-x C-x by mistake.  Perhaps
>> others will have the same tendency.
>>
>> It also has the mnemonic that C-c C-something typically act
>> on the current buffer, and we're talking about current buffer commands.
>
> After trying it a bit, `C-x c' is indeed a bit easier to type than
> `C-x x', but as Eli says, it's a bit more dangerous...  At least
> `C-x C-x' is a harmless command.
>
> But speaking of `C-c' -- I just tried `C-c C-h' (to get a list of
> bindings under `C-c'), and all I got was:
>
> Global Bindings Starting With C-c:
> key             binding
> ---             -------
>
> And nothing more.  Same for `C-c C-x C-h'.  And it's this way in Emacs
> 25.1, too...

But those are reserved for major modes, right?  Or did you have
something else in mind?

-- 
Sean Whitton

Re: Concern about new binding.

[Thibaut Verron]

2021-02-05 9:59 UTC+01:00, Lars Ingebrigtsen <larsi@gnus.org>:
> Juri Linkov <juri@linkov.net> writes:
>
>>> There is always the possibility to use another free C-x LETTER slot.
>>> The other ones are c j w x y.  (A few symbols are also free, for example
>>> #
>>> / % : _ !.)
>>
>> Or 'C-x r v' with the mnemonics rv = ReVert.
>
> Hm...  makes sense, but the `C-x r' keymap is mostly register commands
> (with a sprinkling of bookmark commands (which are related, I guess),
> and rectangle commands (which aren't))...

I believe the relation to rectangle commands is copy-rectangle-to-register.

Re: Concern about new binding.

[Dmitry Gutov]

On 05.02.2021 00:24, Juri Linkov wrote:
> Or 'C-x r v' with the mnemonics rv = ReVert.

I quite like this one. Or 'C-x r e'.

For reasons already mentioned, I'd prefer if 'C-x g' was kept free.

Re: Concern about new binding.

[Jose A. Ortega Ruiz]

> There is always the possibility to use another free C-x LETTER slot.
> The other ones are c j w x y.  (A few symbols are also free, for
> example # / % : _ !.)

Given that C-/ is undo, i would find it easier to remember C-x / as
revert-buffer ("undo everything", if you look at it sideways :))
than any other proposed alternative.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > There is always the possibility to use another free C-x LETTER slot.
> > The other ones are c j w x y.  (A few symbols are also free, for
> > example # / % : _ !.)
> 
> Given that C-/ is undo, i would find it easier to remember C-x / as
> revert-buffer ("undo everything", if you look at it sideways :))
> than any other proposed alternative.

And here we go again.  Not more than 4 days ago
did I write in the bug thread for this that my
library `zones.el' uses prefix key `C-x /':

  I had a zillion keys bound on prefix key `C-x p'
  (for Bookmark+), because that was free years ago.

  Then you decided to give that prefix key to "Project" 
  (saying explicitly, BTW that you "don't need" to pay
  any heed to the fact that Drew uses that prefix key,
  which is of course true).  And on and on it goes.

  I choose to use prefix `C-x /' for zones.el, but
                         ^^^^^^^
  tomorrow I may find that some part of Emacs has been
  given that key.

Tomorrow has arrived...  So disappointing.
___

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=46151#61
___

How about Emacs just stops binding keys by default?
How about leaving what's left _without_ default
bindings?

Or will Emacs developers realize the importance of
this conservation only when there are no keys left?

(Why does this remind me of those who want to open
wilderness to private development?  And those who
settled in areas they claim had no inhabitants?)

Emacs doesn't need any more default key bindings.

Put differently, there will _always_ be things that
could be bound to keys.  Emacs will be adding commands
forever.  Users and 3rd-party libraries also need keys.

Re: [External] : Re: Concern about new binding.

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

  > > Given that C-/ is undo, i would find it easier to remember C-x / as
  > > revert-buffer ("undo everything", if you look at it sideways :))
  > > than any other proposed alternative.

Perhaps we should make C-x / a prefix key.
But I am not arguing for this (or any other choice).
I am only mentioning it as an additional alternative.

-- 
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: Concern about new binding.

[Lars Ingebrigtsen]

"Jose A. Ortega Ruiz" <jao@gnu.org> writes:

> Given that C-/ is undo, i would find it easier to remember C-x / as
> revert-buffer ("undo everything", if you look at it sideways :))
> than any other proposed alternative.

It's a convenient keystroke on US keyboards, but on other national
keyboards, / is hidden away in inconvenient places like S-7, and
`C-x S-7' is pretty awkward to type.

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

Re: Concern about new binding.

[jao]

On Fri, Feb 05 2021, Lars Ingebrigtsen wrote:

> "Jose A. Ortega Ruiz" <jao@gnu.org> writes:
>
>> Given that C-/ is undo, i would find it easier to remember C-x / as
>> revert-buffer ("undo everything", if you look at it sideways :))
>> than any other proposed alternative.
>
> It's a convenient keystroke on US keyboards, but on other national
> keyboards, / is hidden away in inconvenient places like S-7, and
> `C-x S-7' is pretty awkward to type.

I see.  That's a good point.  Not that it matters much, but my second
vote was going to be for `C-x g g' (although there's the Magit
situation, funny how 3rd party libraries get a free pass using "free"
slots ;)) or `C-x G' (because i tend to use shifted letters for
"destructive" commands--i imagine the shift as an exclamation mark (g!),
call me a schemer).

jao
-- 
May my silences become more accurate.
  -Theodore Roethke, poet (1908-1963)

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Thu 04 Feb 2021 at 05:46PM +01, Lars Ingebrigtsen wrote:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> You forgot the proposal to which the mail you are replying to
>> explicitly refers.  So I'll copy it here again: it is to make "C-x g"
>> a keymap for buffer-related operations, with in particular "C-x g r"
>> bound to revert-buffer:
>>
>> C-x g c = clone-buffer
>> C-x g d = diff-buffers
>> C-x g f = fit-frame-to-buffer
>> C-x g h = hexl-mode
>> C-x g i = insert-buffer
>> C-x g l = font-lock-mode
>> C-x g n = rename-buffer
>> C-x g r = revert-buffer
>> C-x g R = revert-buffer-with-fine-grain
>> C-x g t = toggle-truncate-lines
>
> Of the alternative key bindings proposed, I like this the best.  I'd
> prefer `C-x g g' for revert-buffer, though -- it's more in like with the
> `g' binding in `special-mode-map', and `revert-buffer' is a command
> you're likely to want to execute a number of times (in some cases),
> while the rest of these are less keyboard-mashey.

I had this thought too, C-x g g is preferable to C-x g r.

-- 
Sean Whitton

28.0.50; Move revert-buffer global binding into a prefix map

[Sean Whitton]

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

control: tag -1 + patch

On Thu 04 Feb 2021 at 05:46PM +01, Lars Ingebrigtsen wrote:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> You forgot the proposal to which the mail you are replying to
>> explicitly refers.  So I'll copy it here again: it is to make "C-x g"
>> a keymap for buffer-related operations, with in particular "C-x g r"
>> bound to revert-buffer:
>>
>> C-x g c = clone-buffer
>> C-x g d = diff-buffers
>> C-x g f = fit-frame-to-buffer
>> C-x g h = hexl-mode
>> C-x g i = insert-buffer
>> C-x g l = font-lock-mode
>> C-x g n = rename-buffer
>> C-x g r = revert-buffer
>> C-x g R = revert-buffer-with-fine-grain
>> C-x g t = toggle-truncate-lines
>
> Of the alternative key bindings proposed, I like this the best.  I'd
> prefer `C-x g g' for revert-buffer, though -- it's more in like with the
> `g' binding in `special-mode-map', and `revert-buffer' is a command
> you're likely to want to execute a number of times (in some cases),
> while the rest of these are less keyboard-mashey.

Here's a patch doing that, since this seems like a solution which
satisfies most.  Exactly what else to bind into that map I leave to
others, for now, anyway.

-- 
Sean Whitton

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Move-revert-buffer-global-binding-to-C-x-g-g.patch --]
[-- Type: text/x-diff, Size: 2094 bytes --]

From ae48c8984724013a2b145fbac32c094dd54c8f0f Mon Sep 17 00:00:00 2001
From: Sean Whitton <spwhitton@spwhitton.name>
Date: Thu, 4 Feb 2021 11:05:06 -0700
Subject: [PATCH] Move 'revert-buffer' global binding to 'C-x g g'

* lisp/bindings.el: Define ctl-x-g-map and bind 'revert-buffer' to
'C-x g g' globally.
* doc/emacs/files.texi: Replace 'C-x g' with 'C-x g g'.
* etc/NEWS: Document the change.
---
 doc/emacs/files.texi | 2 +-
 etc/NEWS             | 2 +-
 lisp/bindings.el     | 7 ++++++-
 3 files changed, 8 insertions(+), 3 deletions(-)

diff --git a/doc/emacs/files.texi b/doc/emacs/files.texi
index 12ceac800e..dbdb9d582a 100644
--- a/doc/emacs/files.texi
+++ b/doc/emacs/files.texi
@@ -927,7 +927,7 @@ Manual}).  For customizations, see the Custom group @code{time-stamp}.
 
   If you have made extensive changes to a file-visiting buffer and
 then change your mind, you can @dfn{revert} the changes and go back to
-the saved version of the file.  To do this, type @kbd{C-x g}.  Since
+the saved version of the file.  To do this, type @kbd{C-x g g}.  Since
 reverting unintentionally could lose a lot of work, Emacs asks for
 confirmation first.
 
diff --git a/etc/NEWS b/etc/NEWS
index dddc150af1..cf428621d2 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -234,7 +234,7 @@ still applies for shorter search strings, which avoids flicker in the
 search buffer due to too many matches being highlighted.
 
 +++
-** 'revert-buffer' is now bound to 'C-x g' globally.
+** 'revert-buffer' is now bound to 'C-x g g' globally.
 
 \f
 * Editing Changes in Emacs 28.1
diff --git a/lisp/bindings.el b/lisp/bindings.el
index 9ea188d1a0..3ddaf0cec1 100644
--- a/lisp/bindings.el
+++ b/lisp/bindings.el
@@ -1413,7 +1413,12 @@ if `inhibit-field-text-motion' is non-nil."
 
 (define-key ctl-x-map "z" 'repeat)
 
-(define-key ctl-x-map "g" #'revert-buffer)
+(defvar ctl-x-g-map
+  (let ((map (make-sparse-keymap)))
+    (define-key map "g" #'revert-buffer)
+    map)
+  "Keymap for subcommands of C-x g.")
+(define-key ctl-x-map "g" ctl-x-g-map)
 
 (define-key esc-map "\C-l" 'reposition-window)
 
-- 
2.29.2

bug#46300: [External] : 28.0.50; Move revert-buffer global binding into a prefix map

[Drew Adams]

> this seems like a solution which satisfies most.

Most what?  Most users?  Most users polled?

Re: bug#46300: 28.0.50; Move revert-buffer global binding into a prefix map

[Lars Ingebrigtsen]

Sean Whitton <spwhitton@spwhitton.name> writes:

> Here's a patch doing that, since this seems like a solution which
> satisfies most.  Exactly what else to bind into that map I leave to
> others, for now, anyway.

Thanks; applied to Emacs 28 (but I changed the binding to `C-x x g' to
avoid the Magit collision).

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

RE: [External] : Re: bug#46300: 28.0.50; Move revert-buffer global binding into a prefix map

[Drew Adams]

> Thanks; applied to Emacs 28 (but I changed the
> binding to `C-x x g' to avoid the Magit collision).

You traded a Bookmark+ collision for a Magit collision.

Re: Concern about new binding.

[Ergus]

On Thu, Feb 04, 2021 at 05:46:19PM +0100, Lars Ingebrigtsen wrote:
>Gregory Heytings <gregory@heytings.org> writes:
>
>> You forgot the proposal to which the mail you are replying to
>> explicitly refers.  So I'll copy it here again: it is to make "C-x g"
>> a keymap for buffer-related operations, with in particular "C-x g r"
>> bound to revert-buffer:
>>
>> C-x g c = clone-buffer
>> C-x g d = diff-buffers
>> C-x g f = fit-frame-to-buffer
>> C-x g h = hexl-mode
>> C-x g i = insert-buffer
>> C-x g l = font-lock-mode
>> C-x g n = rename-buffer
>> C-x g r = revert-buffer
>> C-x g R = revert-buffer-with-fine-grain
>> C-x g t = toggle-truncate-lines
>
>Of the alternative key bindings proposed, I like this the best.  I'd
>prefer `C-x g g' for revert-buffer, though -- it's more in like with the
>`g' binding in `special-mode-map', and `revert-buffer' is a command
>you're likely to want to execute a number of times (in some cases),
>while the rest of these are less keyboard-mashey.
>
>-- 
>(domestic pets only, the antidote for overdose, milk.)
>   bloggy blog: http://lars.ingebrigtsen.no
>
+1

Re: Concern about new binding.

[Teemu Likonen]

* 2021-02-04 17:46:19+0100, Lars Ingebrigtsen wrote:

> Gregory Heytings <gregory@heytings.org> writes:
>> C-x g c = clone-buffer
>> C-x g d = diff-buffers
>> C-x g f = fit-frame-to-buffer
>> C-x g h = hexl-mode
>> C-x g i = insert-buffer
>> C-x g l = font-lock-mode
>> C-x g n = rename-buffer
>> C-x g r = revert-buffer
>> C-x g R = revert-buffer-with-fine-grain
>> C-x g t = toggle-truncate-lines
>
> Of the alternative key bindings proposed, I like this the best. I'd
> prefer `C-x g g' for revert-buffer, though -- it's more in like with
> the `g' binding in `special-mode-map', and `revert-buffer' is a
> command you're likely to want to execute a number of times (in some
> cases), while the rest of these are less keyboard-mashey.

I like the idea of buffer key bindings behind some new "C-x
<new_letter>" map. This inspired me to add some of those to my systems
(also a binding for "hl-line-mode") and I think they are useful for many
people. My current list would be:

    C-x g c = clone-buffer
    C-x g d = diff-buffers
    C-x g h = hl-line-mode
    C-x g i = insert-buffer
    C-x g n = rename-buffer
    C-x g r = revert-buffer
    C-x g t = toggle-truncate-lines

(My system doesn't seem to have "revert-buffer-with-fine-grain".)

It would have been nicer if Magit documentation would have only
suggested user to bind "C-c g" (not "C-x g") key for "magit-status".

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

Re: Concern about new binding.

[Gregory Heytings]

>
> It would have been nicer if Magit documentation would have only 
> suggested user to bind "C-c g" (not "C-x g") key for "magit-status".
>

The Magit documentation does suggest to use "C-c g", but for 
"magit-file-dispatch", instead of "C-c M-g".

Re: Concern about new binding.

[Teemu Likonen]

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

* 2021-02-06 09:40:03+0000, Gregory Heytings wrote:

>> It would have been nicer if Magit documentation would have only 
>> suggested user to bind "C-c g" (not "C-x g") key for "magit-status".

> The Magit documentation does suggest to use "C-c g", but for
> "magit-file-dispatch", instead of "C-c M-g".

Yes, but I meant to say that key bindings are not only suggestions in
the documentation: the "C-x g" key is automatically bound to
magit-status command. It would be nicer if Magit didn't automatically
bind anything to "reserved" keymaps.

Technically global minor mode global-magit-file-mode is on by default
and it enables minor mode magit-file-mode in every Git buffer. That
minor mode binds "C-x g" and couple of others automatically.

So, user has to manually disable that, either by disabling
global-magit-file-mode (with customize, for example) or by redefining
magit-file-mode-map:

    (defvar magit-file-mode-map)
    (setq magit-file-mode-map (make-sparse-keymap))

-- 
/// Teemu Likonen - .-.. https://www.iki.fi/tlikonen/
// OpenPGP: 4E1055DC84E9DFF613D78557719D69D324539450

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

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > Could we revert the previous one then?? That's the first part of my
> > question.
> 
> I'd prefer to find a binding to which people could agree, because that
> would leave fewer people unhappy.

How do we know that?  Users haven't been polled,
have they?  Emacs users and Emacs have survived
for 35+ years without a global binding for
`revert-buffer'.  Why assume that most users now
would be happier if it had a global binding?

Re: [External] : Re: Concern about new binding.

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

  > How do we know that?  Users haven't been polled,
  > have they?  Emacs users and Emacs have survived
  > for 35+ years without a global binding for
  > `revert-buffer'.

More than that.  Over that time, how often have people
asked for such a global binding?



-- 
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: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Fri, 05 Feb 2021 00:49:22 -0500
> Cc: eliz@gnu.org, kevin.legouguec@gmail.com, stefankangas@gmail.com,
>  spacibba@aol.com, emacs-devel@gnu.org
> 
> More than that.  Over that time, how often have people
> asked for such a global binding?

We never bother ourselves with such questions; never did.  We consider
ourselves to be aware and familiar enough with the Emacs usage
landscape to make such decisions without polling users on each and
every step, because doing so would slow down development to an
unbearable crawl.  I always believed that at least part of the reasons
we were nominated as maintainers was that people trust us to be
capable of representing the bulk of Emacs users, and do it well enough
to avoid too many serious mistakes.

In a case such as this one, when one of the maintainers says "this
makes sense", I expect to hear technical arguments for or against that
(btw, only agreements were heard when the original decision in this
case was made), but I do NOT expect to hear "go ask the world because
you don't really know what you are talking about".

In all the 30 years of my uninterrupted active involvement with Emacs
development, I don't remember even a single instance of polling users
before making user-visible decisions.  (I may have missed one or two,
but it cannot be more than that.)  I'm astonished to hear such demands
now.  If this is indeed what's required from Emacs maintainers, I will
seriously consider resigning, because I cannot in good faith support
such ridiculous development practices, let alone such level of
mistrust towards my and Lars's experience and knowhow.

Re: [External] : Re: Concern about new binding.

[Thibaut Verron]

2021-02-05 9:16 UTC+01:00, Eli Zaretskii <eliz@gnu.org>:
>> From: Richard Stallman <rms@gnu.org>
>> Date: Fri, 05 Feb 2021 00:49:22 -0500
>> Cc: eliz@gnu.org, kevin.legouguec@gmail.com, stefankangas@gmail.com,
>>  spacibba@aol.com, emacs-devel@gnu.org
>>
>> More than that.  Over that time, how often have people
>> asked for such a global binding?
>
> We never bother ourselves with such questions; never did.  We consider
> ourselves to be aware and familiar enough with the Emacs usage
> landscape to make such decisions without polling users on each and
> every step, because doing so would slow down development to an
> unbearable crawl.  I always believed that at least part of the reasons
> we were nominated as maintainers was that people trust us to be
> capable of representing the bulk of Emacs users, and do it well enough
> to avoid too many serious mistakes.

I think this hits the nail right on. Some of us (myself included)
believe that this change underestimates how many Emacs users do not
consider C-x g to be a free-to-take binding.

> In a case such as this one, when one of the maintainers says "this
> makes sense", I expect to hear technical arguments for or against that
> (btw, only agreements were heard when the original decision in this
> case was made), but I do NOT expect to hear "go ask the world because
> you don't really know what you are talking about".

Without going as far as making a formal poll, I don't think it's
unreasonable to be as careful for binding a new key as we are for
rebinding an existing key.

This community has achieved a bit of a "conservative" reputation on
the latter, which may explain the surprise at how apparently
light-handed the same decision can be taken for a "free" key.

Besides, technical arguments were also brought forward: making
revert-buffer too easy-to-reach is dangerous, modes which need
frequent revert-buffer already bind it (directly or by inheriting from
special), there is auto-revert-mode, binding free keys will
necessarily break some users' configuration, the chosen key conflicts
with a major 3rd party package in a way which will break its users'
configuration.

As far as I can tell, the suggestion of a poll was only metaphorical,
as in "do we really need this in view of the drawbacks?".

> In all the 30 years of my uninterrupted active involvement with Emacs
> development, I don't remember even a single instance of polling users
> before making user-visible decisions.  (I may have missed one or two,
> but it cannot be more than that.)  I'm astonished to hear such demands
> now.  If this is indeed what's required from Emacs maintainers, I will
> seriously consider resigning, because I cannot in good faith support
> such ridiculous development practices, let alone such level of
> mistrust towards my and Lars's experience and knowhow.

I can only speak for myself, but I absolutely trust that all
maintainers know the Emacs community far better than I do.

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Fri, 5 Feb 2021 10:11:28 +0100
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> Without going as far as making a formal poll, I don't think it's
> unreasonable to be as careful for binding a new key as we are for
> rebinding an existing key.

What makes you think we aren't that careful?  That the decision so far
was to add that new binding doesn't mean the potential downsides
weren't considered.

> Besides, technical arguments were also brought forward:

I have nothing against technical objections, and said or did nothing
to prevent the technical discussions, including in this very thread.
The post to which you responded was only about a single demand: to
make a user poll each time we add a new key binding (or make a similar
change).

> As far as I can tell, the suggestion of a poll was only metaphorical,

Then I guess I have trouble understanding written English, because to
me the demand to take a poll sounded very much as an explicit and
concrete one.

Re: [External] : Re: Concern about new binding.

[Thibaut Verron]

2021-02-05 12:15 UTC+01:00, Eli Zaretskii <eliz@gnu.org>:
>> From: Thibaut Verron <thibaut.verron@gmail.com>
>> Date: Fri, 5 Feb 2021 10:11:28 +0100
>> Cc: rms@gnu.org, emacs-devel@gnu.org
>>
>> Without going as far as making a formal poll, I don't think it's
>> unreasonable to be as careful for binding a new key as we are for
>> rebinding an existing key.
>
> What makes you think we aren't that careful?  That the decision so far
> was to add that new binding doesn't mean the potential downsides
> weren't considered.

(Tongue-in-cheek) Because usually, when such downsides are brought up,
the answer is status quo.

(Seriously) Because I would expect that counter-arguments would have
been ready and posted already.

>
>> Besides, technical arguments were also brought forward:
>
> I have nothing against technical objections, and said or did nothing
> to prevent the technical discussions, including in this very thread.

I know. My unclear point was that those technical arguments directly
lead to the question: do we really need a revert-buffer binding now,
after living for so long without one. The observation that it doesn't
appear to be a very requested feature is useful to answer it.

I don't think we need rigorous polling to make that statement.

>> As far as I can tell, the suggestion of a poll was only metaphorical,
>
> Then I guess I have trouble understanding written English, because to
> me the demand to take a poll sounded very much as an explicit and
> concrete one.

Sorry. English is not my first language, and regardless I don't want
to overreach in interpreting other's answers.

Re: [External] : Re: Concern about new binding.

[Dmitry Gutov]

On 05.02.2021 13:15, Eli Zaretskii wrote:
>> As far as I can tell, the suggestion of a poll was only metaphorical,
> Then I guess I have trouble understanding written English, because to
> me the demand to take a poll sounded very much as an explicit and
> concrete one.

It looked more like a question about the history of such requests rather 
than a demand to make a poll now.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> I have nothing against technical objections, and said or did nothing
> to prevent the technical discussions, including in this very thread.

You said that no technical objections had been raised.

> The post to which you responded was only about a single demand: to
> make a user poll each time we add a new key binding (or make a similar
> change).

No, I was the one who posted about polling.
And I did not demand anything at all.

I just asked _questions_:

  How do we know that?  Users haven't been polled,
  have they?  Emacs users and Emacs have survived
  for 35+ years without a global binding for
  `revert-buffer'.  Why assume that most users now
  would be happier if it had a global binding?

AFAICT, no one has demanded that a poll be required
for every question - or even for _any_ question.
But you keep repeating that people have been making
such "demands".  That's not fair.

> > As far as I can tell, the suggestion of a poll was only metaphorical,
> 
> Then I guess I have trouble understanding written English, because to
> me the demand to take a poll sounded very much as an explicit and
> concrete one.

Please cite the "demand to take a poll" to which
you're referring.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > More than that.  Over that time, how often have people
> > asked for such a global binding?
> 
> We never bother ourselves with such questions; never did.  We consider
> ourselves to be aware and familiar enough with the Emacs usage
> landscape to make such decisions without polling users on each and
> every step, 

I think Richard was not talking about polling, there.

I mentioned polling.  He added something else: how
often have users _asked_ for this?  Do we have bug
reports (feature requests) for it?  Any?  Many?

(I too had mentioned this point earlier, though not
in the mail that Richard replied too.)

> because doing so would slow down development to an
> unbearable crawl.  I always believed that at least part of the reasons
> we were nominated as maintainers was that people trust us to be
> capable of representing the bulk of Emacs users, and do it well enough
> to avoid too many serious mistakes.

That's true.  I don't think anyone disrespects the
maintainers.  I sure don't.  I'm very appreciative
of the hard work they do - and their judgment, in
general.

In particular, FWIW, I appreciate what some (many?)
might consider to be your conservative push-back
about many proposed changes.  Sometimes I voice an
explicit "+1"; sometimes I say nothing.  But to
myself I often say how lucky we are that you don't
just go along lightly with some new-change proposal.

That said, no one is infallible.  Leaders that
people respect the most often make mistakes.

In this particular case, no one has said that a
"serious mistake" was made.  And we've agreed, I
think, that it's not wrong for someone (especially
a maintainer) in a bug thread to make a change.
And that that change can be reversed, especially
if it's not a big one.

Some of us have argued, in this particular case,
that the decision to give a default binding to
`C-x g' should be reversed - at least pending more
discussion.  That should be possible especially
since the change hasn't been made to a release,
and especially because this "mistake" is _not_ a
serious one.

(What was argued wrt changes made in bug threads
was to avoid changes that range much wider than
the bug or feature request itself.  That's all.
In the current case, moving from a request for
a key for shell buffer reverting to the "need"
for a global key for buffer reverting.)

> In a case such as this one, when one of the maintainers says "this
> makes sense", I expect to hear technical arguments for or against that
> (btw, only agreements were heard when the original decision in this
> case was made), but I do NOT expect to hear "go ask the world because
> you don't really know what you are talking about".

1. I gave technical arguments.  I've even repeated
   them, since.
2. It's not true that only agreements were heard.
   I expressed disagreement from the outset.

> In all the 30 years of my uninterrupted active involvement with Emacs
> development, I don't remember even a single instance of polling users
> before making user-visible decisions.  (I may have missed one or two,
> but it cannot be more than that.)  I'm astonished to hear such demands

Have you heard a "demand" now?  I don't think
you've heard any demands whatsoever.  (Ever.)
Let's not descend into hyperbole, please.

> now.  If this is indeed what's required from Emacs maintainers, I will
> seriously consider resigning, because I cannot in good faith support
> such ridiculous development practices, let alone such level of
> mistrust towards my and Lars's experience and knowhow.

Please don't be so defensive.  No one is
attacking you or Lars.  It's not about you or
Lars or disrespecting the authority or
responsibility of maintainers.  Not at all.

And no, please don't consider resigning.

You've threatened that multiple times over the
years.  I think we're all glad that you've
kept at it.  I can understand the pressure of
the job and its responsibilities.  Know that
your work here is appreciated.  I hope that
knowledge makes a difference.

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> Date: Fri, 5 Feb 2021 18:24:37 +0000
> 
> Know that your work here is appreciated.  I hope that knowledge
> makes a difference.

It doesn't, not when the actual words and deeds speak to the contrary.

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> Date: Fri, 5 Feb 2021 18:24:37 +0000
> Cc: "emacs-devel@gnu.org" <emacs-devel@gnu.org>
> 
> > > More than that.  Over that time, how often have people
> > > asked for such a global binding?
> > 
> > We never bother ourselves with such questions; never did.  We consider
> > ourselves to be aware and familiar enough with the Emacs usage
> > landscape to make such decisions without polling users on each and
> > every step, 
> 
> I think Richard was not talking about polling, there.
> 
> I mentioned polling.

You did, and Richard said "more than that".  If that's not agreement,
then I don't know what agreement is.

> > In a case such as this one, when one of the maintainers says "this
> > makes sense", I expect to hear technical arguments for or against that
> > (btw, only agreements were heard when the original decision in this
> > case was made), but I do NOT expect to hear "go ask the world because
> > you don't really know what you are talking about".
> 
> 1. I gave technical arguments.  I've even repeated
>    them, since.

Not relevant to the issues I raised.

> 2. It's not true that only agreements were heard.
>    I expressed disagreement from the outset.

You disagree with any suggestion to add new key bindings, so I long
ago stopped taking your disagreements about these issues seriously.

> I just asked _questions_:
> 
>   How do we know that?  Users haven't been polled,
>   have they?

"You just asked questions."  Please don't insult my intelligence.  I
can read, you know.  When I express an opinion and you say we cannot
know that because there was no poll, how to interpret that other than
a demand to make a poll before my opinion would count?  And then
Richard seconded that.

Re: [External] : Re: Concern about new binding.

[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 never bother ourselves with such questions; never did.  We consider
  > ourselves to be aware and familiar enough with the Emacs usage
  > landscape to make such decisions without polling users on each and
  > every step, because doing so would slow down development to an
  > unbearable crawl.

You're right, but I think we are having a miscommunication.
I'm not saying we should poll the users about this.
That wasn't the intention at all.

Here's the discussion that led up to it:

    > I'd prefer to find a binding to which people could agree, because that
    > would leave fewer people unhappy.

    How do we know that?  Users haven't been polled,
    have they?  Emacs users and Emacs have survived
    for 35+ years without a global binding for
    `revert-buffer'.  Why assume that most users now
    would be happier if it had a global binding?

So I added

    More than that.  Over that time, how often have people
    asked for such a global binding?

My point was that we should not assume there is a lot of demand for
this change.


-- 
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: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: emacs-devel@gnu.org
> Date: Sun, 07 Feb 2021 00:33:40 -0500
> 
> You're right, but I think we are having a miscommunication.
> I'm not saying we should poll the users about this.
> That wasn't the intention at all.
> 
> Here's the discussion that led up to it:
> 
>     > I'd prefer to find a binding to which people could agree, because that
>     > would leave fewer people unhappy.
> 
>     How do we know that?  Users haven't been polled,
>     have they?  Emacs users and Emacs have survived
>     for 35+ years without a global binding for
>     `revert-buffer'.  Why assume that most users now
>     would be happier if it had a global binding?
> 
> So I added
> 
>     More than that.  Over that time, how often have people
>     asked for such a global binding?
> 
> My point was that we should not assume there is a lot of demand for
> this change.

You agreed with Drew who said a poll was needed (although now he
denies that).

More generally, the expectation that we poll the user to substantiate
decisions or opinions is expressed more and more frequently lately, on
more than one or two occasions, which is the background for what I
wrote.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > You're right, but I think we are having a miscommunication.
> > I'm not saying we should poll the users about this.
> > That wasn't the intention at all.
> >
> > Here's the discussion that led up to it:
> >
> >     > I'd prefer to find a binding to which people could
> >     > agree, because that would leave fewer people unhappy.
> >
> >     How do we know that?  Users haven't been polled,
> >     have they?  Emacs users and Emacs have survived
> >     for 35+ years without a global binding for
> >     `revert-buffer'.  Why assume that most users now
> >     would be happier if it had a global binding?
> >
> > So I added
> >
> >     More than that.  Over that time, how often have people
> >     asked for such a global binding?
> >
> > My point was that we should not assume there is a lot of
> > demand for this change.
> 
> You agreed with Drew who said a poll was needed
> (although now he denies that).

I already corrected you once on this.  I
shouldn't have to do so again.

I never, ever, said that a poll is/was needed.
Here, in this thread, or in any other thread.

It's not that "now he [I] denies that".  It's
that I never said that.  Please cite something
to the contrary, instead of continuing to
misrepresent what I've said.

I do agree with Richard's general sentiment that
asking users could sometimes provide some helpful
info.  And we both made the point that "we should
not _assume_ there is a lot of demand for this
change".

That was the message.  I posed it as a question:
what demand has been expressed for this change?
Has it ever been requested?  (No answer, so far.)

But I've never, ever, said or thought that a poll
is, EVER, needed.

And I have no illusions about the difficulty of
good polling or the limitations of polling.

I'd never promote polling as the sole, or even
as necessarily a good, or even an adequate, way
of determining what users want.  It can be one
way to obtain some kinds of info - nothing more.

(And I explicitly criticized a recent outside
poll of Emacs users wrt various criteria.) 

Nor do I think that what users want, even when
we can determine that reasonably, is or should
be the sole, or even the best, reason for a
design decision.  _Far from it._

What did I really say here about polling?
I quoted it once, after your first attempt to
misrepresent it.  (It's quoted again, above.)
Yet you persist in doing that.

In response to a statement about a decision
that's expected to leave "fewer people unhappy",
I asked _how that was known_ or thought to be
true.  That's all.  I asked whether users were
polled in that context, as a (conceivable)
justification for that claim.

I have no idea what real justification, if any,
might lie behind the claim.  I asked whether
some poll might be part of it.  I didn't demand
anything, including polling.

You claimed I argued that "we cannot know that,
because there was no poll".  And you said my
question was really a "demand", and that I
insisted a poll be taken "before [your] opinion
would count" -- and even that Richard seconded
that insistence.  None of that is accurate.

Please stop misrepresenting what I've said.
You've claimed that I've made derogatory
statements, and more.  I have not.

I even volunteered clearly and forthrightly
(and it's not the first time) that I'm very
grateful for your work as maintainer, and in
particular I appreciate your continuing to act
conservatively wrt proposals for change, and
your valuing what already exists or has long
existed.  I strongly value that in an Emacs
maintainer.

(I've also said multiple times that I especially
value the importance and care you place on Emacs
doc.  No one, with the exception of Richard, has
shown such appreciation of the importance of doc.)

You replied to my statement of appreciation with
a nasty grumble to the effect that it means
nothing, that what I wrote is insincere, and that
"actual words and deeds speak to the contrary."

I can only ask that you and others take me at
my word, and invite proof to the contrary.
It's disingenuous and unfair to do otherwise.
I don't say nice things to flatter you.  I say
what I mean.

Please stop being so defensive, and keep the
discussion about ideas.  Please do not try to
present a difference of opinion - a technical
argument - as an attack on yourself or other
maintainers.  It's not.  It's not about you.
And it's not about me.  It's about Emacs.

Re: [External] : Re: Concern about new binding.

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

  > > My point was that we should not assume there is a lot of demand for
  > > this change.

  > You agreed with Drew who said a poll was needed (although now he
  > denies that).

I agreed with what I saw was the main point of his message.  Not all
the side points such perhaps having a poll.  I regret any
misunderstanding.

-- 
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: Concern about new binding.

[Gregory Heytings]

It seems to me that the root problem of this thread, and similar ones in 
the past months, is the lack of a convention for external packages in 
`(elisp) Key Binding Conventions'.  There is a convention for users, there 
are conventions for major and minor modes, but there is no convention for 
external packages such as Magit, Drew's packages, and so forth. 
Consequently, the only solution for such packages is to use the currently 
empty slots, with a sword of Damocles hanging over them: these empty slots 
could at any time be reclaimed by Emacs.  I too can sympathize with Drew's 
(and other's) frustration when this happens.

A proposal to solve the current problem and future similar problems is to 
free one of the keys, and to mention in `(elisp) Key Binding Conventions' 
that it is, forever, reserved for external packages.

This proposal has two forms: a weak and a strong one.  The weak one would 
only reserve the control key, the strong one would also reserve the meta 
and control-meta keys.

The candidate keys for that proposal are "z", "t" and "o".

IOW, one could for example reserve either "C-z" (weak version), or "C-z" 
and "M-z" and "C-M-z" (strong version), for external packages.

This is a one-time change, which I'm sure will not be an easy one for 
everyone, but is a long-term solution that will avoid such repeated wars.

Re: Concern about new binding.

[Joost Kremers]

On Fri, Feb 05 2021, Gregory Heytings wrote:
> It seems to me that the root problem of this thread, and similar ones in 
> the past months, is the lack of a convention for external packages in 
> `(elisp) Key Binding Conventions'.  There is a convention for users, there 
> are conventions for major and minor modes, but there is no convention for 
> external packages such as Magit, Drew's packages, and so forth. 
> Consequently, the only solution for such packages is to use the currently 
> empty slots, 

Actually, there is another option, which AFAIK has been the unspoken "rule" for
such cases: leave the binding up to the user.

What we're talking about here are basically applications that run inside Emacs.
They have an entry point, i.e., a function that the user can run to start the
application (some may have multiple entry points, but that doesn't change the
argument), which users can bind as they see fit. That's what the `C-c <letter>`
keys are for. I mean, even applications that come with Emacs (Gnus, Rmail, Ediff
come to mind), don't have standard key bindings.

Perhaps a better way to update the documented key binding conventions is to add
the rule that packages should generally not create global key bindings.
Reserving keys for external packages won't solve the fundamental problem here:
two external packages may still decide to use the same key bindings, causing
similar conflicts for users that install both.


-- 
Joost Kremers
Life has its moments

Re: Concern about new binding.

[Gregory Heytings]

>
> Perhaps a better way to update the documented key binding conventions is 
> to add the rule that packages should generally not create global key 
> bindings.
>

That's another solution indeed, but IMO it is not a reasonable one.  It is 
reasonable for a package to create global bindings, to write its 
documentation with these bindings, and for users to install the package 
and to access it through these bindings without having to set specific 
configuration options beforehand.  It is IMO not reasonable to require 
from all users to add "global-set-key"s in their configuration before 
using a package.

>
> Reserving keys for external packages won't solve the fundamental problem 
> here: two external packages may still decide to use the same key 
> bindings, causing similar conflicts for users that install both.
>

That's a similar, but different problem: it's a conflict between package X 
and package Y, not a conflict between package X and Emacs.  Moreover the 
likelihood that two packages use the same keys is much lower when many 
keys are available.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > Perhaps a better way to update the documented key binding
> > conventions is to add the rule that packages should
> > generally not create global key bindings.
> 
> That's another solution indeed, but IMO it is not a reasonable one.  It
> is reasonable for a package to create global bindings, to write its
> documentation with these bindings, and for users to install the package
> and to access it through these bindings without having to set specific
> configuration options beforehand.  It is IMO not reasonable to require
> from all users to add "global-set-key"s in their configuration before
> using a package.
> 
> > Reserving keys for external packages won't solve the fundamental
> > problem here: two external packages may still decide to use the
> > same key bindings, causing similar conflicts for users that install both.
> 
> That's a similar, but different problem: it's a conflict between
> package X and package Y, not a conflict between package X and Emacs.
> Moreover the likelihood that two packages use the same keys is much
> lower when many keys are available.

100% agreement.

Re: Concern about new binding.

[Joost Kremers]

On Fri, Feb 05 2021, Gregory Heytings wrote:
>>
>> Perhaps a better way to update the documented key binding conventions is 
>> to add the rule that packages should generally not create global key 
>> bindings.
>>
>
> That's another solution indeed, but IMO it is not a reasonable one.  It is 
> reasonable for a package to create global bindings,

I tend to feel differently. :-) It's reasonable for a package to *suggest*
specific global key bindings and perhaps even to provide a user option or
function to install them, but IMHO they shouldn't be created automatically.

To an extent, this is just my personal opinion, but I think there are technical
reason as well. Firstly, note that `use-package` makes it possible to delay
loading a package until it's first used. That would be moot when creating
bindings depends on loading a package. In order to install the global bindings,
the package would have to be loaded upon startup. If you'd want to lazy-load a
package, you'd have to bind the keys explicitly anyway.

Moreover, lazy-loading makes it necessary that a package that creates its own
global bindings adds a user option to disable the creation of those bindings,
because otherwise lazy-loading a package could stomp on user-defined binding.
(The only other solution would be to add a bunch of `with-eval-after-load`s to
your init file to restore your personal bindings, which is not very
user-friendly, IMHO.)

One possible way to avoid this problem could be to basically do what Magit does:
ensure that packages install their global key bindings only if they're not
already bound. Emacs could provide a macro to do this, let's say
`maybe-global-set-key`, which package authors would then be encouraged to use.
If certain keymaps were reserved for external packages, as per your proposal,
this method would also avoid the problem that `C-x g` raises now. By using
`maybe-global-set-key`, a package author would know they won't be stomping on a
user's preferred key bindings and at the same time they'd have the guarantee
that Emacs would never override their bindings, ever.

It wouldn't solve another problem, however, which is that the key bindings a
user finds in their Emacs will depend on the order in which packages are loaded.
You say that the likelihood of two external packages using conflicting key
bindings is low, but I believe this is mainly due to the fact that most external
packages follow the unspoken rule that they shouldn't create global bindings.
But if Emacs reserves certain keymaps for external packages, it's likely many
packages will start binding these keys, raising the potential for conflicts. And
when that happens, the order in which packages are loaded matters.

The only way to avoid that would be for each package to provide an option to
disable the creation of its global bindings. But the system you'd end up with is
complex and confusing for the user, I think. For each package you install, you'd
have to find out whether its key bindings override those of another package and
then make sure to load them in the correct order or set the option not to create
the bindings.

It's more straight-forward, I think, if you can just add a `require` or
`use-package` statement to your init file and add the key bindings you want. No
need to think about the place where you load the package in your init file or
whether you want to lazy-load a package.

Package authors would then simply include the code to create their proposed
key bindings in their installation instructions and every user would have the
opportunity to decide whether they want to put that code in their init file or
not. There would be no potential side effect to consider and all non-standard key
bindings would be located in one place: the user's init file.


-- 
Joost Kremers
Life has its moments

Re: Concern about new binding.

[Gregory Heytings]

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


>
> Moreover, lazy-loading makes it necessary that a package that creates 
> its own global bindings adds a user option to disable the creation of 
> those bindings, because otherwise lazy-loading a package could stomp on 
> user-defined binding.
>
> [...]
>
> It wouldn't solve another problem, however, which is that the key 
> bindings a user finds in their Emacs will depend on the order in which 
> packages are loaded.
>
> [...]
>
> The only way to avoid that would be for each package to provide an 
> option to disable the creation of its global bindings.
>

AFAICS, it's not the only way to avoid that.  Another solution is, when a 
package is loaded, to check whether the bindings it would like to use are 
already used, and if so, issue a warning to the user instead of rebinding 
them.  In such cases, and only in such cases, the user would have to do 
something.  Typical users who install a few packages each binding a few 
keys would never have to do anything.

Re: Concern about new binding.

[Andreas Schwab]

On Feb 06 2021, Joost Kremers wrote:

> To an extent, this is just my personal opinion, but I think there are technical
> reason as well. Firstly, note that `use-package` makes it possible to delay
> loading a package until it's first used. That would be moot when creating
> bindings depends on loading a package. In order to install the global bindings,
> the package would have to be loaded upon startup. If you'd want to lazy-load a
> package, you'd have to bind the keys explicitly anyway.

Typically, such global bindings are installed in the autoload file.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Concern about new binding.

[Thibaut Verron]

2021-02-05 10:38 UTC+01:00, Joost Kremers <joostkremers@fastmail.fm>:
>
> On Fri, Feb 05 2021, Gregory Heytings wrote:
>> It seems to me that the root problem of this thread, and similar ones in
>> the past months, is the lack of a convention for external packages in
>> `(elisp) Key Binding Conventions'.  There is a convention for users, there
>>
>> are conventions for major and minor modes, but there is no convention for
>>
>> external packages such as Magit, Drew's packages, and so forth.
>> Consequently, the only solution for such packages is to use the currently
>>
>> empty slots,
>
> Actually, there is another option, which AFAIK has been the unspoken "rule"
> for
> such cases: leave the binding up to the user.

+1 (as long as we are speaking both about emacs and packages)

But there seems to be technical reasons for a package wanting to set
its binding.


> What we're talking about here are basically applications that run inside
> Emacs.
> They have an entry point, i.e., a function that the user can run to start
> the
> application (some may have multiple entry points, but that doesn't change
> the
> argument), which users can bind as they see fit. That's what the `C-c
> <letter>`
> keys are for. I mean, even applications that come with Emacs (Gnus, Rmail,
> Ediff
> come to mind), don't have standard key bindings.

How do you define "applications"? Magit is very similar in its intent
to vc-mode, which does have a global binding.
A cursory look through global-map shows global bindings for functions
from abbrev, dabbrev, calc, eww, xref, 2C, vc. Are those applications?

> Perhaps a better way to update the documented key binding conventions is to
> add
> the rule that packages should generally not create global key bindings.

I personally find it useful when packages recommend key bindings. It
helps me understand what the package is for and how it can be used.

And if sufficiently many users follow the recommendation, I don't know
if the key should be considered free.

The only practical difference for the issue at hand is that Emacs
rebinding a recommended binding will not break configurations, instead
the new binding will be shadowed by the users' init files.

> Reserving keys for external packages won't solve the fundamental problem
> here:
> two external packages may still decide to use the same key bindings,
> causing
> similar conflicts for users that install both.

As far as I know there has never been any serious conflict of this
kind. Examples of popular packages which come to mind with global keys
are:
magit recommending/setting "C-x g"
expand-region recommending "C-,"
ace-jump recommending "C-;"
multi-cursors recommending the keys around "C-." (with the exception
of "C-,", which might be explained by the fact that it's the same
author as expand-region)
org-roam hijacking "C-x n"

Basically, it's been first-come-first-served in the community for a
while, and small packages not complaining when their binding was taken
by someone who became bigger.

It seems to work, and it doesn't seem to make a difference whether a
key is recommended or bound for that.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > Reserving keys for external packages won't solve the fundamental
> > problem here: two external packages may still decide to use
> > the same key bindings, causing similar conflicts for users
> > that install both.
> 
> As far as I know there has never been any serious
> conflict of this kind.

Agreed.

(But as I pointed out, there are 3rd-party libraries
and 3rd-party libraries.  A well-known, heavily used
library is different in this regard from a small
shared user library.  The potential problem is there
for 2 or more large, heavily-used libraries to have
conflicting bindings.  But I too don't see even that
as much of a problem, in practice.  The problem of
trying to compete with Emacs default bindings is a
much bigger, more real problem - it's the problem at
the heart of this thread, IMO.)

> Basically, it's been first-come-first-served in the community for a
> while, and small packages not complaining when their binding was taken
> by someone who became bigger.

Yup.  Well put.

> It seems to work, and it doesn't seem to make a difference whether a
> key is recommended or bound for that.

Yup (for some meaning of "work" ;-)).

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> Perhaps a better way to update the documented key
> binding conventions is to add the rule that packages
> should generally not create global key bindings.

As I mentioned earlier, my position on that is
that (1) we can document that it's generally a
good idea for 3rd-party code to only suggest
such bindings, and not actually create them,
but (2) there's no convention that 3rd-party
code should not or must not create such bindings.

What will happen, if we try a more draconian
convention, is that 3rd-party code will add
minor modes which wouldn't otherwise have
existed (i.e., created just to provide bindings).

And then we have the same potential problem, but
just playing out as competition between minor
modes that are active at the same time.

> Reserving keys for external packages won't solve
> the fundamental problem here: two external
> packages may still decide to use the same key
> bindings, causing similar conflicts for users
> that install both.

I agree.  Except that I don't consider that to be
the fundamental problem here.  And I don't even
think it is much of a potential problem, though
I recognize that it exists.

The fundamental problem here, IMO, is Emacs
itself grabbing more and more new default keys,
restricting the space of keys available for
3rd-party libraries.

Competition for keys among 3rd parties is much
less of a problem, I think.  When Emacs grabs a
key by default, no package wants to bind that
key - it's effectively lost to 3rd-party code.

Re: [External] : Re: Concern about new binding.

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-05 21:57]:
> > Perhaps a better way to update the documented key
> > binding conventions is to add the rule that packages
> > should generally not create global key bindings.
> 
> As I mentioned earlier, my position on that is
> that (1) we can document that it's generally a
> good idea for 3rd-party code to only suggest
> such bindings, and not actually create them,
> but (2) there's no convention that 3rd-party
> code should not or must not create such bindings.

That is good idea and if adopted, then it shall become part of the
Emacs Lisp manual as new normative example.

Re: Concern about new binding.

[Eli Zaretskii]

> Date: Fri, 05 Feb 2021 09:21:20 +0000
> From: Gregory Heytings <gregory@heytings.org>
> 
> A proposal to solve the current problem and future similar problems is to 
> free one of the keys, and to mention in `(elisp) Key Binding Conventions' 
> that it is, forever, reserved for external packages.
> 
> This proposal has two forms: a weak and a strong one.  The weak one would 
> only reserve the control key, the strong one would also reserve the meta 
> and control-meta keys.
> 
> The candidate keys for that proposal are "z", "t" and "o".

C-z, C-t, and C-o are already taken, and are very old bindings.  C-t
in particular is very useful and frequently-used (by me, FWIW), and
also matches the default binding in Bash, GDB CLI, and elsewhere.  A
recent discussion demonstrated that at least for C-z enough people are
against changing its binding, even though we have "C-x C-z" to do the
same.

These data points suggest that usurping these keys may not be easy, to
say the least.

Re: Concern about new binding.

[Gregory Heytings]

>> A proposal to solve the current problem and future similar problems is 
>> to free one of the keys, and to mention in `(elisp) Key Binding 
>> Conventions' that it is, forever, reserved for external packages.
>>
>> This proposal has two forms: a weak and a strong one.  The weak one 
>> would only reserve the control key, the strong one would also reserve 
>> the meta and control-meta keys.
>>
>> The candidate keys for that proposal are "z", "t" and "o".
>
> C-z, C-t, and C-o are already taken
>

I know this; I said "to _free_ one of the keys".

>
> C-t in particular is very useful and frequently-used (by me, FWIW), and 
> also matches the default binding in Bash, GDB CLI, and elsewhere.  A 
> recent discussion demonstrated that at least for C-z enough people are 
> against changing its binding, even though we have "C-x C-z" to do the 
> same.
>

Yes, it is unavoidable that some people will be against changing a 
binding.  I have no preference between the three proposed keys, and 
anticipated that there would be more objections against using "t" for that 
purpose.  If we put "t" aside, there are still two other options: "z" and 
"o".

>
> These data points suggest that usurping these keys may not be easy, to 
> say the least.
>

The meaning of the proposal is that the benefit of such a single change 
is, in the long term, largely superior to its loss in the short term.

Re: Concern about new binding.

[Eli Zaretskii]

> Date: Fri, 05 Feb 2021 12:07:48 +0000
> From: Gregory Heytings <gregory@heytings.org>
> cc: emacs-devel@gnu.org
> 
> > These data points suggest that usurping these keys may not be easy, to 
> > say the least.
> 
> The meaning of the proposal is that the benefit of such a single change 
> is, in the long term, largely superior to its loss in the short term.

I'm just not sure enough people will share your opinion to make it
possible to do such a change.  But that's me; and for my personal
usage I don't really care too much about changes in key bindings
because it's all too easy to override any defaults I don't like (e.g.,
I have my private key binding for "C-x g").  But others evidently care
a lot.

Re: Concern about new binding.

[Thibaut Verron]

2021-02-05 13:07 UTC+01:00, Gregory Heytings <gregory@heytings.org>:
>
>>> A proposal to solve the current problem and future similar problems is
>>> to free one of the keys, and to mention in `(elisp) Key Binding
>>> Conventions' that it is, forever, reserved for external packages.
>>>
>>> This proposal has two forms: a weak and a strong one.  The weak one
>>> would only reserve the control key, the strong one would also reserve
>>> the meta and control-meta keys.
>>>
>>> The candidate keys for that proposal are "z", "t" and "o".
>>
>> C-z, C-t, and C-o are already taken
>>
>
> I know this; I said "to _free_ one of the keys".
>
>>
>> C-t in particular is very useful and frequently-used (by me, FWIW), and
>> also matches the default binding in Bash, GDB CLI, and elsewhere.  A
>> recent discussion demonstrated that at least for C-z enough people are
>> against changing its binding, even though we have "C-x C-z" to do the
>> same.
>>
>
> Yes, it is unavoidable that some people will be against changing a
> binding.  I have no preference between the three proposed keys, and
> anticipated that there would be more objections against using "t" for that
> purpose.  If we put "t" aside, there are still two other options: "z" and
> "o".
>
>>
>> These data points suggest that usurping these keys may not be easy, to
>> say the least.
>>
>
> The meaning of the proposal is that the benefit of such a single change
> is, in the long term, largely superior to its loss in the short term.
>
>

Re: Concern about new binding.

[Thibaut Verron]

2021-02-05 13:39 UTC+01:00, Thibaut Verron <thibaut.verron@gmail.com>:
> 2021-02-05 13:07 UTC+01:00, Gregory Heytings <gregory@heytings.org>:
>>
>>>> A proposal to solve the current problem and future similar problems is
>>>> to free one of the keys, and to mention in `(elisp) Key Binding
>>>> Conventions' that it is, forever, reserved for external packages.
>>>>
>>>> This proposal has two forms: a weak and a strong one.  The weak one
>>>> would only reserve the control key, the strong one would also reserve
>>>> the meta and control-meta keys.
>>>>
>>>> The candidate keys for that proposal are "z", "t" and "o".
>>>
>>> C-z, C-t, and C-o are already taken
>>>
>>
>> I know this; I said "to _free_ one of the keys".
>>
>>>
>>> C-t in particular is very useful and frequently-used (by me, FWIW), and
>>> also matches the default binding in Bash, GDB CLI, and elsewhere.  A
>>> recent discussion demonstrated that at least for C-z enough people are
>>> against changing its binding, even though we have "C-x C-z" to do the
>>> same.
>>>
>>
>> Yes, it is unavoidable that some people will be against changing a
>> binding.  I have no preference between the three proposed keys, and
>> anticipated that there would be more objections against using "t" for
>> that
>> purpose.  If we put "t" aside, there are still two other options: "z" and
>> "o".

(Sorry for the message I sent just now, it is really empty)

I also regularly use C-o to get some breathing room. I unbind C-z to
have a free key in tmux and screen, so I wouldn't mind freeing that
key.

Re: Concern about new binding.

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

> Yes, it is unavoidable that some people will be against changing a
> binding.  I have no preference between the three proposed keys, and
> anticipated that there would be more objections against using "t" for that
> purpose.  If we put "t" aside, there are still two other options: "z" and
> "o".

FWIW, I would not like to see C-o change as I use it daily.  But I could
live with it as I can rebind it locally.  It would be too bad that we
would then lose the nice symmetry between `C-o' and `C-x C-o'.

I'm in favour of rebinding C-z to exactly one thing: `undo'.  It would
IMO be very unfortunate if we do rebind it yet miss out on the
opportunity to make Emacs more like other applications.

Re: Concern about new binding.

[Ergus]

On Sat, Feb 06, 2021 at 07:23:18AM -0800, Stefan Kangas wrote:
>Gregory Heytings <gregory@heytings.org> writes:
>
>
>I'm in favour of rebinding C-z to exactly one thing: `undo'.  It would
>IMO be very unfortunate if we do rebind it yet miss out on the
>opportunity to make Emacs more like other applications.
>
Hi Stefan:

Unless I totally agree with this proposal... it implies that there will
be two changes: 1) (Re)Moving undo from where it is and 2) putting it in
C-z...

I proposed that some months ago and it started another war due to the
concept of "emacs does not have to be like other applications" but also
"use cua mode" they said.

So if this is accepted I will be totally in favor of the change... but I
don't think it will be approved.

Re: Concern about new binding.

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2021-02-06 18:24]:
> Gregory Heytings <gregory@heytings.org> writes:
> 
> > Yes, it is unavoidable that some people will be against changing a
> > binding.  I have no preference between the three proposed keys, and
> > anticipated that there would be more objections against using "t" for that
> > purpose.  If we put "t" aside, there are still two other options: "z" and
> > "o".
> 
> FWIW, I would not like to see C-o change as I use it daily.  But I could
> live with it as I can rebind it locally.  It would be too bad that we
> would then lose the nice symmetry between `C-o' and `C-x C-o'.
> 
> I'm in favour of rebinding C-z to exactly one thing: `undo'.  It would
> IMO be very unfortunate if we do rebind it yet miss out on the
> opportunity to make Emacs more like other applications.

For console users it is good to consider why people use C-z in the
first place.

Why would anybody wish to "stop the job" in the shell?

Maybe there is urgent need to replace disks, mount disks, unmount
such, connect to remove servers during job execution?

Maybe there is need to replace the video file in the file list while
not interrupting the processing of other 20 video files? Maybe such
video file processing takes 2 days. I am using Emacs Lisp to process
video files and this is real world example. Sometimes I process video
files on remote server. Maybe I do not want to process video files
during the day and job can remain suspended until the night without
interrupting the queue of video files being processed.

Thus it is good to consider the purpose for users to suspend a job in
their shell.

Yes, sure there are other Emacs key bindings to suspend the job, but
suspending a job should be compatible with shell bindings to suspend
the job and that is C-z.

Breaking incompatibility puts users' data at stake.

Jean

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> C-t in particular is very useful and frequently-used (by me, FWIW), and
> also matches the default binding in Bash, GDB CLI, and elsewhere.

I don't argue that `C-t' should or must be repurposed,
and I too use it.  But I do think it's one candidate
for that.  I think there are most likely better uses
for it.  It, along with some other keys (I mentioned
`C-o') are worth discussing, if Emacs needs more key
bindings.

> These data points suggest that usurping these keys
> may not be easy, to say the least.

Yes.

Re: Concern about new binding.

[Ergus via Emacs development discussions.]

On February 5, 2021 12:21:02 PM GMT+01:00, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Fri, 05 Feb 2021 09:21:20 +0000
>> From: Gregory Heytings <gregory@heytings.org>
>> 
>> A proposal to solve the current problem and future similar problems
>is to 
>> free one of the keys, and to mention in `(elisp) Key Binding
>Conventions' 
>> that it is, forever, reserved for external packages.
>> 
>> This proposal has two forms: a weak and a strong one.  The weak one
>would 
>> only reserve the control key, the strong one would also reserve the
>meta 
>> and control-meta keys.
>> 
>> The candidate keys for that proposal are "z", "t" and "o".
>
>C-z, C-t, and C-o are already taken, and are very old bindings.  C-t
>in particular is very useful and frequently-used (by me, FWIW), and
>also matches the default binding in Bash, GDB CLI, and elsewhere.  A
>recent discussion demonstrated that at least for C-z enough people are
>against changing its binding, even though we have "C-x C-z" to do the
>same.
>
Hi Eli:

IIRC there were not agreement about what to do with C-z. BUT not really many people against the change itself. There was the suggestion to use C-z C-z and C-z z (ala M-g g) inside the new C-z map that made happy many old C-z users. Then the problem was the lack of a decision and a deadline to decide. 

Sometimes I feel that we need just a pool application to vote and a deadline. to decide about. And we will save a lot of emails.

>These data points suggest that usurping these keys may not be easy, to
>say the least.

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: Concern about new binding.

[Eli Zaretskii]

> Date: Fri, 05 Feb 2021 20:14:29 +0100
> From: Ergus <spacibba@aol.com>
> 
> Sometimes I feel that we need just a pool application to vote and a
> deadline. to decide about.

This isn't a democracy, so a poll is not the right instrument to make
decisions.  Hearing different opinions is a tool, not the algorithm to
decide what to do.

Re: Concern about new binding.

[chad]

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

On Fri, Feb 5, 2021 at 11:16 AM Ergus via Emacs development discussions. <
emacs-devel@gnu.org> wrote:

> > A
> >recent discussion demonstrated that at least for C-z enough people are
> >against changing its binding, even though we have "C-x C-z" to do the
> >same.
>
> IIRC there were not agreement about what to do with C-z. BUT not really
> many people against the change itself. There was the suggestion to use C-z
> C-z and C-z z (ala M-g g) inside the new C-z map that made happy many old
> C-z users. Then the problem was the lack of a decision and a deadline to
> decide.
>

I had proposed such a change a while back, not too long before the thread
in question, along with a request for people to reply to the list or to me
directly if they used C-z suspend-frame in GUI emacs. FWIW, I got no reply
saying that they did use the binding, and multiple people saying that they
had rebound C-z themselves (which I have been doing for 25+ years).

What I would characterize as the major objection was the desire to have
emacs on a tty respond reasonably to at least one of the canonical ways to
end a tty program, C-c or C-z, along with reluctance to strongly segregate
the keybindings between tty and GUI, at least as far as commonly-used
functions were concerned.

I think that there is a reasonable technical solution available here where
hitting C-z and then nothing else for a few seconds provides enough
guidance to the user, roughly along the same lines as what the very popular
package which-key already does.

(For anyone not familiar, it creates, after a short delay, a list of
possible completions for a current partial command. More details can be had
from:
https://elpa.gnu.org/packages/which-key.html )

There had been talk in the past year about perhaps including/enabling
something which-key or something similar as part of the "modernization"
effort, so I didn't push the conversation past that point.

Hope that helps,
~Chad

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

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> It seems to me that the root problem of this thread, and similar ones
> in
> the past months, is the lack of a convention for external packages in
> `(elisp) Key Binding Conventions'.  There is a convention for users,
> there
> are conventions for major and minor modes, but there is no convention
> for
> external packages such as Magit, Drew's packages, and so forth.

FWIW, I don't think that's the root problem of
this thread.  I don't even think it's much of
a problem.

I, for one, think that it makes sense for
3rd-party libraries to be in the same class as
users when it comes to key-binding conventions.

I might be convinced otherwise.  And yes, there
are differences among 3rd-party libraries.  Some
are huge and have many users.  Some are even
nearly part of Emacs itself.  Others are simply
some small bit of code that a user shares with
others.

I think that, until proven otherwise, we're OK
with lumping 3rd-party code with users, when it
comes to conventions about key bindings.

> Consequently, the only solution for such packages is to use the
> currently empty slots, with a sword of Damocles hanging over
> them: these empty slots could at any time be reclaimed by Emacs.
> I too can sympathize with Drew's (and other's) frustration when
> this happens.

It's indeed a problem.  The same problem can
arise if some other 3rd-party library decides
to use the same key (e.g. a prefix key) that
another library has long used.

But I think that such potential conflicts
among 3rd-party bindings are less of a problem
than Emacs itself grabbing keys.  (See above.
And again, I could be convinced otherwise.)

> A proposal to solve the current problem and future similar problems is
> to free one of the keys, and to mention in `(elisp) Key Binding
> Conventions' that it is, forever, reserved for external packages.

I'm not in favor of that - a single key for
all 3rd-party code.

> This proposal has two forms: a weak and a strong one.  The weak one
> would only reserve the control key, the strong one would also
> reserve the meta and control-meta keys.

I guess you mean not a single key but a
single key plus its Control or Control-&-Meta
modifiers?

I'm not in favor of that either - still too
limiting.

I favor allowing all keys that are currently
allowed for 3rd-party code.  And I favor Emacs
itself implementing a moratorium on binding any
more keys by default.

A moratorium that could be overruled in cases
deemed to be important, cases that would
hopefully be discussed here, and would of
course be decided by the maintainers.

> The candidate keys for that proposal are "z", "t" and "o".
> IOW, one could for example reserve either "C-z" (weak version), or "C-
> z"
> and "M-z" and "C-M-z" (strong version), for external packages.
> 
> This is a one-time change, which I'm sure will not be an easy one for
> everyone, but is a long-term solution that will avoid such repeated
> wars.

To me, that's too limiting for 3rd-party libraries.
I'd prefer what I say above.  Emacs itself should
keep its hands off new keys.

Emacs can instead repurpose some existing key
bindings, if it needs new bindings.  There are, I
think, some existing bindings that might not be
all that necessary.

RE: [External] : Re: Concern about new binding.

[Gregory Heytings]

>> A proposal to solve the current problem and future similar problems is 
>> to free one of the keys, and to mention in `(elisp) Key Binding 
>> Conventions' that it is, forever, reserved for external packages.
>
> I'm not in favor of that - a single key for all 3rd-party code.
>
> [...]
>
> I'm not in favor of that either - still too limiting.
>

I'm puzzled.  The proposal frees one complete keymap for libraries such as 
Magit and yours.  With say C-o, Magit could use C-o g and C-o M-g, you 
could use C-o p and C-o / and ..., and so forth, with the guarantee that 
Emacs would never reclaim any key in that map.  That's a lot of room...

>
> I favor allowing all keys that are currently allowed for 3rd-party code. 
> And I favor Emacs itself implementing a moratorium on binding any more 
> keys by default.
>

... but apparently you prefer to continue to use the few remaining keys 
that are not bound by default?  Isn't that contradictory?

>
> To me, that's too limiting for 3rd-party libraries. I'd prefer what I 
> say above.  Emacs itself should keep its hands off new keys.
>

That's clearly an unreasonable demand.  When new commands are added to 
Emacs, I see no reason to not bind them to some key.  I also see no reason 
to not bind commands that were for one reason or another not bound when 
they were included in Emacs, and are nowadays considered important enough 
to be bound to a key.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> I'm puzzled.  The proposal frees one complete keymap for libraries such
> as Magit and yours.  With say C-o, Magit could use C-o g and C-o M-g, you
> could use C-o p and C-o / and ..., and so forth, with the guarantee
> that Emacs would never reclaim any key in that map.  That's a lot of room...
> 
> > I favor allowing all keys that are currently allowed for 3rd-party
> > code.  And I favor Emacs itself implementing a moratorium on
> > binding any more keys by default.
> 
> ... but apparently you prefer to continue to use the few remaining keys
> that are not bound by default?  Isn't that contradictory?

How so?  The few remaining keys are more than a single key.

> > To me, that's too limiting for 3rd-party libraries. I'd prefer what I
> > say above.  Emacs itself should keep its hands off new keys.
> 
> That's clearly an unreasonable demand.  When new commands are added to
> Emacs, I see no reason to not bind them to some key.

I see no reason _to_ bind a command just because it's new.

And I was clear that there could be exceptions to the
(proposed) rule.

The point is that (1) there are few keys left, and (2) if
Emacs itself binds one of them, that's more limiting, in
effect, than if some 3rd-party library binds one of them.

To me, there's a problem: scarcity of available keys.
I proposed something that could help with that problem.
That's all.  Other suggestions for that?

> I also see no reason to not bind commands that were
> for one reason or another not bound when they were
> included in Emacs, 

As Eli is wont to say (correctly), we don't do things in
Emacs just because there's no known good reason not to.
We make changes when there are good reasons _to_ do so.

It's not just about `revert-buffer' not having been
bound when it was included in Emacs (Day One, probably).

It's that for all of Emacs's 35+ years it hasn't been
bound.  And I'm not aware of any requests (new or old)
for that.  (And none have been presented so far in this
discussion.)

The importance of that command, and its relatively
frequent and common use, together with the fact that it
has never had a default global key binding, and that no
one has even asked for such a binding, all argue against
a need for it to have such a binding.

> and are nowadays considered important enough to be
> bound to a key.

That's in question, isn't it?

And it's not about whether it's important for
`revert-buffer' to be bound to a key.  _I_ bind it to
a global key, myself, as one user.  It's about whether
it's important enough to be bound globally by default.

And I haven't seen here anything that's argued that
there's some particular "nowadays" need that wasn't
a need before.  No need expressed before, and no new
need expressed now.

And besides users binding `revert-buffer' (because
they find that useful), `revert-buffer' _is_ bound
by Emacs by default - in multiple modes, and often
to a mode-specific behavior (via variable
`revert-buffer-function').

The discussion of binding `revert-buffer' is only
about binding it globally by default.  That's what's
new, that's what's just been done.  And there's
been no "nowadays" need presented for that, AFAIK.

RE: [External] : Re: Concern about new binding.

[Gregory Heytings]

>> I'm puzzled.  The proposal frees one complete keymap for libraries such 
>> as Magit and yours.  With say C-o, Magit could use C-o g and C-o M-g, 
>> you could use C-o p and C-o / and ..., and so forth, with the guarantee 
>> that Emacs would never reclaim any key in that map.  That's a lot of 
>> room...
>>
>>> I favor allowing all keys that are currently allowed for 3rd-party 
>>> code.  And I favor Emacs itself implementing a moratorium on binding 
>>> any more keys by default.
>>
>> ... but apparently you prefer to continue to use the few remaining keys 
>> that are not bound by default?  Isn't that contradictory?
>
> How so?  The few remaining keys are more than a single key.
>

... and a complete keymap is more than a single key.

I can't understand why you do not agree that having _all_ (say) C-o LETTER 
slots at the disposal of third-party libraries is not a reasonable 
solution that would contribute to peace and stability, and that you prefer 
to fight to keep the last five or six C-x LETTER slots free.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> >> ... but apparently you prefer to continue to use the
> >> few remaining keys that are not bound by default?
> >> Isn't that contradictory?
> >
> > How so?  The few remaining keys are more than a single key.
> 
> ... and a complete keymap is more than a single key.

No, sorry; I still don't understand.  You can bind
a keymap to a key.  If there are _several_ keys that
you can bind keymaps to, then that offers more
possibilities than if there is only _one_ key that
you can bind a keymap to.

> I can't understand why you do not agree that having
> _all_ (say) C-o LETTER slots at the disposal of
> third-party libraries is not a reasonable solution
> that would contribute to peace and stability, and
> that you prefer to fight to keep the last five or
> six C-x LETTER slots free.

`C-o' is currently bound by default.  But I already
made clear that I'm for freeing it up, one way or
another.  I _do_ agree that having all `C-o LETTER'
keys available for binding would be helpful.

If _only_ `C-o' were available for use as a prefix key
then that would be far less than all of the currently
unbound keys, which can each be used as a prefix key.

And the currently unbound keys are not limited to
`C-x LETTER' or even `C-x <whatever>' keys.

I proposed a moratorium on Emacs binding any new keys
by default.  I didn't limit that to `C-x LETTER'.

And yes, we could go further, and consider adding some
currently globally bound keys, such as `C-o', to the
"free" list.  I wouldn't be against that, at all, even
if I only argued for Emacs to keep its mitts off keys
keys that don't yet have global default bindings.

My proposal is a good start.  But I sure wouldn't mind
having us go further.  Emacs has too many keys bound
globally by default, I think.  That latter battle
isn't one I'd argue for now, but yeah, I'm in favor
of Emacs having even fewer global key bindings, not
just in favor of it putting an end to the steal.
(Ooooh, apologies for that horrible turn of phrase.)

Something needs to be done, IMO.  Other proposals are
welcome, to help us manage key-binding possibilities
and their inherent limitations.  Early on, there was
a vast undeveloped and unexplored frontier - uncharted
territory.  Now, Land's End is in plain sight.

Maybe Emacs should bind global keys only using some
hydra-like functionality.  (Dunno.)

But whatever solution we might find, it's important
that the help system really support it.  Today, help
on keys is good - even static help, i.e., without
something like `which-key' or Icicles key completion.
Today, you can do `C-x 4 C-h' and get help on all of
those keys.  Likewise, `describe-keymap' is a great
help.  We need to ensure that we keep providing great
key help.

Dunno whether a hydra approach - or even some of the
currently discussed transient key approaches -
provide such good help.  I suspect not, but I don't
know.  It's one thing to provide on-the-fly help
with some kind of completion when you start to use
a key.  It's something else to be able to get help
about whole sets of keys.

RE: [External] : Re: Concern about new binding.

[Gregory Heytings]

>>>> ... but apparently you prefer to continue to use the few remaining 
>>>> keys that are not bound by default? Isn't that contradictory?
>>>
>>> How so?  The few remaining keys are more than a single key.
>>
>> ... and a complete keymap is more than a single key.
>
> No, sorry; I still don't understand.  You can bind a keymap to a key. 
> If there are _several_ keys that you can bind keymaps to, then that 
> offers more possibilities than if there is only _one_ key that you can 
> bind a keymap to.
>

I'm not sure I see what you mean.  It's not _one_ key.  Having a complete 
keymap at the disposal of third-party libraries means that there are (at 
least) 26 letters free; each of them can be bound to a separate keymap. 
Magit would bind the "g" and "M-g" keys, some other library would bind the 
"." and "," keys, another one would bind "x" key to a keymap, another one 
would bind the "C-k" and "C-l" keys, you would bind the "p" key to a 
keymap for your bookmark+ library, and so forth.  Or am I missing 
something?

And with the "strong" version of the proposal, there would be (at least) 
52 other prefix keys, with the meta- and control-meta- prefixes.

>
> And the currently unbound keys are not limited to `C-x LETTER' or even 
> `C-x <whatever>' keys.
>

Almost all C-SYMBOL and almost all C-M-SYMBOL keys are currently unbound 
indeed, but I don't see any evidence that Emacs is about to grab them all.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > If there are _several_ keys that you can bind
> > keymaps to, then that offers more possibilities
> > than if there is only _one_ key that you can
> > bind a keymap to.
> 
> I'm not sure I see what you mean.  It's not _one_ key.  Having a
> complete keymap at the disposal of third-party libraries means
> that there are (at least) 26 letters free; each of them can be
> bound to a separate keymap.

Yes, of course.  I already acknowledged that.

That's still much less than what can be bound
to several such prefix keys.

_Of course_ you can bind each letter to a
prefix key.  But you can do the same on any of
the still-free keys.  And there are more than
one of those.  (More than one is, well, more
than one.)

What's more, if you put everything on only a
single prefix key, then that leads to deeper
(i.e., longer) key bindings.

For example, I use `C-x x' as a prefix key for
Bookmark+ keys other than specific kinds of
bookmark jumping.  I use `C-x j' and `C-x 4 j'
as prefix keys for bookmark jumping commands.
Without being able to use more than one prefix
key, the jump commands would all be a level
deeper (longer key sequences).

And the jump prefix keys themselves already
have multiple levels of prefix keys.  E.g.,
`C-x j t . % +' jumps to a file bookmark in
the current dir (`.') that has a tag (`t')
that matches a given regexp (`%') you're
prompted for.  Those keys are systematic and
mnemonic, but that's already several prefix
keys deep.

I've seen no reason, so far, why we should
limit 3rd-party libraries to a single prefix
key - even if one can of course keep extending
a prefix key by adding deeper layers.

Better to have _several_ free keys for
3rd-party libraries than to have only one.
That's the point.

No argument for how you can put lots of stuff
on a single prefix key can overcome the fact
that more prefix keys give you more than does
one prefix key.

https://www.emacswiki.org/emacs/BookmarkPlus#BookmarkPrefixKeys

RE: [External] : Re: Concern about new binding.

[Gregory Heytings]

>> Having a complete keymap at the disposal of third-party libraries means 
>> that there are (at least) 26 letters free; each of them can be bound to 
>> a separate keymap.
>
> That's still much less than what can be bound to several such prefix 
> keys.
>

That's wrong, both from a practical and from a theoretical point of view.

From a practical point of view, the bindings in (B) are not deeper/longer 
than the bindings in (A):

|      (A)      |      (B)      |
|---------------|---------------|
| C-x j         | C-o j         |
| C-x j = f     | C-o j = f     |
| C-x j t . % + | C-o j t . % + |
| C-x 4 j       | C-o 4 j       |
| C-x x :       | C-o x :       |
| C-x x t e     | C-o x t e     |
| C-x x t + b   | C-o x t + b   |

From a theoretical point of view: the number of available keys is, in both 
cases, aleph-zero.

>
> No argument for how you can put lots of stuff on a single prefix key can 
> overcome the fact that more prefix keys give you more than does one 
> prefix key.
>

"No argument can."?  "A man hears what he wants to hear, and disregards 
the rest." (Simon & Garfunkel)

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> |      (A)      |      (B)      |
> |---------------|---------------|
> | C-x j         | C-o j         |
> | C-x j = f     | C-o j = f     |
> | C-x j t . % + | C-o j t . % + |
> | C-x 4 j       | C-o 4 j       |
> | C-x x :       | C-o x :       |
> | C-x x t e     | C-o x t e     |
> | C-x x t + b   | C-o x t + b   |

You don't seem to be hearing that I want more
than just reserving one prefix key, `C-o'.

It's not about letting Emacs bind `C-x' keys
(and any other keys) by default, willy nilly,
and giving 3rd-party writers and other users
only `C-o'.

Reserving `C-o' for users and 3rd-party code
is a fine proposal.  I'd like the same thing
for `C-x j', `C-x x', and _all_ other keys
that Emacs does not currently bind by default
(not just `C-x' keys).

I'm suggesting a moratorium on Emacs binding
keys by default.

(And I mentioned that there could be exceptions,
in case of something discussed and considered
important enough.  The point is to try to
deal with the problem of a limited keyspace.)

Re: [External] : Re: Concern about new binding.

[Jean Louis]

* Drew Adams <drew.adams@oracle.com> [2021-02-06 21:10]:
> > |      (A)      |      (B)      |
> > |---------------|---------------|
> > | C-x j         | C-o j         |
> > | C-x j = f     | C-o j = f     |
> > | C-x j t . % + | C-o j t . % + |
> > | C-x 4 j       | C-o 4 j       |
> > | C-x x :       | C-o x :       |
> > | C-x x t e     | C-o x t e     |
> > | C-x x t + b   | C-o x t + b   |
> 
> You don't seem to be hearing that I want more
> than just reserving one prefix key, `C-o'.

I am using zile very often as Zile Is Lossy Emacs. Zile editor has C-o
that does same what current Emacs does. It adopted C-o because of
Emacs. Changing C-o in Emacs would break all the habits of using C-o
in Emacs like editors and Emacs like keybindings in other software. To
me that does not make sense.

There is `mg' editor that is used in BSD derivates as Emacs
replacement and it uses C-o to open-line

`qemacs' uses C-o to open-line because it follows Emacs key bindings.

`e3em' uses C-o to open-line because it follows Emacs key bindings.

Changing C-o would break users' habits, and many other editors rely on
some standard Emacs bindings. That introduces much confusion.

I realize you did not use C-o often and I am surprised, I have
observed few other people here also did not find use of C-o.

How do you open move the current line and come into previous line to
insert that one? That would involve something like C-a ENTER C-p if
cursor is not at beginning of the line. If cursor is at beginning then
ENTER C-p.

With C-o I do: C-a C-o if cursors is in the middle of the line and C-o
if cursor is at begin of the line. And I use C-o so often, many times
daily.

In vi editos I use "O".

Without knowing that some people never use C-o I found it very
important command, and while used in other editors I find it
surprising that proposals come to remove C-o to something else.

Removing C-o is to me same as removing C-x C-f

Those empty keys or less known C-x bindings would be just fine.

Jean

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > > | C-x j         | C-o j         |
> > > | C-x j = f     | C-o j = f     |
> > > ...
> >
> > You don't seem to be hearing that I want _more_
> > than just reserving one prefix key, `C-o'.

... <long reply about why `C-o' shouldn't be changed>

Why that reply to my message?  The point of my
message was simply that we should not reserve _only
one key_ for 3rd party use.  We should reserve more
than one, and the keys to reserve, to start with,
are those that are not yet bound.

I am NOT the one who started all the posts about
which keys already bound by default to reserve for
3rd-party use.  _MY_ proposal was instead to start
by reserving for 3rd-party use all keys currently
_NOT_ bound by default.  That's a completely
different approach.

It's Gregory who made a counter proposal to instead
reserve _only one_ prefix key for that, and also
changed to proposing, for that purpose, that Emacs
give up some key _already bound_.  And down the
rabbit hole we went...
___

I did say, as a _parallel_ idea, that Emacs could
also likely benefit from restructuring of existing
default key bindings.

I made the point that some keys bound by default to
repeatable keys are not used for repeatable commands,
and that their commands could usefully be made
repeatable, or those keys could instead be given to
other commands that are naturally repeatable.

And I made the point (and emphasized it _over_ the
point about repeatable commands) that some keys
bound by default to commands that maybe aren't so
useful overall could usefully be changed to prefix
keys instead.

And I made the point that a fair amount of useful
refactoring could be done by moving some commands
that are currently bound by default to bindings
under prefix keys.

But all of that parallel idea about possible changes
to Emacs default key bindings - refactoring - is
completely separate from the proposal I made about
reserving keys for 3rd-party code.
___

My proposal to reserve all currently unbound keys
for 3rd-party code is what I really argued for.  Any
discussion about changing existing key bindings can
go on and on, contentiously, and it is not urgent.

IMO it is more important to impose a moratorium
_now_ on Emacs grabbing more and more unbound keys
for its default bindings.

And the discussion that's ensued from Gregory's
counter proposal has made it all the more urgent to
do what I proposed.  There are suggestions from
that bindings-changes discussion for Emacs to grab
even _more_ unbound keys for default bindings.

Unfortunately, Gregory's counter proposal took over,
and there's (predictably) been a flurry of back &
forth about this, that, or the other key as a
candidate for repurposing.

I specifically wanted to avoid that.  (But yes,
when discussion about this or that key ensued, I 
occasionally added my 2 cents about the key.)

Re: [External] : Re: Concern about new binding.

[Alfred M. Szmidt]

   You don't seem to be hearing that I want more
   than just reserving one prefix key, `C-o'.

Most (All?) keyboards today have a Super key -- why not allocate that
or parts of it to global third-party packages?

This solves moving things around, and constantly breaking things for
people.  One could put up a similar scheme for reserving keys for
users, and third party keys there as it is done for C-.

The key is also easily rebindable to another position for those who so
wish, one can put it on the Fn keys, or on Caps-Lock.  Putting it
under a seperate super-map would also allow userss to put it under
some other key as well.

There are far more solutions to this problem than just unbinding keys
unconditionally for some unknown future case that nobody can figure
out.

Re: [External] : Re: Concern about new binding.

[Gregory Heytings]

>
> Most (All?) keyboards today have a Super key -- why not allocate that or 
> parts of it to global third-party packages?
>

Because the super modifier cannot be used in a terminal or console?

>
> This solves moving things around, and constantly breaking things for 
> people.
>

Is it not a slight exaggeration to say that Emacs is "constantly breaking 
things"?

>
> There are far more solutions to this problem than just unbinding keys 
> unconditionally for some unknown future case that nobody can figure out.
>

It's not "for some unknown future case that nobody can figure out", it's 
for a recurring problem that is becoming more and more important.  More 
and more users use Emacs, the extensible editor, with third-party 
extension libraries, and these these third-party extension libraries 
cannot create global key bindings.

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> Date: Fri, 12 Feb 2021 09:09:27 +0000
> From: Gregory Heytings <gregory@heytings.org>
> Cc: emacs-devel@gnu.org
> 
> > This solves moving things around, and constantly breaking things for 
> > people.
> 
> Is it not a slight exaggeration to say that Emacs is "constantly breaking 
> things"?

Yes, but only slight.

Re: [External] : Re: Concern about new binding.

[Alfred M. Szmidt]

   > Most (All?) keyboards today have a Super key -- why not allocate that or 
   > parts of it to global third-party packages?

   Because the super modifier cannot be used in a terminal or console?

That is simply not true.

   > This solves moving things around, and constantly breaking things for 
   > people.

   Is it not a slight exaggeration to say that Emacs is "constantly breaking 
   things"?

Is it? The build was just broken just recently.

   > There are far more solutions to this problem than just unbinding keys 
   > unconditionally for some unknown future case that nobody can figure out.

   It's not "for some unknown future case that nobody can figure out", it's 
   for a recurring problem that is becoming more and more important.  More 
   and more users use Emacs, the extensible editor, with third-party 
   extension libraries, and these these third-party extension libraries 
   cannot create global key bindings.

There is already a space where users (and what third party packages can
recommend users to use) can bind their keys.

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: "Alfred M. Szmidt" <ams@gnu.org>
> Date: Fri, 12 Feb 2021 10:11:40 -0500
> Cc: emacs-devel@gnu.org
> 
>    > This solves moving things around, and constantly breaking things for 
>    > people.
> 
>    Is it not a slight exaggeration to say that Emacs is "constantly breaking 
>    things"?
> 
> Is it? The build was just broken just recently.

The risk of breaking things is an inherent part of any development.
The master branch should not expected to be stable.  People who track
the master branch should expect the build to be broken, and should not
treat such breakage as a reason to reprimand the Emacs developers.

Re: [External] : Re: Concern about new binding.

[Gregory Heytings]

>>> Most (All?) keyboards today have a Super key -- why not allocate that 
>>> or parts of it to global third-party packages?
>>
>> Because the super modifier cannot be used in a terminal or console?
>
> That is simply not true.
>

That's what I thought until today, but indeed I may be wrong.  Could you 
please explain how it is possible to use the super modifier in a console?

>>> This solves moving things around, and constantly breaking things for 
>>> people.
>>
>> Is it not a slight exaggeration to say that Emacs is "constantly 
>> breaking things"?
>
> Is it? The build was just broken just recently.
>

Of course a development version is expected to break things from time to 
time.  If you want stability, use stable releases.  And I'd say that even 
the development version is pretty stable.  It breaks occasionally, yes, 
and when it does it's during a very short period of time.

>>> There are far more solutions to this problem than just unbinding keys 
>>> unconditionally for some unknown future case that nobody can figure 
>>> out.
>>
>> It's not "for some unknown future case that nobody can figure out", 
>> it's for a recurring problem that is becoming more and more important. 
>> More and more users use Emacs, the extensible editor, with third-party 
>> extension libraries, and these these third-party extension libraries 
>> cannot create global key bindings.
>
> There is already a space where users (and what third party packages can 
> recommend users to use) can bind their keys.
>

Yes, there is a space in which users can bind their keys, and as a matter 
of fact users can bind all keys the way they want it.

Yes, third party packages can recommend users to use this or that key for 
their commands, they can also recommend users to use keys that are not 
reserved for them, and as a matter of fact packages can also bind all keys 
the way they want it (that's more or less what evil-mode does), as nobody 
is forcing them to follow the key binding conventions.

The proposal is only to create a key space in which third party packages 
could automatically create global key bindings, without conflicting with 
Emacs core (that is, without rebinding any key bound in vanilla Emacs) and 
without conflicting with users' personal settings.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> The proposal is only to create a key space in which
> third party packages could automatically create global
> key bindings, without conflicting with Emacs core (that
> is, without rebinding any key bound in vanilla Emacs)
> and without conflicting with users' personal settings.

No, your proposal was not _only_ to do that.

_My_ proposal was to do that, and to do it for keys
that are not already bound by default - just reserve
those for 3rd-party code.

_Your_ proposal was to change some key that already
has a default binding, and give it -- and ONLY it --
to 3rd-party libraries as a prefix key.
___

The _problem_ is indeed encroaching Emacs default key
bindings narrowing the usable keyspace for 3rd-party
code.

The best _solution_, which requires _NO_ discussion of
sacrificing this or that key already bound by default,
is to declare a moratorium on Emacs grabbing any more
_unbound_ keys by default (modulo possible important
exceptions, which would invite discussion and then
decision by maintainers).

Unfortunately, by you tossing your counter-proposal
into the ring, we've, quite predictably, gone down the
rabbit hole of my-key vs your-key, this-key vs that-key.

There's no reason, in order to reserve keys for
3rd-party use, to start by sacrificing _any_ keys from
those bound by default.  Not even one.  Not this one.
Not that one.  Not one.

RE: [External] : Re: Concern about new binding.

[Gregory Heytings]

>> The proposal is only to create a key space in which third party 
>> packages could automatically create global key bindings, without 
>> conflicting with Emacs core (that is, without rebinding any key bound 
>> in vanilla Emacs) and without conflicting with users' personal 
>> settings.
>
> No, your proposal was not _only_ to do that.
>
> _My_ proposal was to do that, and to do it for keys that are not already 
> bound by default - just reserve those for 3rd-party code.
>

... and two maintainers replied to that proposal that they will never 
agree with it.  Again, it would be better to take that as a postulate for 
further reflection.

>
> _Your_ proposal was to change some key that already has a default 
> binding, and give it -- and ONLY it -- to 3rd-party libraries as a 
> prefix key.
>

Yes, that's what "to create a key space" means.

It's a compromise between "being free to reclaim any key at any time" and 
"being constrained to not use any key it doesn't yet use".  IOW, it's a 
compromise between "keeping all keys" and "giving away all unbound keys". 
The compromise is to give away one or two keys, and to keep the other 
ones.  Such a compromise would give as much freedom as possible to Emacs, 
as much freedom as possible to third-party libraries, without changing 
users' habits too much.

Super key in console?

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-12 19:57]:
> 
> > > > Most (All?) keyboards today have a Super key -- why not allocate
> > > > that or parts of it to global third-party packages?
> > > 
> > > Because the super modifier cannot be used in a terminal or console?
> > 
> > That is simply not true.
> > 
> 
> That's what I thought until today, but indeed I may be wrong.  Could you
> please explain how it is possible to use the super modifier in a
> console?

I know it can be used in Terminal under X with special settings of X
keymap but I have not found good settings, if somebody does, let us
know it here as least for X terminal emulators.

Some references are here:
https://www.emacswiki.org/emacs/MetaKeyProblems but do not really
offer solution that I need.

Here is reference how to make it work in Urxvt:
https://www.reddit.com/r/emacs/comments/6i0k6y/super_key_maps_to_nothing_in_emacs_nw/

For `konsole' terminal emulator it works right away. That is great,
but again graphical. Still good for remote work with Super key.

For `xterm' this link does not work any more, and I would like to get
xterm-extras.el
https://www.emacswiki.org/emacs/XtermExtras

It would be really good that Super works in console without X. Is
there any way to make it work?

Jean

Re: [External] : Re: Concern about new binding.

[Alfred M. Szmidt]

   >>> Most (All?) keyboards today have a Super key -- why not allocate that 
   >>> or parts of it to global third-party packages?
   >>
   >> Because the super modifier cannot be used in a terminal or console?
   >
   > That is simply not true.

   That's what I thought until today, but indeed I may be wrong.  Could you 
   please explain how it is possible to use the super modifier in a console?

Without any reconfigs, "C-x @ s x" for s-x (see the
event-apply-FOO-modifier functions).

On GNU/Linux systems you can rebind Super_L/R to a Fn key or some
other such thing, and use it that way.  I think you can check the
loadkys and dumpkeys commands.

   The proposal is only to create a key space in which third party packages 
   could automatically create global key bindings, without conflicting with 
   Emacs core (that is, without rebinding any key bound in vanilla Emacs) and 
   without conflicting with users' personal settings.

There is no reason to free up M-o for that specific purpose, for
example.  Drew's moratorium suggestion is also a good solution, and
does not remove functionality.

Re: [External] : Re: Concern about new binding.

[Gregory Heytings]

>> That's what I thought until today, but indeed I may be wrong.  Could 
>> you please explain how it is possible to use the super modifier in a 
>> console?
>
> Without any reconfigs, "C-x @ s x" for s-x (see the 
> event-apply-FOO-modifier functions).
>

That's not "using the super modifier", that's "a trick to fake the use of 
the super modifier".

>
> On GNU/Linux systems you can rebind Super_L/R to a Fn key or some other 
> such thing, and use it that way.  I think you can check the loadkys and 
> dumpkeys commands.
>

Of course, everything is possible with tricks that most users don't know 
and will never know.  What is important is that it doesn't work out of the 
box.  Emacs does not assume users have a super modifier, third-party 
libraries can't assume that either.

Re: [External] : Re: Concern about new binding.

[Alfred M. Szmidt]

   >> That's what I thought until today, but indeed I may be wrong.  Could 
   >> you please explain how it is possible to use the super modifier in a 
   >> console?
   >
   > Without any reconfigs, "C-x @ s x" for s-x (see the 
   > event-apply-FOO-modifier functions).

   That's not "using the super modifier", that's "a trick to fake the use of 
   the super modifier".

The claim here was that it cannot be used, it can and trivially so and
works out of the box.  The super modifier (and hyper, etc) are fully
supported by Emacs.

The "trick" is exactly the same as for Meta which also has issues on
consoles (on OpenBSD you need to explicitly fix it for example, same
on some GNU/Linux systems).

There is also another key space that is already used by Emacs, and
that is Alt.  E.g, A-}, A-a < etc.

Re: [External] : Re: Concern about new binding.

[Gregory Heytings]

>>>>>> Most (All?) keyboards today have a Super key -- why not allocate 
>>>>>> that or parts of it to global third-party packages?
>>>>>
>>>>> Because the super modifier cannot be used in a terminal or console?
>>>>
>>>> That's what I thought until today, but indeed I may be wrong.  Could 
>>>> you please explain how it is possible to use the super modifier in a 
>>>> console?
>>>
>>> Without any reconfigs, "C-x @ s x" for s-x (see the 
>>> event-apply-FOO-modifier functions).
>>
>> That's not "using the super modifier", that's "a trick to fake the use 
>> of the super modifier".
>
> The claim here was that it cannot be used, it can and trivially so and 
> works out of the box.  The super modifier (and hyper, etc) are fully 
> supported by Emacs.
>

It seems that you forgot the context of the discussion.  I was replying to 
your suggestion (see above) to "allocate the super key to third party 
packages".  Typing "C-x @ s" is not "using the super key", it's a last 
resort possibility to fake the use of a super modifier.  When you want to 
call goto-line, I'd bet you type "M-g M-g", not "C-x @ m g C-x @ m g".

Re: [External] : Re: Concern about new binding.

[Alfred M. Szmidt]

   It seems that you forgot the context of the discussion.  I was replying to 
   your suggestion (see above) to "allocate the super key to third party 
   packages".  Typing "C-x @ s" is not "using the super key", it's a last 
   resort possibility to fake the use of a super modifier.  When you want to 
   call goto-line, I'd bet you type "M-g M-g", not "C-x @ m g C-x @ m g".

And the solution to removing M-o M-s was to write "M-x center-line" or
rebinding the key.  So you could just type M-x goto-line if it doesn't
work, how come that is no longer a solution here?

Re: [External] : Re: Concern about new binding.

[Stefan Monnier]

>    > Without any reconfigs, "C-x @ s x" for s-x (see the 
>    > event-apply-FOO-modifier functions).
>    That's not "using the super modifier", that's "a trick to fake the use of 
>    the super modifier".
> The claim here was that it cannot be used, it can and trivially so and
> works out of the box.

Last I checked the `C-x @` thingies for modifiers only work partly: you
can't combine them as in `C-x @ h C-x @ s x` to do `H-s-x`.

> The super modifier (and hyper, etc) are fully supported by Emacs.

Definitely, and AFAIK it is in fairly wide use, so we'd notice quickly
if something broke it.


        Stefan

RE: [External] : Re: Concern about new binding.

[Drew Adams]

>    You don't seem to be hearing that I want more
>    than just reserving one prefix key, `C-o'.
> 
> There are far more solutions to this problem than
> just unbinding keys unconditionally for some unknown
> future case that nobody can figure out.

I never suggested unbinding any keys, to reserve
them for 3rd-party code.  I proposed that we put
in place a moratorium on Emacs binding any more
unbound keys, and that keys that currently are
_not_ bound by default be reserved for 3rd-party
code.

The idea is that Emacs stop grabbing virgin
territory for new default key bindings.  This
proposal I made didn't call for unbinding any
keys.

Re: [External] : Re: Concern about new binding.

[Alfred M. Szmidt]

   I never suggested unbinding any keys, to reserve
   them for 3rd-party code.  I proposed that we put
   in place a moratorium on Emacs binding any more
   unbound keys, and that keys that currently are
   _not_ bound by default be reserved for 3rd-party
   code.

   The idea is that Emacs stop grabbing virgin
   territory for new default key bindings.  This
   proposal I made didn't call for unbinding any
   keys.

Drew's proposal is also a good one.

Re: [External] : Re: Concern about new binding.

[Karthik Chikmagalur]

"Alfred M. Szmidt" <ams@gnu.org> writes:

> Most (All?) keyboards today have a Super key -- why not allocate that
> or parts of it to global third-party packages?

The super key is used by desktop environments, window managers or by
Windows for system level functions. For example, super+p brings up the
display/projector configuration menu on KDE and in Windows. super+l
locks the screen in windows. Pressing super brings up an activities menu
in Gnome. These are often not easy to rebind at the system level
(without significant tweaking) and Emacs cannot use them easily.

Re: [External] : Re: Concern about new binding.

[Jean Louis]

* Karthik Chikmagalur <karthikchikmagalur@gmail.com> [2021-02-13 04:52]:
> "Alfred M. Szmidt" <ams@gnu.org> writes:
> 
> > Most (All?) keyboards today have a Super key -- why not allocate that
> > or parts of it to global third-party packages?
> 
> The super key is used by desktop environments, window managers or by
> Windows for system level functions. For example, super+p brings up the
> display/projector configuration menu on KDE and in Windows. super+l
> locks the screen in windows. Pressing super brings up an activities menu
> in Gnome. These are often not easy to rebind at the system level
> (without significant tweaking) and Emacs cannot use them easily.

That is not a reason to reject as that assumes generalized desktop
environments. They also use Control and Alternative in combinations,
so that would not be a reason to reject using Super in Emacs.

Good example is Alt-TAB that is often overwritten or used by Window
Manager but it has function in Emacs (don't stone me if I do not
remember which one), maybe completion, I do not remember.

You use those environments, I don't. I am using simple Window
managers, it works well for me.

Reservation of keys is not absolute reservation. But in general I
would say that there is no need for any reservations as it will not
solve problems of collisions.

Re: [External] : Re: Concern about new binding.

[Philip Kaludercic]

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

"Alfred M. Szmidt" <ams@gnu.org> writes:

>    You don't seem to be hearing that I want more
>    than just reserving one prefix key, `C-o'.
>
> Most (All?) keyboards today have a Super key -- why not allocate that
> or parts of it to global third-party packages?

I can imagine that window managers shadow that key for their own
functionality -- this danger exists for all super keys.

-- 
	Philip K.

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

Re: Concern about new binding.

[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 seems to me that the root problem of this thread, and similar ones in 
  > the past months, is the lack of a convention for external packages in 
  > `(elisp) Key Binding Conventions'.  There is a convention for users, there 
  > are conventions for major and minor modes, but there is no convention for 
  > external packages such as Magit, Drew's packages, and so forth. 

This is a good point.  Maybe we should come up with one.

It may be difficult, though, because good decisions would depend on
how important each package is.

If a package becomes very popular, and we include it in Emacs, we
would want to give it a binding that doesn't conflict with anything
else.  That would mean changing its binding.

-- 
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: Concern about new binding.

[Jean Louis]

* Gregory Heytings <gregory@heytings.org> [2021-02-05 12:23]:
> 
> It seems to me that the root problem of this thread, and similar ones in the
> past months, is the lack of a convention for external packages in `(elisp)
> Key Binding Conventions'.  There is a convention for users, there are
> conventions for major and minor modes, but there is no convention for
> external packages such as Magit, Drew's packages, and so forth.
> Consequently, the only solution for such packages is to use the currently
> empty slots, with a sword of Damocles hanging over them: these empty slots
> could at any time be reclaimed by Emacs.  I too can sympathize with Drew's
> (and other's) frustration when this happens.

I am using Super key, the one between Ctrl and Alt. If Emacs on
console would found automatic way to recognize that key in the same
way how it recognizes it under X or graphical environment then maybe
it could be one of solutions for third party packages. 

> This proposal has two forms: a weak and a strong one.  The weak one would
> only reserve the control key, the strong one would also reserve the meta and
> control-meta keys.

Meta or Alternative is just fine, it is equivalent to Control key,
just one key. Both Control and Alternative (Meta) are harder to type
and really not convenient for third party packages.

> The candidate keys for that proposal are "z", "t" and "o".

C-z, C-t, C-o are old commands. C-t works in bash the same, why then
change the default Emacs binding that has been reflected into many
other Emacs-like editors? Those proposals come very surprising to me.

> IOW, one could for example reserve either "C-z" (weak version), or "C-z" and
> "M-z" and "C-M-z" (strong version), for external packages.

M-z is just fine to replace as it is not implemented in other
Emacs-like editors and is not common, it is very nice and would
disturb people using the zap to char. Somebody's habits will be
sacrificed anyway.

> This is a one-time change, which I'm sure will not be an easy one
> for everyone, but is a long-term solution that will avoid such
> repeated wars.

As long as it is not C-z, C-t, C-o.

Re: [External] : Re: Concern about new binding.

[Jean Louis]

* Ergus <spacibba@aol.com> [2021-02-04 01:38]:
> I think Gregory already proposed the best approach, but now people are
> arguing about Magit, projectile or philosophical questions.
> 
> IMHO, I would prefer that after a deadline you make a decision (even if
> it is the opposite to what I expect) and close it. Otherwise it becomes
> a never ending collections of emails with no final results...

I can understand that you had a purpose of discussion and such is
probably reflected in the subject. Your focus is or was on the
purpose. But then many people participate introduced various useful
details. That makes the discussion informative, thought provoking and
educational. I learn about other people's habits in using Emacs and
their thoughts in developments. References to manuals then help me
make better decisions on key bindings in packages I am developing.

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> Date: Fri, 12 Feb 2021 11:19:45 +0300
> From: Jean Louis <bugs@gnu.support>
> Cc: Eli Zaretskii <eliz@gnu.org>, emacs-devel@gnu.org, rms@gnu.org,
>  drew.adams@oracle.com, kevin.legouguec@gmail.com
> 
> But then many people participate introduced various useful
> details. That makes the discussion informative, thought provoking and
> educational. I learn about other people's habits in using Emacs and
> their thoughts in developments. References to manuals then help me
> make better decisions on key bindings in packages I am developing.

That kind of discussion is better taken elsewhere: help-gnu-emacs, for
example.

Re: [External] : Re: Concern about new binding.

[Jean Louis]

* Eli Zaretskii <eliz@gnu.org> [2021-02-03 21:15]:
> > Date: Wed, 3 Feb 2021 19:01:42 +0100
> > From: Ergus <spacibba@aol.com>
> > Cc: Drew Adams <drew.adams@oracle.com>, emacs-devel@gnu.org,
> > 	kevin.legouguec@gmail.com, rms@gnu.org
> > 
> > >
> > >> IMO, the binding should be removed until/unless
> > >> the discussion here leads to a decision to add
> > >> it back again.
> > >
> > >Please wait till the discussion comes to its conclusion.
> > 
> > In my short experience here; when discussions start like this; then
> > there is never a conclusion. They just slowly stop and no change is made
> > at the end. I someone insists after some time, the again the same...
> > 
> > In 3 years I have more than 30 examples...
> 
> I don't think I understand what you are saying.  You started this
> discussion.  If you don't like how discussions happen here, why did
> you start it?

https://www.gnu.org/fun/jokes/users-lightbulb.html

Re: [External] : Re: Concern about new binding.

[Joost Kremers]

On Wed, Feb 03 2021, Drew Adams wrote:
> That's the problem: the discussion of a narrow
> feature request and possible solutions turned
> into a wider discussion.  _And_ someone there
> decided to change Emacs to add a global key
> for reverting buffers.

As an Emacs maintainer, isn't that their prerogative?


-- 
Joost Kremers
Life has its moments

RE: [External] : Concern about new binding.

[Drew Adams]

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

> In a recent commit I see that the C-x g binding was taken for
> revert-buffer.
> 
> I suppose this should have been discussed previously, unless I don't
> find the thread... but I have some concerns about this.
> 
> 1) In general `C-x g` is used by magit; I know this is not a priority
> (cause magit is an external package), but magit is a very popular
> package.
> 
> 2) In some threads before we have discussed that relative short
> combinations must be reserved to maps in order to economize them...
> 
> 3) In spite of revert-buffer is a very useful command it is useless in
> many conditions like when auto-revert-mode is enable... so maybe it
> makes sense to bind it to something longer (ex: C-x g r)??
> 
> There are more commands that could be set in a map inside C-x g IMHO:
> toggle-read-only revert-buffer-with-fine-grain something to
> enable/disable font-lock etc
> 
> This way instead of limiting; could open a big spot to set useful
> commands. I understand that longer commands are harder to discover, but
> hopefully we could have which-key in the next release?
> 
> I hope I am writing this soon enough that the author could consider
> revert this change maybe with something more "general" does it makes
> sense??

See attached mails, and the thread for bug #46151.
I end that second mail saying this:

  All proposals to sacrifice keys to default bindings
  should really be discussed on emacs-devel.

The first mail reiterates the reasons I oppose this
binding.

[-- Attachment #2: Type: message/rfc822, Size: 16089 bytes --]

From: Drew Adams <drew.adams@oracle.com>
To: Lars Ingebrigtsen <larsi@gnus.org>, Sean Whitton <spwhitton@spwhitton.name>
Cc: "46151@debbugs.gnu.org" <46151@debbugs.gnu.org>
Subject: bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers
Date: Mon, 1 Feb 2021 16:14:13 +0000
Message-ID: <SA2PR10MB447470DA936B9CA0B2C8B9FDF3B69@SA2PR10MB4474.namprd10.prod.outlook.com>

> I think a global `revert-buffer' binding is the way to go.  How to
> reload a file is something that comes up all the time, so I think it is
> high time it got bound.

I disagree, for reasons given before:

1. Anyone who wants it can bind it.  (I do.)

2. It has no meaning for many modes.  By its
   very nature it is essentially mode-specific.

3. Modes where it is useful typically already
   bind it.  And they bind it to a key that
   makes sense for that particular mode.
   You just need to use `C-h m' to find out
   what the key is.

4. Given #3, if you add a global binding for
   it then there's not much point in those
   mode-specific bindings.

5. Emacs has been fine for 35+ years without
   any global binding for it.  The "Founders"
   knew what they were doing in this regard.
   (Perhaps they were thinking of some of this
   list.)

6. Emacs should impose a moratorium on itself
   NOW, to stop binding keys by default.  Just
   say NO.

   Seriously.

   The few keys that still have no default
   global bindings should be left as is, in
   general - left for users and 3rd-party code.

7. IF many users start using some binding over
   a period of years THEN Emacs can consider
   giving it a default binding.  Don't be
   prematurely "optimizing" UI in this way for
   people when there has been no popular
   request for it.

8. YAGNI.

One opinion.




[-- Attachment #3: Type: message/rfc822, Size: 15544 bytes --]

From: Drew Adams <drew.adams@oracle.com>
To: Sean Whitton <spwhitton@spwhitton.name>, Lars Ingebrigtsen <larsi@gnus.org>
Cc: "46151@debbugs.gnu.org" <46151@debbugs.gnu.org>
Subject: bug#46151: [External] : bug#46151: 28.0.50; Set revert-buffer-function in shell command output buffers
Date: Mon, 1 Feb 2021 19:43:11 +0000
Message-ID: <SA2PR10MB447405B60C67BB0746331779F3B69@SA2PR10MB4474.namprd10.prod.outlook.com>

> > I think a global `revert-buffer' binding is the way to go.  How to
> > reload a file is something that comes up all the time, so I think it
> > is high time it got bound.
> 
> Okay, here is a patch.

Please don't do this.  Don't remove `C-x g' from
the little remaining virgin (non-default) key
territory.

It is not "high time" to bind this or any other
key by default.  It's high time to _desist_ from
having default Emacs taking over more territory.
It doesn't need it, and it shouldn't take it.

35 years with no global binding for `revert-buffer'.
No problem - thousands of users and hackers.  But
now, from one user request Lars decides it's "high
time"...  No need.

All proposals to sacrifice keys to default bindings
should really be discussed on emacs-devel.

Re: Concern about new binding.

[Karl Fogel]

On 02 Feb 2021, Ergus wrote:
>1) In general `C-x g` is used by magit; I know this is not a 
>priority (cause magit is an external package), but magit is a 
>very popular package. 

While Magit is indeed very popular and valuable, shouldn't it 
still adhere to convention and avoid binding things in the `C-x' 
space?

That's really a point to be made on the Magit development mailing 
list, not here, but what I'm saying here is that Emacs shouldn't 
make special efforts to avoid interfering with package keybindings 
that violate Emacs's conventions anyway.

Magit should instead suggest `C-c g' as an entry point for
`magit-status', though a user can bind it however they want of course.
I doubt there are any Magit users who would be daunted by the need to
set up a keybinding for Magit's entry point.

Best regards,
-Karl

Invoking Magit (was: Concern about new binding)

[Stefan Monnier]

> Magit should instead suggest `C-c g' as an entry point for
> `magit-status', though a user can bind it however they want of course.
> I doubt there are any Magit users who would be daunted by the need to
> set up a keybinding for Magit's entry point.

I think it'd make more sense to use a keybinding under the `C-x v`
prefix.  Another option would be to hijack `find-file` like PCL-CVS did,
i.e. make it so `C-x C-f .../.git` opens up Magit.


        Stefan

Re: Invoking Magit

[Karl Fogel]

On 02 Feb 2021, Stefan Monnier wrote:
>> Magit should instead suggest `C-c g' as an entry point for 
>> `magit-status', though a user can bind it however they want of 
>> course.  I doubt there are any Magit users who would be daunted 
>> by the need to set up a keybinding for Magit's entry point. 
> I think it'd make more sense to use a keybinding under the `C-x 
>v` prefix.

Well, sure, if Emacs wants to deliberately give some keybinding 
space to a popular 3rd-party package like Magit, that's fine 
(personally I think I'd be in favor in this case, given Magit's 
popularity).

But Emacs makes that decision, not Magit.  In other words, the 
crucial question is: who exactly is the subject of the verb "use" 
in your last sentence above?  Is it Emacs, or the user?

Emacs already has conventions [1] about keyspaces reserved for 
users versus those reserved for packages (well, modes, and this 
entry point to Magit is not exactly a mode).  According to those 
conventions:

  * `C-c LETTER' is for users to do with as they like -- neither 
  Emacs 
    nor third-party packages should ever bind anything here.

  * `C-c C-LETTER' and `C-c DIGIT' and `C-c {}<>:;' are all 
  reserved for 
    major modes.  In this case it doesn't matter whether the mode 
    ships with GNU Emacs or is a 3rd-party mode, since only one 
    major mode is active at a given time.  If a user has chosen 
    the mode, then they accept that part of the keybinding space 
    (sure, they might customize it further, but that's up to them 
    -- they understand that they may overwrite default bindings of 
    the mode when they do that).

  * `C-c OTHER_STUFF' is for minor modes; I'll skip the details 
  here.

So Emacs is free to reserve space under `C-x v' for Magit entry 
points if it wants to.  That would be an unusual decision, but 
there's no reason not to consider it.  However, when you wrote 
this...

>I think it'd make more sense to use a keybinding under the `C-x 
>v` prefix.

...I couldn't tell whether you meant it would make more sense for 
*users* to do that (i.e., by their choice), or for *Emacs* to do 
that (i.e., we reserve that slot for Magit).

IMHO we shouldn't recommend the former, because we already 
recommend to users that `C-c LETTER' is where they should do such 
custom bindings, and we should encourage use of that convention.

But if you meant the latter, then that's a different discussion 
and one worth having.

>Another option would be to hijack `find-file` like PCL-CVS did, 
>i.e. make it so `C-x C-f .../.git` opens up Magit. 

(Oh my gosh, it's been *years* since I used PCL-CVS... you are 
bringing back memories... :-) )

I hope we wouldn't do that here.  There are many reasons why 
someone might open up a .git directory in Dired Mode (I do it all 
the time) by doing `C-x C-f .../.git'.

Best regards, -Karl 

[1] 
https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

Re: Invoking Magit

[Stefan Monnier]

>  * `C-c LETTER' is for users to do with as they like -- neither   Emacs
>    nor third-party packages should ever bind anything here.
>
>  * `C-c C-LETTER' and `C-c DIGIT' and `C-c {}<>:;' are all   reserved for
>    major modes.  In this case it doesn't matter whether the mode     ships
>    with GNU Emacs or is a 3rd-party mode, since only one     major mode is
>    active at a given time.  If a user has chosen     the mode, then they
>    accept that part of the keybinding space     (sure, they might customize
>    it further, but that's up to them     -- they understand that they may
>    overwrite default bindings of     the mode when they do that).
>
>  * `C-c OTHER_STUFF' is for minor modes; I'll skip the details   here.

Those are for use *within* the major/minor mode.
The keybinding under discussion is a global one to make it easier to
enter Magit.  It doesn't have much choice but to collide
with something :-(

But sometimes the better answer is not to use a keybinding at all.

>> I think it'd make more sense to use a keybinding under the `C-x v` prefix.
> ...I couldn't tell whether you meant it would make more sense for *users* to
>  do that (i.e., by their choice), or for *Emacs* to do that (i.e., we
> reserve that slot for Magit).

Neither/both.  I meant for Magit to do that.

>> Another option would be to hijack `find-file` like PCL-CVS did, i.e. make
>> it so `C-x C-f .../.git` opens up Magit. 
> (Oh my gosh, it's been *years* since I used PCL-CVS... you are bringing back
> memories... :-) )
> I hope we wouldn't do that here.  There are many reasons why someone might
> open up a .git directory in Dired Mode (I do it all the time) by doing `C-x
> C-f .../.git'.

I've never been super happy with that trick in PCL-CVS either, but in
practice it worked great, IME.  Of course, you sometimes do want to look
at the CVS/.git/younameit dir or file, but that's what the C-u prefix
was for.

I do feel that Emacs would gain by developing some way to specify
interactively *how* a given file should be viewed.  In most cases
there's only one reasonable choice, admittedly, but I find more and more
cases where this is not so (e.g. ps-as-image vs ps-as-text,
djvu-with-djvu-mode vs djvu-with-doc-view, odt-with-doc-view vs
odt-as-zip-archive, html-as-text vs html-via-shr, ...).


        Stefan

Re: Invoking Magit

[Karl Fogel]

On 02 Feb 2021, Stefan Monnier wrote:
>Those are for use *within* the major/minor mode.  The keybinding 
>under discussion is a global one to make it easier to enter 
>Magit.  It doesn't have much choice but to collide with something 
>:-( 

Yes, I know?  (Sorry; I think you maybe thought I was saying 
something I wasn't saying.)
 
>>> I think it'd make more sense to use a keybinding under the 
>>> `C-x v` prefix. 
>> ...I couldn't tell whether you meant it would make more sense 
>> for *users* to 
>>  do that (i.e., by their choice), or for *Emacs* to do that 
>>  (i.e., we 
>> reserve that slot for Magit). 
> Neither/both.  I meant for Magit to do that. 

What I'm proposing is cooperation between Emacs and popular 
independent 3rd-party packages:

Emacs reserves certain bindings for a given package, so that when 
the package maintainers use those bindings, they know it's safe. 
Emacs would maintain a registry so it's clear to everyone what's 
going on.

Let me put it this way:

If Magit were shipped as part of Emacs, there would be no question 
in about what to do, right?  Emacs would choose keybindings for 
the Magit entry points, the same way Emacs chooses keybindings for 
anything else.

All I'm saying is, the fact that Magit is not shipped with Emacs 
is largely irrelevant here.  What matters is its popularity, not 
its provenance.  Emacs can still reserve keybindings for it, and 
the fact that the package is supplied from elsewhere is fine.

(What those bindings would do when the package isn't loaded is 
simply display information about where to get the package in 
questions.)

Best regards,
-Karl

Re: Concern about new binding.

[Thibaut Verron]

2021-02-02 17:50 UTC+01:00, Karl Fogel <kfogel@red-bean.com>:
> On 02 Feb 2021, Ergus wrote:
>>1) In general `C-x g` is used by magit; I know this is not a
>>priority (cause magit is an external package), but magit is a
>>very popular package.
>
> While Magit is indeed very popular and valuable, shouldn't it
> still adhere to convention and avoid binding things in the `C-x'
> space?
>
> That's really a point to be made on the Magit development mailing
> list, not here, but what I'm saying here is that Emacs shouldn't
> make special efforts to avoid interfering with package keybindings
> that violate Emacs's conventions anyway.
>
> Magit should instead suggest `C-c g' as an entry point for
> `magit-status', though a user can bind it however they want of course.
> I doubt there are any Magit users who would be daunted by the need to
> set up a keybinding for Magit's entry point.

To be clear, Magit itself does not bind anything by default. It
suggests "C-x g" as a binding, and I see now that it also offers an
option to enable that binding for the user.

It is not the only high-level package using "C-x letter" as an entry
point, another example coming to mind is projectile ("C-x p").

As for the conventions, as far as I can tell, they explicitly require
to steer clear of "C-c letter", but they don't have anything about
"C-x letter":
https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

Thibaut

Re: Concern about new binding.

[Sean Whitton]

Hello,

On Tue 02 Feb 2021 at 06:45PM +01, Thibaut Verron wrote:

> To be clear, Magit itself does not bind anything by default. It
> suggests "C-x g" as a binding, and I see now that it also offers an
> option to enable that binding for the user.

Actually, it's on by default in current git master and in the version of
magit in Debian.

> It is not the only high-level package using "C-x letter" as an entry
> point, another example coming to mind is projectile ("C-x p").

No, projectile was C-c p, but it eventually removed it and just
suggested in its docs that users bind it themselves.

I think that approach would be sensible for magit too.

> As for the conventions, as far as I can tell, they explicitly require
> to steer clear of "C-c letter", but they don't have anything about
> "C-x letter":
> https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

AFAICT, there's an implicit additional convention that major and minor
modes stick to the sequences that are reserved for them.  Given this,
ISTM that as magit chose to bind C-x g, there was inevitably going to be
a clash like this sooner or later.

-- 
Sean Whitton

Re: Concern about new binding.

[Karl Fogel]

On 02 Feb 2021, Sean Whitton wrote:
>No, projectile was C-c p, but it eventually removed it and just 
>suggested in its docs that users bind it themselves.   I think 
>that approach would be sensible for magit too. 

+1, but apparently the Magit devs considered that possibility and 
rejected it :-/.
 
>AFAICT, there's an implicit additional convention that major and 
>minor modes stick to the sequences that are reserved for them. 
>Given this, ISTM that as magit chose to bind C-x g, there was 
>inevitably going to be a clash like this sooner or later. 

Agreed.

Re: Concern about new binding.

[Karl Fogel]

On 02 Feb 2021, Thibaut Verron wrote:
>2021-02-02 17:50 UTC+01:00, Karl Fogel <kfogel@red-bean.com>: 
>> On 02 Feb 2021, Ergus wrote: 
>>>1) In general `C-x g` is used by magit; I know this is not a 
>>>priority (cause magit is an external package), but magit is a 
>>>very popular package. 
>> 
>> While Magit is indeed very popular and valuable, shouldn't it 
>> still adhere to convention and avoid binding things in the 
>> `C-x' space? 
>> 
>> That's really a point to be made on the Magit development 
>> mailing list, not here, but what I'm saying here is that Emacs 
>> shouldn't make special efforts to avoid interfering with 
>> package keybindings that violate Emacs's conventions anyway. 
>> 
>> Magit should instead suggest `C-c g' as an entry point for 
>> `magit-status', though a user can bind it however they want of 
>> course.  I doubt there are any Magit users who would be daunted 
>> by the need to set up a keybinding for Magit's entry point. 
> To be clear, Magit itself does not bind anything by default. It 
>suggests "C-x g" as a binding, and I see now that it also offers 
>an option to enable that binding for the user. 

Actually, Magit does bind `C-x g' by default.

There is a defcustom, `magit-define-global-key-bindings', and it 
defaults to `t' in magit.el since October 2020 -- see [1] for the 
history of that decision.  When that variable is true, then that 
keybinding (and two others) are made automatically by Magit at 
load time.

>It is not the only high-level package using "C-x letter" as an 
>entry point, another example coming to mind is projectile ("C-x 
>p").   As for the conventions, as far as I can tell, they 
>explicitly require to steer clear of "C-c letter", but they don't 
>have anything about "C-x letter": 
>https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html 

Uh, I mean... sure, okay, those guidelines don't say anything 
explicit about not binding `C-x LETTER' in your 3rd-party package, 
but does that kind of guidance really have to be made explicit? 
This is Emacs: everyone who develops for Emacs knows that the 
`C-x' map is crowded and used heavily by Emacs.  If everyone's 
packages started binding things under there, they'd simply collide 
with *each other* all the time, as well as (eventually) with Emacs 
when Emacs decides to add a new `C-x' binding, as happened here.

I mean, the guidelines don't say to avoid rebinding the letter `a' 
either, but people know not to do that :-).

Magit should explicitly advise users to use `C-c LETTER' for 
Magit's entry points.  The user-reserved space is there under `C-c 
LETTER' precisely so users can bind entry points to their favorite 
functionality.

In other words, while Magit itself should "steer clear" of binding 
things under either `C-x' or `C-c LETTER', Magit is perfectly free 
to make recommendations.  Right now, Magit's three main entry 
points are:

  C-x g     `magit-status' C-x M-g   `magit-dispatch' C-c M-g 
  `magit-file-dispatch' 
 
And the doc string for `magit-define-global-key-bindings' even 
says the following: 
 
  > We recommend that you bind "C-c g" instead of "C-c M-g" to 
  > `magit-file-dispatch'.  The former is a much better binding 
  > but the "C-c <letter>" namespace is strictly reserved for 
  > users; preventing Magit from using it by default. 

Now, clearly Magit's developers knew about the convention and 
decided to clobber the Emacs-reserved space anyway.  I totally 
understand why they did so, even though I disagree with the 
decision.

One solution to this would be for Emacs to reserve some keyspace 
for those three Magit entry points explicitly, outside the `C-c 
WHATEVER'
conventions.  Maybe it would be under `C-x', or maybe somewhere 
else.  Magit is so popular that this might make sense -- 
essentially, bring Magit back into keybinding compliance by 
creating a reserved space for it.

I'm not sure why Magit doesn't ship with Emacs; I presume it has 
something to do with copyright assignment issues.  But I think the 
question of whether a package ships with Emacs can be, in 
principle, be independent of the question of whether Emacs 
reserves some keybinding space for that package.  That might sound 
like a weird idea, but Magit is a good example of a situation 
where it could make sense.

Best regards, -Karl 

[1] commit 5a38e1bb0fffa0326a1b5073c0ce9b05386e5109
    Author:     Jonas Bernoulli <jonas@bernoul.li>
    AuthorDate: Sat Oct 31 20:16:01 2020 +0100
    Commit:     Jonas Bernoulli <jonas@bernoul.li>
    CommitDate: Fri Nov 6 21:40:17 2020 +0100
    
        Add three global key bindings by default
        
        For the longest time we have tried hard to avoid doing this but
        it is just not worth the effort and leads to an inferior result.
        
        Now we add three bindings by default.
        
          ;;;###autoload
          (when magit-define-global-key-bindings
            (let ((map (current-global-map)))
              (define-key map (kbd "C-x g")   'magit-status)
              (define-key map (kbd "C-x M-g") 'magit-dispatch)
              (define-key map (kbd "C-c M-g") 'magit-file-dispatch)))
        
        As you can see is easy to prevent these bindings from being added
        and I hope having to do so won't upset anyone too much.  While we
        did not add global bindings we already added these bindings in all
        file-visiting buffers and we did not get any complaints about that.
        
        This completely replaces `magit-file-mode' and the global variant,
        which we define as an alias of the new variable.
        
        See #4237.
    
    M	Documentation/magit.org
    M	Documentation/magit.texi
    M	lisp/magit-files.el
    M	lisp/magit.el

Re: Concern about new binding.

[Thibaut Verron]

2021-02-02 19:51 UTC+01:00, Karl Fogel <kfogel@red-bean.com>:
> On 02 Feb 2021, Thibaut Verron wrote:
>>2021-02-02 17:50 UTC+01:00, Karl Fogel <kfogel@red-bean.com>:
>>> On 02 Feb 2021, Ergus wrote:
>>> Magit should instead suggest `C-c g' as an entry point for
>>> `magit-status', though a user can bind it however they want of
>>> course.  I doubt there are any Magit users who would be daunted
>>> by the need to set up a keybinding for Magit's entry point.
>> To be clear, Magit itself does not bind anything by default. It
>>suggests "C-x g" as a binding, and I see now that it also offers
>>an option to enable that binding for the user.
>
> Actually, Magit does bind `C-x g' by default.
>
> There is a defcustom, `magit-define-global-key-bindings', and it
> defaults to `t' in magit.el since October 2020 -- see [1] for the
> history of that decision.  When that variable is true, then that
> keybinding (and two others) are made automatically by Magit at
> load time.

My bad, sorry.

>
>>It is not the only high-level package using "C-x letter" as an
>>entry point, another example coming to mind is projectile ("C-x
>>p").   As for the conventions, as far as I can tell, they
>>explicitly require to steer clear of "C-c letter", but they don't
>>have anything about "C-x letter":
>>https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html
>>
>
> Uh, I mean... sure, okay, those guidelines don't say anything
> explicit about not binding `C-x LETTER' in your 3rd-party package,
> but does that kind of guidance really have to be made explicit?
> This is Emacs: everyone who develops for Emacs knows that the
> `C-x' map is crowded and used heavily by Emacs. If everyone's
> packages started binding things under there, they'd simply collide
> with *each other* all the time, as well as (eventually) with Emacs
> when Emacs decides to add a new `C-x' binding, as happened here.

If a key space is reserved *for future usage*, that's most definitely
something I would expect to see mentioned in the key binding
conventions.
I mean, isn't the point of having written conventions precisely to
avoid relying on "everyone knows that"?

My understanding until today was that C-x is indeed crowded, but that
the few remaining keys are free.

> I mean, the guidelines don't say to avoid rebinding the letter `a'
> either, but people know not to do that :-).

Because 'a' is already bound. In modes where self-insert-command makes
no sense, a can  be bound. And some modes also sensibly rebind some
keys away from self-insert-command (typically for delimiters
insertion). Some packages also rebind C-<, C-a or mouse-click.

And let's not get started about evil...

> Magit should explicitly advise users to use `C-c LETTER' for
> Magit's entry points.  The user-reserved space is there under `C-c
> LETTER' precisely so users can bind entry points to their favorite
> functionality.
>
> In other words, while Magit itself should "steer clear" of binding
> things under either `C-x' or `C-c LETTER', Magit is perfectly free
> to make recommendations.  Right now, Magit's three main entry
> points are:
>
>   C-x g     `magit-status' C-x M-g   `magit-dispatch' C-c M-g
>   `magit-file-dispatch'
>
> And the doc string for `magit-define-global-key-bindings' even
> says the following:
>
>   > We recommend that you bind "C-c g" instead of "C-c M-g" to
>   > `magit-file-dispatch'.  The former is a much better binding
>   > but the "C-c <letter>" namespace is strictly reserved for
>   > users; preventing Magit from using it by default.
>
> Now, clearly Magit's developers knew about the convention and
> decided to clobber the Emacs-reserved space anyway.  I totally
> understand why they did so, even though I disagree with the
> decision.

Or they also took the guidelines and the convention at face value,
acknowledging the status of C-c letter, but not mentioning anything
about any emacs-reserved space. :)

Re: Concern about new binding.

[Basil L. Contovounesios]

Thibaut Verron <thibaut.verron@gmail.com> writes:

> To be clear, Magit itself does not bind anything by default. It
> suggests "C-x g" as a binding, and I see now that it also offers an
> option to enable that binding for the user.

Which is turned on by default.

-- 
Basil

Re: Concern about new binding.

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

  > As for the conventions, as far as I can tell, they explicitly require
  > to steer clear of "C-c letter", but they don't have anything about
  > "C-x letter":
  > https://www.gnu.org/software/emacs/manual/html_node/elisp/Key-Binding-Conventions.html

That's true.  It isn't necessarily bad for a package to bind C-xLETTER.

However, binding any of the remaining C-x LETTER keys is a digificant
change,  A package which binds one should be prepared to see that
key get an important global binding, which would not quite compel
a change in the package, but almost.

-- 
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: Concern about new binding.

[Gregory Heytings]

>
> 1) In general `C-x g` is used by magit; I know this is not a priority 
> (cause magit is an external package), but magit is a very popular 
> package.
>

Emacs is free to use the free C-x LETTER slots.  There were only 5 such 
free slots until a few days ago: c g j w x.

>
> 3) In spite of revert-buffer is a very useful command it is useless in 
> many conditions like when auto-revert-mode is enable... so maybe it 
> makes sense to bind it to something longer (ex: C-x g r)??
>
> There are more commands that could be set in a map inside C-x g IMHO: 
> toggle-read-only
> revert-buffer-with-fine-grain
> something to enable/disable font-lock etc
>

I agree with you that these free slots should probably be used as prefix 
commands.  I also agree with you that revert-buffer is perhaps not useful 
enough to use a single letter C-x slot.  I would suggest something like:

C-x g c = clone-buffer
C-x g d = diff-buffers
C-x g f = fit-frame-to-buffer
C-x g h = hexl-mode
C-x g i = insert-buffer
C-x g l = font-lock-mode
C-x g n = rename-buffer
C-x g r = revert-buffer
C-x g R = revert-buffer-with-fine-grain
C-x g t = toggle-truncate-lines

and so forth.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> I agree with you that these free slots should probably be used as
> prefix commands.

Not by Emacs, please.  Leave them for users and
3rd-party libraries (which would preferably make
them optional in some way).

Emacs should, in 2021, no longer be conquering
key-sequence space.  It should leave the little
bit of space left there to users.

There's a tendency for Emacs to gather more and
more stuff (e.g. Project), and for its developers
to want to add one or more prefix keys for that.

That's forgivable (IMO) for 3rd-party libraries,
but I no longer forgive it for Emacs itself.
Time to tell Emacs to back off, IMO.

> I would suggest something like:
> 
> C-x g c = clone-buffer
> C-x g d = diff-buffers
> C-x g f = fit-frame-to-buffer
> C-x g h = hexl-mode
> C-x g i = insert-buffer
> C-x g l = font-lock-mode
> C-x g n = rename-buffer
> C-x g r = revert-buffer
> C-x g R = revert-buffer-with-fine-grain
> C-x g t = toggle-truncate-lines
> 
> and so forth.

Please, no, absolutely not.

You can do that for your own use.

If zillions of users end up using exactly that
for a considerable time, then emacs-devel can
think about giving prefix key `C-x g' to Emacs
that way.  Till then, no, please.  wAGNI. 

Re: [External] : Re: Concern about new binding.

[Ergus]

>> I would suggest something like:
>>
>> C-x g c = clone-buffer
>> C-x g d = diff-buffers
>> C-x g f = fit-frame-to-buffer
>> C-x g h = hexl-mode
>> C-x g i = insert-buffer
>> C-x g l = font-lock-mode
>> C-x g n = rename-buffer
>> C-x g r = revert-buffer
>> C-x g R = revert-buffer-with-fine-grain
>> C-x g t = toggle-truncate-lines
>>
>> and so forth.
>
>Please, no, absolutely not.
>
>You can do that for your own use.
>
>If zillions of users end up using exactly that
>for a considerable time, then emacs-devel can
>think about giving prefix key `C-x g' to Emacs
>that way.  Till then, no, please.  wAGNI.
>
>
Drew: 

The binding is already taken (that's why I started the thread), so the
discussion will be to take it for something "better" than a single
(maybe superfluous) command.

If we start arguing as usual then the binding will stay and no change
will be done (again as usual).

Best,
Ergus

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> >> I would suggest something like:
> >>
> >> C-x g c = clone-buffer
> >> C-x g d = diff-buffers
> >> C-x g f = fit-frame-to-buffer
> >> C-x g h = hexl-mode
> >> C-x g i = insert-buffer
> >> C-x g l = font-lock-mode
> >> C-x g n = rename-buffer
> >> C-x g r = revert-buffer
> >> C-x g R = revert-buffer-with-fine-grain
> >> C-x g t = toggle-truncate-lines
> >>
> >> and so forth.
> >
> >Please, no, absolutely not.
> >
> >You can do that for your own use.
> >
> >If zillions of users end up using exactly that
> >for a considerable time, then emacs-devel can
> >think about giving prefix key `C-x g' to Emacs
> >that way.  Till then, no, please.  wAGNI.
>
> Drew:
> 
> The binding is already taken (that's why I started the thread), so the
> discussion will be to take it for something "better" than a single
> (maybe superfluous) command.

IMO the decision should be to revert that binding.

It doesn't make sense to take it as given at this
point and only hope that at least other things get
stuffed under it as a prefix key.

> If we start arguing as usual then the binding will stay and no change
> will be done (again as usual).

The question should have been discussed.  And it
should be discussed here now, IMO.  This mistake
shouldn't be considered carved in stone.

Re: Concern about new binding.

[Ergus]

On Tue, Feb 02, 2021 at 10:10:06PM +0000, Gregory Heytings wrote:
>
>I agree with you that these free slots should probably be used as 
>prefix commands.  I also agree with you that revert-buffer is perhaps 
>not useful enough to use a single letter C-x slot.  I would suggest 
>something like:
>
>C-x g c = clone-buffer
>C-x g d = diff-buffers
>C-x g f = fit-frame-to-buffer
>C-x g h = hexl-mode
>C-x g i = insert-buffer
>C-x g l = font-lock-mode
>C-x g n = rename-buffer
>C-x g r = revert-buffer
>C-x g R = revert-buffer-with-fine-grain
>C-x g t = toggle-truncate-lines
>
>and so forth.
>

Hi Gregory:

Here I totally agree with you.

Personally I prefer to keep the `C-x g` free; BUT if it is going to be
taken, then we should use a map and not a single command (specially not
one so unhelpful)

I won't send any other email about this because I tend to spam too
much. 

But Eli, Stefan, Lars... Do you approve this change? At least revert the
binding?

Because if we forget this now, after some time it will require
deprecation and years...

Best,
Ergus

Re: Concern about new binding.

[Eli Zaretskii]

> Date: Wed, 3 Feb 2021 01:56:42 +0100
> From: Ergus <spacibba@aol.com>
> Cc: emacs-devel@gnu.org
> 
> But Eli, Stefan, Lars... Do you approve this change? At least revert the
> binding?

Which change? what binding?

Re: Concern about new binding.

[Ergus]

On Wed, Feb 03, 2021 at 05:28:28AM +0200, Eli Zaretskii wrote:
>> Date: Wed, 3 Feb 2021 01:56:42 +0100
>> From: Ergus <spacibba@aol.com>
>> Cc: emacs-devel@gnu.org
>>
>> But Eli, Stefan, Lars... Do you approve this change? At least revert the
>> binding?
>
>Which change? what binding?
>
Commit: 7d15fa008af774789a91d7242055dc87497df66f

All this thread is because of that.

Re: Concern about new binding.

[Eli Zaretskii]

On February 3, 2021 5:58:24 AM GMT+02:00, Ergus <spacibba@aol.com> wrote:
> On Wed, Feb 03, 2021 at 05:28:28AM +0200, Eli Zaretskii wrote:
> >> Date: Wed, 3 Feb 2021 01:56:42 +0100
> >> From: Ergus <spacibba@aol.com>
> >> Cc: emacs-devel@gnu.org
> >>
> >> But Eli, Stefan, Lars... Do you approve this change? At least
> revert the
> >> binding?
> >
> >Which change? what binding?
> >
> Commit: 7d15fa008af774789a91d7242055dc87497df66f
> 
> All this thread is because of that.

This thread seems to be about a lot of things, including whether it's okay for 3rd party packages to use C-x SOME-LETTER, and even whether the Emacs developers are doing their job well enough.

As for that particular commit: the discussion is still unfolding, and it isn't yet clear to me whether there's consensus or what it is.  Some say that Magit was wrong in using "C-x g" to begin with, others (including yourself?) are okay with having "C-x g" globally bound to revert-buffer if we add to that more global bindings starting with "C-x g".  And most of the points you raised in your OP didn't yet get any responses.

So from my POV it's too early to make up my mind about this.  Lars obviously didn't think the new binding was terribly wrong, or else he wouldn't have committed that change.  And Stefan started a new thread to discuss a related but separate issue.

So I think we should wait and see if some consensus emerges out of this discussion.

Re: Concern about new binding.

[martin rudalics]

 > Emacs is free to use the free C-x LETTER slots.  There were only 5
 > such free slots until a few days ago: c g j w x.

I don't care about any keybindings because I always use my own.  But why
all this fuss with something as handy as M-g practically empty?

martin

Re: Concern about new binding.

[Gregory Heytings]

>> Emacs is free to use the free C-x LETTER slots.  There were only 5 such 
>> free slots until a few days ago: c g j w x.
>
> I don't care about any keybindings because I always use my own.  But why 
> all this fuss with something as handy as M-g practically empty?
>

I think M-g is for "goto" actions.  What we have here are "buffer" 
actions.  IMO it is better to put them on separate keymaps.  The exception 
is C-x r, which is used for registers, rectangles and bookmarks, which is 
IMO confusing.

Re: Concern about new binding.

[martin rudalics]

 > I think M-g is for "goto" actions.

Then let's change the semantics of "g".

 > What we have here are "buffer"
 > actions.  IMO it is better to put them on separate keymaps.  The
 > exception is C-x r, which is used for registers, rectangles and
 > bookmarks, which is IMO confusing.

Isn't it a bit ridiculous to desperately search for free keybindings for
one given prefix while another prefix offers them for free?

martin

Re: Concern about new binding.

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

  > Isn't it a bit ridiculous to desperately search for free keybindings for
  > one given prefix while another prefix offers them for free?

Systematic use of a prefix for a certain purpose makes it easier
to remember.  That is very important for a system as complex as Emacs.

-- 
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: Concern about new binding.

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

  > In a recent commit I see that the C-x g binding was taken for
  > revert-buffer.

I see another disadvantage in that binding: revert-buffer is a drastic
operation, so we should not make it easier.  I think it is wiser
not to put it on a key -- which is why I never did.

-- 
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: Concern about new binding.

[Gregory Heytings]

>> In a recent commit I see that the C-x g binding was taken for 
>> revert-buffer.
>
> I see another disadvantage in that binding: revert-buffer is a drastic 
> operation, so we should not make it easier.  I think it is wiser not to 
> put it on a key -- which is why I never did.
>

It's true that it is a drastic operation, but it asks for confirmation, 
and it can be undone.  An additional security measure would be to disable 
it by default: (put 'revert-buffer 'disabled t).

Re: Concern about new binding.

[Robert Pluim]

>>>>> On Wed, 03 Feb 2021 09:37:07 +0000, Gregory Heytings <gregory@heytings.org> said:

    >>> In a recent commit I see that the C-x g binding was taken for
    >>> revert-buffer.
    >> 
    >> I see another disadvantage in that binding: revert-buffer is a
    >> drastic operation, so we should not make it easier.  I think it is
    >> wiser not to put it on a key -- which is why I never did.
    >> 

    Gregory> It's true that it is a drastic operation, but it asks for
    Gregory> confirmation, and it can be undone.  An additional security measure
    Gregory> would be to disable it by default: (put 'revert-buffer 'disabled t).

Please no, itʼs a useful operation in some situations, making it more
confusing for people to use is not a good idea.

Compromise binding: "C-x G", which doesnʼt clash with magit, and is
relatively hard to type by accident.

Robert

Re: Concern about new binding.

[Alfred M. Szmidt]

Why not C-x M-u for revert-buffer?  Hard to type, follows the pattern
of "undo" which revert-buffer basically is, is free, similar to the
normal pattern of Emacs bindings where M- works on something larger
than something without.

Re: Concern about new binding.

[Andreas Schwab]

On Feb 03 2021, Alfred M. Szmidt wrote:

> Why not C-x M-u for revert-buffer?

Why not M-x revert-buffer for revert-buffer?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Concern about new binding.

[Alfred M. Szmidt]

   > Why not C-x M-u for revert-buffer?

   Why not M-x revert-buffer for revert-buffer?

Why not M-x undo for undo? Why not M-x find-file for find file?  Why
not remove all keybindings and let users typ in sexps all the time?
Why not use flip switches for proramming instead of having a keyboard?

Because people want to use it, and people want to make things nicer.

Re: Concern about new binding.

[Andreas Schwab]

On Feb 03 2021, Alfred M. Szmidt wrote:

> Because people want to use it, and people want to make things nicer.

You want a hard to type binding for revert-buffer, you already have
that.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Concern about new binding.

[Alfred M. Szmidt]

   > Because people want to use it, and people want to make things nicer.

   You want a hard to type binding for revert-buffer, you already have
   that.

It is not I who wanted it.

Re: Concern about new binding.

[Thibaut Verron]

2021-02-03 13:51 UTC+01:00, Alfred M. Szmidt <ams@gnu.org>:
>    > Because people want to use it, and people want to make things nicer.
>
>    You want a hard to type binding for revert-buffer, you already have
>    that.
>
> It is not I who wanted it.

What is still unclear to me is why a *global* binding for
revert-buffer is useful.

In text-editing buffers, we have M-x revert-buffer. We have the
various auto-revert modes for when the file changes outside of the
editor. And we have an entry in the "Files" menu.
What scenario do they not cover?

In special buffers, manually triggering a revert can be useful, but
those buffers typically have a lot more keys to choose from. Not only
that, they even already have a binding for revert-buffer ('g', in
special-mode-map).

If a mode has a more useful binding on 'g', they can either set
revert-buffer-function or use another key for revert-buffer (or both).

What problem does a global binding solve?

Re: Concern about new binding.

[Eli Zaretskii]

> From: Thibaut Verron <thibaut.verron@gmail.com>
> Date: Wed, 3 Feb 2021 14:15:48 +0100
> Cc: rpluim@gmail.com, Andreas Schwab <schwab@linux-m68k.org>,
>  gregory@heytings.org, rms@gnu.org, emacs-devel@gnu.org
> 
> What is still unclear to me is why a *global* binding for
> revert-buffer is useful.

So that users could remember only a single key sequence, and it would
do the job regardless of the current major mode.

Re: Concern about new binding.

[Dmitry Gutov]

On 03.02.2021 17:00, Eli Zaretskii wrote:
> So that users could remember only a single key sequence, and it would
> do the job regardless of the current major mode.

Up until now, we've had a single key sequence for "special" revert commands.

And that key sequence was 'g'.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > So that users could remember only a single key sequence, and it would
> > do the job regardless of the current major mode.
> 
> Up until now, we've had a single key sequence for "special" revert
> commands.
> 
> And that key sequence was 'g'.

Yes, we've decided that a key for `revert-buffer'
makes sense for this or that mode.  And yes, when
possible we've used the same key for that, `g'.

All of that is normal.  Reverting a buffer is
about, well, the buffer.  And in particular it's
related to the mode, a priori.

Re: [External] : Re: Concern about new binding.

[Yuan Fu]

I just want to addd that considering the amount of work and discussion involved in removing or changing default key bindings, we shouldn’t go too lightly on adding them.

Yuan

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Yuan Fu <casouri@gmail.com>
> Date: Wed, 3 Feb 2021 12:12:46 -0500
> Cc: Dmitry Gutov <dgutov@yandex.ru>,
>  Eli Zaretskii <eliz@gnu.org>,
>  "thibaut.verron@gmail.com" <thibaut.verron@gmail.com>,
>  "rms@gnu.org" <rms@gnu.org>,
>  "rpluim@gmail.com" <rpluim@gmail.com>,
>  "gregory@heytings.org" <gregory@heytings.org>,
>  "emacs-devel@gnu.org" <emacs-devel@gnu.org>,
>  "ams@gnu.org" <ams@gnu.org>,
>  "schwab@linux-m68k.org" <schwab@linux-m68k.org>
> 
> I just want to addd that considering the amount of work and discussion involved in removing or changing default key bindings, we shouldn’t go too lightly on adding them.

I don't see any evidence that we are adding new key bindings too
lightly.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > What is still unclear to me is why a *global* binding for
> > revert-buffer is useful.
> 
> So that users could remember only a single key sequence, and it would
> do the job regardless of the current major mode.

That's the reason for _any_ global key.

But what's the reason for a global key
for `revert-buffer'?

Why does Emacs need to sacrifice a key
for this by default?

What happened to seeing what users
actually do?

If zillions of users bind a global key
for `revert-buffer' - and especially if
they're all wanting the same key - then
we have a good case to consider.  But
we don't have that, do we?

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Drew Adams <drew.adams@oracle.com>
> CC: "rms@gnu.org" <rms@gnu.org>, "rpluim@gmail.com" <rpluim@gmail.com>,
>         "gregory@heytings.org" <gregory@heytings.org>,
>         "emacs-devel@gnu.org"
> 	<emacs-devel@gnu.org>,
>         "ams@gnu.org" <ams@gnu.org>,
>         "schwab@linux-m68k.org"
> 	<schwab@linux-m68k.org>
> Date: Wed, 3 Feb 2021 16:27:23 +0000
> 
> > > What is still unclear to me is why a *global* binding for
> > > revert-buffer is useful.
> > 
> > So that users could remember only a single key sequence, and it would
> > do the job regardless of the current major mode.
> 
> That's the reason for _any_ global key.
> 
> But what's the reason for a global key
> for `revert-buffer'?

That many modes have some kind of "revert" action.

Re: [External] : Re: Concern about new binding.

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

  > > But what's the reason for a global key
  > > for `revert-buffer'?

  > That many modes have some kind of "revert" action.

Aren't they special modes?  I think they already have a standard key
for that: g.

-- 
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: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: drew.adams@oracle.com, thibaut.verron@gmail.com, rpluim@gmail.com,
> 	gregory@heytings.org, emacs-devel@gnu.org, ams@gnu.org,
> 	schwab@linux-m68k.org
> Date: Thu, 04 Feb 2021 00:46:14 -0500
> 
>   > > But what's the reason for a global key
>   > > for `revert-buffer'?
> 
>   > That many modes have some kind of "revert" action.
> 
> Aren't they special modes?  I think they already have a standard key
> for that: g.

Some of them are special modes, but some aren't.

Re: [External] : Re: Concern about new binding.

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

  > > 
  > >   > That many modes have some kind of "revert" action.
  > > 
  > > Aren't they special modes?  I think they already have a standard key
  > > for that: g.

  > Some of them are special modes, but some aren't.

That makes me curious; I'd like to understand how come.  Can someone
post about modes that have their own revert actions but are not
special modes?

-- 
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: [External] : Re: Concern about new binding.

[Sean Whitton]

Hello,

On Fri 05 Feb 2021 at 12:50AM -05, Richard Stallman wrote:

> [[[ 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. ]]]
>
>   > >
>   > >   > That many modes have some kind of "revert" action.
>   > >
>   > > Aren't they special modes?  I think they already have a standard key
>   > > for that: g.
>
>   > Some of them are special modes, but some aren't.
>
> That makes me curious; I'd like to understand how come.  Can someone
> post about modes that have their own revert actions but are not
> special modes?

*Shell Command Output* from M-! and *Async Command Output* from M-& now
have this on master.

-- 
Sean Whitton

Re: [External] : Re: Concern about new binding.

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Cc: drew.adams@oracle.com, thibaut.verron@gmail.com, rpluim@gmail.com,
> 	gregory@heytings.org, emacs-devel@gnu.org, ams@gnu.org,
> 	schwab@linux-m68k.org
> Date: Fri, 05 Feb 2021 00:50:43 -0500
> 
>   > >   > That many modes have some kind of "revert" action.
>   > > 
>   > > Aren't they special modes?  I think they already have a standard key
>   > > for that: g.
> 
>   > Some of them are special modes, but some aren't.
> 
> That makes me curious; I'd like to understand how come.  Can someone
> post about modes that have their own revert actions but are not
> special modes?

Searching Emacs for files that set revert-buffer-function brings up
the following list:

  apropos.el
  bookmark.el
  bs.el
  calendar/todo-mode.el
  chistory.el
  cus-theme.el
  dired.el
  emacs-backtrace.el
  emacs-ert.el
  emacs-package.el
  emacs-tabulated-list.el
  emacs-timer-list.el
  epa.el
  facemenu.el
  find-dired.el
  find-lisp.el
  forms.el
  help-mode.el
  hexl.el
  ibuffer.el
  info.el
  locate.el
  mail/mspools.el
  mail/rmail.el
  mail/rmailsum.el
  mh-e/mh-folder.el
  net/net-utils.el
  net/secrets.el
  net/telnet.el
  proced.el
  progmodes/compile.el
  progmodes/ebrowse.el
  progmodes/sql.el
  replace.el
  simple.el
  tar-mode.el
  time.el
  vc/diff.el
  vc/pcvs.el
  vc/vc-dir.el
  vc/vc.el
  wdired.el

I think this gives a good idea about what modes have revert actions,
but if details are needed, one can look inside these files and see.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> What problem does a global binding solve?

Exactly the question that should have been,
and should be, the starting point.
___

(And how on earth has Emacs survived 35+
years without such a global key?)

Re: Concern about new binding.

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

  > In text-editing buffers, we have M-x revert-buffer. We have the
  > various auto-revert modes for when the file changes outside of the
  > editor. And we have an entry in the "Files" menu.
  > What scenario do they not cover?

  > In special buffers, manually triggering a revert can be useful, but
  > those buffers typically have a lot more keys to choose from. Not only
  > that, they even already have a binding for revert-buffer ('g', in
  > special-mode-map).

1+

-- 
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: Concern about new binding.

[Andreas Schwab]

On Feb 03 2021, Alfred M. Szmidt wrote:

>    > Because people want to use it, and people want to make things nicer.
>
>    You want a hard to type binding for revert-buffer, you already have
>    that.
>
> It is not I who wanted it.

Yes, you did:

> Why not C-x M-u for revert-buffer?  Hard to type, follows the pattern

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Concern about new binding.

[Alfred M. Szmidt]

   > It is not I who wanted it.

   Yes, you did:

I suggested a possible solution to the person I was replying to, who
in turn was replying to Gregory who thought 'C-x g' was to easy to
type.

So, no, _I_ didn't.  And I'd appreicate it if you stopped pretending
you know anything about what I want -- specially when I explcitly said
the opposite.

Re: Concern about new binding.

[Andreas Schwab]

It was a literal quote.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Concern about new binding.

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

Would everyone please be kinder to those who don't agree?

-- 
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: [External] : Re: Concern about new binding.

[Drew Adams]

>> Because people want to use it, and people want to make things nicer.
> 
>    You want a hard to type binding for revert-buffer, you already have
>    that.
> 
> It is not I who wanted it.

Every user can already have whatever behavior they want:

1. No global key
2. This or that global key for `revert-buffer'
3. This or that global key for `revert-buffer'
   without needing to confirm

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> Because people want to use it, and people want to make things nicer.

"People" are free to do that.  The question
is whether Emacs should sacrifice a key for
this _by default_.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> > Why not C-x M-u for revert-buffer?
> 
> Why not M-x revert-buffer for revert-buffer?

+1.

Absolutely.

And anyone can bind a global key if they like.
__

Personally, I do that.  I bind `f5' to this:

 (defun revert-buffer-no-confirm ()
   "Revert buffer without confirmation."
   (interactive) (revert-buffer t t))

And I use `f5' because that's the key for this
global behavior on MS Windows.

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> Why not C-x M-u for revert-buffer?  Hard to type, follows the pattern
> of "undo" which revert-buffer basically is, is free, similar to the
> normal pattern of Emacs bindings where M- works on something larger
> than something without.

What are the reasons why we need Emacs to have
_any_ default binding for `revert-buffer'?

That should be the starting point.

Re: Concern about new binding.

[Juri Linkov]

> Why not C-x M-u for revert-buffer?  Hard to type, follows the pattern
> of "undo" which revert-buffer basically is, is free, similar to the
> normal pattern of Emacs bindings where M- works on something larger
> than something without.

Then C-x M-g would be better, since 'g' will retain its connection
with the key 'g' bound in special modes.

Re: Concern about new binding.

[Basil L. Contovounesios]

Robert Pluim <rpluim@gmail.com> writes:

> Compromise binding: "C-x G", which doesnʼt clash with magit, and is
> relatively hard to type by accident.

+1

-- 
Basil

Re: Concern about new binding.

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

  > > Compromise binding: "C-x G", which doesnʼt clash with magit, and is
  > > relatively hard to type by accident.

Letters following C-x are not case-sensitive.  That is a systematic rule.

Thai rule is not sacred; for a good enough reason,
we could break it.  But this is not an important reason; it is
not sufficient reason to break a rule.

-- 
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: Concern about new binding.

[Robert Pluim]

>>>>> On Thu, 04 Feb 2021 00:39:11 -0500, Richard Stallman <rms@gnu.org> said:

    Richard> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
    Richard> [[[ whether defending the US Constitution against all enemies,     ]]]
    Richard> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]

    >> > Compromise binding: "C-x G", which doesnʼt clash with magit, and is
    >> > relatively hard to type by accident.

    Richard> Letters following C-x are not case-sensitive.  That is a systematic rule.

Thatʼs a new one for me, I thought it was just C-<key>, since you
canʼt distinguish case for those on a tty.

    Richard> Thai rule is not sacred; for a good enough reason,
    Richard> we could break it.  But this is not an important reason; it is
    Richard> not sufficient reason to break a rule.

OK. Maybe we can find an acceptable binding. Personally I use s-u, but
thatʼs not a good candidate as a default binding.

Robert

RE: [External] : Re: Concern about new binding.

[Drew Adams]

> Compromise binding: "C-x G", which doesnʼt clash with magit, and is
> relatively hard to type by accident.

It's not a compromise with my position, at
least.  IMO we should not add any binding
for this.

And I presented several reasons:

https://lists.gnu.org/archive/html/emacs-devel/2021-02/msg00048.html

Re: Concern about new binding.

[Stefan Kangas]

Gregory Heytings <gregory@heytings.org> writes:

>>> In a recent commit I see that the C-x g binding was taken for
>>> revert-buffer.
>>
>> I see another disadvantage in that binding: revert-buffer is a drastic
>> operation, so we should not make it easier.  I think it is wiser not to
>> put it on a key -- which is why I never did.
>>

FWIW, I think this is the correct idea here.

In particular, I think `C-x g' is an unfortunate keybinding, as it is
too easy to make a drastic mistake.  If we need to have a keybinding, I
like the idea of something like `C-x M-u' more.

> It's true that it is a drastic operation, but it asks for confirmation,
> and it can be undone.

AFAIK, that depends on the size of your changes and the value of
`undo-limit', `undo-strong-limit' and `undo-outer-limit'.

> An additional security measure would be to disable it by default: (put
> 'revert-buffer 'disabled t).

I think making it easy to type only to make it harder to use would be
both contradictory and self-defeating.

Re: Concern about new binding.

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

  > > I see another disadvantage in that binding: revert-buffer is a drastic 
  > > operation, so we should not make it easier.  I think it is wiser not to 
  > > put it on a key -- which is why I never did.
  > >

  > It's true that it is a drastic operation, but it asks for confirmation, 
  > and it can be undone.  An additional security measure would be to disable 
  > it by default: (put 'revert-buffer 'disabled t).

Typing 8 characters to invoke the command is not a big burden.
I think it is a reasonable length for a command like this.
How many times per day do you do revert-buffer in a file-visiting buffer?


-- 
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: Concern about new binding.

[Sean Whitton]

Hello,

> I see another disadvantage in that binding: revert-buffer is a drastic
> operation, so we should not make it easier.  I think it is wiser
> not to put it on a key -- which is why I never did.

You can easily undo it, however, with a quick C-/.

-- 
Sean Whitton

Re: Concern about new binding.

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

  > You can easily undo it, however, with a quick C-/.

I think that is limited to files under a certain size.

-- 
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: Concern about new binding.

[Gregory Heytings]

>> You can easily undo it, however, with a quick C-/.
>
> I think that is limited to files under a certain size.
>

Yes, that limit is 'undo-outer-limit', set to 22 MB by default.

Unfortunately, when you execute 'revert-buffer' on such a large buffer, 
you get a warning _after_ the reversion has happened that you cannot undo 
it anymore: "Warning (undo): Buffer '...' undo info was ... bytes long. 
The undo info was discarded because it exceeded `undo-outer-limit'."

It would perhaps make sense to ask for confirmation _before_ executing the 
command ("The command '...' will discard undo info, really do it? (yes or 
no)").

Re: Concern about new binding.

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> It would perhaps make sense to ask for confirmation _before_ executing
> the command ("The command '...' will discard undo info, really do it?
> (yes or no)").

Makes sense to me.

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

Re: Concern about new binding.

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Gregory Heytings <gregory@heytings.org> writes:
>
>> It would perhaps make sense to ask for confirmation _before_ executing
>> the command ("The command '...' will discard undo info, really do it?
>> (yes or no)").
>
> Makes sense to me.

Or...  if it could offer to to keep the undo info, even if it's over the
current general limit, that would be even nicer, perhaps?

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

Re: Concern about new binding.

[Gregory Heytings]

>>> It would perhaps make sense to ask for confirmation _before_ executing 
>>> the command ("The command '...' will discard undo info, really do it? 
>>> (yes or no)").
>>
>> Makes sense to me.
>
> Or...  if it could offer to to keep the undo info, even if it's over the 
> current general limit, that would be even nicer, perhaps?
>

I don't have strong feelings about this.  Perhaps offering to keep the 
undo info after the command has been executed would be nicer indeed.  But 
not executing the command before a confirmation is perhaps less risky. 
It seems to me that if you see such a question before the command is 
executed, the question will have all your attention, because what you 
wanted did not happen yet.  If you see it after the command is executed, 
the risk of answering "no" without really thinking about it is higher.

On a side note, I don't understand the "At garbage collection time" in the 
doc string of "undo-outer-limit":

Outer limit on size of undo information for one command.
At garbage collection time, if the current command has produced more than 
this much undo information, it discards the info and displays a warning. 
This is a last-ditch limit to prevent memory overflow.

It seems to me that this happens when the command is executed, not "at 
garbage collection time".

Re: Concern about new binding.

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

>> Or...  if it could offer to to keep the undo info, even if it's over
>> the current general limit, that would be even nicer, perhaps?
>
> I don't have strong feelings about this.  Perhaps offering to keep the
> undo info after the command has been executed would be nicer indeed.
> But not executing the command before a confirmation is perhaps less
> risky.

I was thinking about asking before doing anything, if that's practically
possible, but I haven't looked at the code.

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

Re: Concern about new binding.

[Gregory Heytings]

>>> Or...  if it could offer to to keep the undo info, even if it's over 
>>> the current general limit, that would be even nicer, perhaps?
>>
>> I don't have strong feelings about this.  Perhaps offering to keep the 
>> undo info after the command has been executed would be nicer indeed. 
>> But not executing the command before a confirmation is perhaps less 
>> risky.
>
> I was thinking about asking before doing anything, if that's practically 
> possible, but I haven't looked at the code.
>

I misunderstood what you said indeed.  I think asking before doing 
anything would be okay, but I guess in that case it would be necessary to 
introduce an "undo-outer-outer-limit" at, say, 250 MB, above which it 
would not be possible to keep the undo info.

Re: Concern about new binding.

[Lars Ingebrigtsen]

Gregory Heytings <gregory@heytings.org> writes:

> I misunderstood what you said indeed.  I think asking before doing
> anything would be okay, but I guess in that case it would be necessary
> to introduce an "undo-outer-outer-limit" at, say, 250 MB, above which
> it would not be possible to keep the undo info.

Ideally, we could ask "this action will take <foo> MB; really do it?",
and we won't need any new variable.

But like I said, I don't know how feasible this is to ask before the
doing the action.

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

Re: Concern about new binding.

[Gregory Heytings]

>> I misunderstood what you said indeed.  I think asking before doing 
>> anything would be okay, but I guess in that case it would be necessary 
>> to introduce an "undo-outer-outer-limit" at, say, 250 MB, above which 
>> it would not be possible to keep the undo info.
>
> Ideally, we could ask "this action will take <foo> MB; really do it?", 
> and we won't need any new variable.
>
> But like I said, I don't know how feasible this is to ask before the 
> doing the action.
>

In fact that option already exists (almost): undo-ask-before-discard.  It 
would make sense to set its default value to t instead of nil.  I said 
"almost" because it asks after executing the command, not before.  But at 
least it asks...

Re: Concern about new binding.

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 04 Feb 2021 11:10:20 +0100
> Cc: Richard Stallman <rms@gnu.org>, emacs-devel@gnu.org
> 
> I was thinking about asking before doing anything, if that's practically
> possible, but I haven't looked at the code.

I don't think it's possible, since the messages comes from a function
called by GC.  At least this isn't an easy local change.

Re: Concern about new binding.

[Eli Zaretskii]

On February 4, 2021 11:49:15 AM GMT+02:00, Gregory Heytings <gregory@heytings.org> wrote:
> 
> On a side note, I don't understand the "At garbage collection time" in
> the 
> doc string of "undo-outer-limit":
> 
> Outer limit on size of undo information for one command.
> At garbage collection time, if the current command has produced more
> than 
> this much undo information, it discards the info and displays a
> warning. 
> This is a last-ditch limit to prevent memory overflow.
> 
> It seems to me that this happens when the command is executed, not "at
> 
> garbage collection time".

That discarding of the undo info happens in a function that compacts buffers and truncates their undo lists.  That function is called from GC.  If you see the message when the command is executed, it simply means that GC is called immediately after the command or even while the command still runs.

Re: Concern about new binding.

[Gregory Heytings]

>> On a side note, I don't understand the "At garbage collection time" in 
>> the doc string of "undo-outer-limit":
>>
>> Outer limit on size of undo information for one command. At garbage 
>> collection time, if the current command has produced more than this 
>> much undo information, it discards the info and displays a warning. 
>> This is a last-ditch limit to prevent memory overflow.
>>
>> It seems to me that this happens when the command is executed, not "at 
>> garbage collection time".
>
> That discarding of the undo info happens in a function that compacts 
> buffers and truncates their undo lists.  That function is called from 
> GC.  If you see the message when the command is executed, it simply 
> means that GC is called immediately after the command or even while the 
> command still runs.
>

You are correct.  But with the default Emacs values, "gc-cons-threshold" 
is 800000 and "undo-outer-limit" is 24000000, GC will happen immediately.