1

I am writing some extension features for various major modes. The features are (as usual in Emacs) some functions that should be bound to some keys to simplify the workflow of the user.

I started out by assigning these functions to function-keys F1, F2, F3, and so on.. But realized later that if these extensions should be used by others than myself, it would not be a very good idea. According to Appendix D.2 Key Binding Conventions in the Emacs Lisp manual, the function-keys should not be touched; they should be free for the user to customize.

So which keybindings should be assigned for extension features for a major mode? Are there any guidelines for this? Consider for example cperl-mode or LaTeX-mode, they define most keys on the mode-specific-map i.e. the C-c prefix key. Is it a good idea to use the same keymap, or is this also going to breakdown sometimes in the future when the author of the major mode changes the bindings or adds new bindings to this map? I guess there could also very well be a chance that this keymap (mode-specific-map) would at some point get exhausted for reasonable/sensible key combinations.. Should I instead use another prefix key? And then, which is safe/good to use? What is common practice?

1
  • 1
    Contributors to the AUCTeX library frequent the forum located at tex.stackexchange.com/questions/tagged/emacs ; however, I've seen at least a couple of AUCTeX fans on this beta forum as well. In terms of doing the AUCTeX thing, I'd ask the mavens what key conventions they prefer. I generally stick to whatever the major mode already has set up and I just add or modify the key bindings as needed. I also set up a global mode map to do certain things like open the buffer to a specific preassigned directory in lets say dired-mode ctl-d-map, or my tree-view mode ctl-z-map.
    – lawlist
    Jan 19, 2015 at 8:09

2 Answers 2

1

I'm by no means an authoritative source, just listing my opinion. If your code relates to a major-mode, you should either:

  • submit a patch to that mode, so that it gets integrated naturally
  • put your bindings in a minor-mode that can get activated/deactivated at will by the user

Otherwise, you'll be breaking an important rule:

A simple (require 'foo) should not change the behavior of the editor

The actual change should come not just from a require but from enabling a major or minor mode.

1
  • Thanks for the input @abo-abo. These extension I am talking about will not be applicable, in general, to the major mode. Let's say I make a framework for doing certain things and put it on GitHub. For those using the framework, the extensions to cperl-mode would be of interest, but not for the users of cperl-mode in general.. So I am not considering a patch to the major mode as a good solution. Jan 19, 2015 at 9:30
1

In a comment, you give this example:

Let's say I make a framework for doing certain things and put it on GitHub. For those using the framework, the extensions to cperl-mode would be of interest, but not for the users of cperl-mode in general.

For this situation, an option is to write a derived-mode, that is a major-mode inheriting from another major-mode.

(define-derived-mode your-framework-mode
  cperl-mode
  "Your-framework" ; name for the status line
  "Your-framework Mode"     ; long name
  ;; your settings
)

A buffer with your-framework-mode enabled will have all the features of cperl-mode, with the addition of a keymap named your-framework-mode-map, which you can use for your extra bindings.

Of course, the form really defines a major mode, so you get much more than a keymap: hook, initialization code...

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.