Changing default beancount keybindings for Emacs (issue #333).
117 views
Skip to first unread message
Karl Fogel
Oct 6, 2020, 4:07:19 PM10/6/20
to bean...@googlegroups.com
Hi, everyone. As per https://github.com/beancount/beancount/issues/333, I'd like to propose that we change the default Emacs keybindings in beancount.el.
The change is simply to replace each
Control-c LETTER
with
Control-c Control-LETTER
in `beancount-mode-map'.
Justification: the current bindings violate the Emacs keybinding guidelines. In Emacs, "Control-c LETTER" is reserved for users' custom bindings (many of us depend on that convention being observed) while "Control-c Control-LETTER" is specifically reserved for modes -- like `beancount-mode'. Since by default `beancount-mode-map' is on Control-c and binds many plain letters, it's currently violating those conventions.
Since there *is* a space under Control-c that's explicitly reserved for modes' custom bindings, let's keep `beancount-mode-map' on that key and simply use that designated space (namely, Control-LETTER).
Further details are in the issue.
I'm happy to provied the patch, but first I wanted to ask if anyone objects to this change, or wants to discuss it first.
Best regards,
-Karl
The change is simply to replace each
Control-c LETTER
with
Control-c Control-LETTER
in `beancount-mode-map'.
Justification: the current bindings violate the Emacs keybinding guidelines. In Emacs, "Control-c LETTER" is reserved for users' custom bindings (many of us depend on that convention being observed) while "Control-c Control-LETTER" is specifically reserved for modes -- like `beancount-mode'. Since by default `beancount-mode-map' is on Control-c and binds many plain letters, it's currently violating those conventions.
Since there *is* a space under Control-c that's explicitly reserved for modes' custom bindings, let's keep `beancount-mode-map' on that key and simply use that designated space (namely, Control-LETTER).
Further details are in the issue.
I'm happy to provied the patch, but first I wanted to ask if anyone objects to this change, or wants to discuss it first.
Best regards,
-Karl
Martin Blais
Oct 6, 2020, 10:03:49 PM10/6/20
to Beancount
How about we change the defaults, but provide a function one can call to add the current disallowed ones?
The rationale for this being that by default the mode would be compliant (and I suppose can be more easily packaged places) but those who can't be bothered with the change could quickly restore things to how they were with minimal effort.
--
You received this message because you are subscribed to the Google Groups "Beancount" group.
To unsubscribe from this group and stop receiving emails from it, send an email to beancount+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beancount/87eembf79n.fsf%40red-bean.com.
Daniele Nicolodi
Oct 7, 2020, 4:27:03 AM10/7/20
to bean...@googlegroups.com
On 07/10/2020 04:03, Martin Blais wrote:
> How about we change the defaults, but provide a function one can call to
> add the current disallowed ones?
It seems a good compromise. I'll try to find some time to implement
> How about we change the defaults, but provide a function one can call to
> add the current disallowed ones?
this. I am happy to review patches if someone feels to work on this.
Cheers,
Dan
TRS-80
Oct 26, 2020, 9:54:09 PM10/26/20
to bean...@googlegroups.com
> On 2020-10-06 22:03, Martin Blais wrote:
> How about we change the defaults, but provide a function one can call
> to add the current disallowed ones?
> The rationale for this being that by default the mode would be
> compliant (and I suppose can be more easily packaged places) but those
> who can't be bothered with the change could quickly restore things to
> how they were with minimal effort.
>
Really glad to see Emacs conventions being respected.
> How about we change the defaults, but provide a function one can call
> to add the current disallowed ones?
> The rationale for this being that by default the mode would be
> compliant (and I suppose can be more easily packaged places) but those
> who can't be bothered with the change could quickly restore things to
> how they were with minimal effort.
>
How about just a section of documentation ("if you prefer the old
keybindings...") as Emacs config is simply text, after all. It
could simply be copy-pasted into their init file.
That way has two advantages:
1. Does not pollute the repository with a "one time use"
function.
2. Gives newbies (some of which I expect may never have used
Emacs before) a very good and easy example which they can use
as a basis for their own further customization.
Taking such an approach, I think, is much more in line with "the
Emacs way" of doing things.
Perhaps with an appropriate version bump (not even sure we are
following semantic versioning, as this will be a brand new and
separate repository).
What do you guys think?
Cheers,
TRS-80
Karl Fogel
May 10, 2023, 6:52:42 AM5/10/23
to Beancount
This sounds good to me.
Shall I submit a PR to patch both the keybindings and (as described above) the documentation?
Shall I submit a PR to patch both the keybindings and (as described above) the documentation?
If I hear nothing, I'll eventually assume the answer is "yes", but once there's been a discussion I always prefer to get an explicit nod first if I can.
Best regards,
-Karl
Karl Fogel
May 10, 2023, 6:56:48 PM5/10/23
to Beancount
On Wednesday, May 10, 2023 at 5:52:42 AM UTC-5 Karl Fogel wrote:
This sounds good to me.
Shall I submit a PR to patch both the keybindings and (as described above) the documentation?If I hear nothing, I'll eventually assume the answer is "yes", but once there's been a discussion I always prefer to get an explicit nod first if I can.
Reply all
Reply to author
Forward
0 new messages