Skip to main content
added 401 characters in body
Source Link
Mark Karpov
  • 5k
  • 1
  • 27
  • 55

I have slightly different doc-string, it's called DEF there:

(define-key KEYMAP KEY DEF)

And then it's explained:

DEF is anything that can be a key's definition:

  • nil (means key is undefined in this keymap),
  • a command (a Lisp function suitable for interactive calling),
  • a string (treated as a keyboard macro),
  • a keymap (to define a prefix key),
  • a symbol (when the key is looked up, the symbol will stand for its function definition, which should at that time be one of the above, or another symbol whose function definition is used, etc.),
  • a cons (STRING . DEFN), meaning that DEFN is the definition (DEFN should be a valid definition in its own right),
  • or a cons (MAP . CHAR), meaning use definition of CHAR in keymap MAP,
  • or an extended menu item definition.

Lisp is granddaddy of dynamic languages like Python, where variables don't have type, they just "point" to some object that can be everything. So it's sorttypically functions can interpret different types of conventionarguments differently and many functions take everything that "makes sense" as arguments. (So, functions frequently test type of arguments, this is different in Python, where such testing is not idiomatic, because Python thinks in terms of "interfaces", not types.)

In Emacs Lisp, you have two types of functions, simple functions and commands. Commands must have interactive declaration. This tells Emacs how to chooseget values of arguments when command is called interactively (by user). So it perfectly makes sense that your keybinding should be associated with command, not just a function.

I have slightly different doc-string, it's called DEF there:

(define-key KEYMAP KEY DEF)

And then it's explained:

DEF is anything that can be a key's definition:

  • nil (means key is undefined in this keymap),
  • a command (a Lisp function suitable for interactive calling),
  • a string (treated as a keyboard macro),
  • a keymap (to define a prefix key),
  • a symbol (when the key is looked up, the symbol will stand for its function definition, which should at that time be one of the above, or another symbol whose function definition is used, etc.),
  • a cons (STRING . DEFN), meaning that DEFN is the definition (DEFN should be a valid definition in its own right),
  • or a cons (MAP . CHAR), meaning use definition of CHAR in keymap MAP,
  • or an extended menu item definition.

Lisp is granddaddy of dynamic languages like Python, where variables don't have type, they just "point" to some object that can be everything. So it's sort of convention.

In Emacs Lisp, you have two types of functions, simple functions and commands. Commands must have interactive declaration. This tells Emacs how to choose arguments when command is called interactively (by user).

I have slightly different doc-string, it's called DEF there:

(define-key KEYMAP KEY DEF)

And then it's explained:

DEF is anything that can be a key's definition:

  • nil (means key is undefined in this keymap),
  • a command (a Lisp function suitable for interactive calling),
  • a string (treated as a keyboard macro),
  • a keymap (to define a prefix key),
  • a symbol (when the key is looked up, the symbol will stand for its function definition, which should at that time be one of the above, or another symbol whose function definition is used, etc.),
  • a cons (STRING . DEFN), meaning that DEFN is the definition (DEFN should be a valid definition in its own right),
  • or a cons (MAP . CHAR), meaning use definition of CHAR in keymap MAP,
  • or an extended menu item definition.

Lisp is granddaddy of dynamic languages like Python, where variables don't have type, they just "point" to some object that can be everything. So typically functions can interpret different types of arguments differently and many functions take everything that "makes sense" as arguments. (So, functions frequently test type of arguments, this is different in Python, where such testing is not idiomatic, because Python thinks in terms of "interfaces", not types.)

In Emacs Lisp, you have two types of functions, simple functions and commands. Commands must have interactive declaration. This tells Emacs how to get values of arguments when command is called interactively (by user). So it perfectly makes sense that your keybinding should be associated with command, not just a function.

Source Link
Mark Karpov
  • 5k
  • 1
  • 27
  • 55

I have slightly different doc-string, it's called DEF there:

(define-key KEYMAP KEY DEF)

And then it's explained:

DEF is anything that can be a key's definition:

  • nil (means key is undefined in this keymap),
  • a command (a Lisp function suitable for interactive calling),
  • a string (treated as a keyboard macro),
  • a keymap (to define a prefix key),
  • a symbol (when the key is looked up, the symbol will stand for its function definition, which should at that time be one of the above, or another symbol whose function definition is used, etc.),
  • a cons (STRING . DEFN), meaning that DEFN is the definition (DEFN should be a valid definition in its own right),
  • or a cons (MAP . CHAR), meaning use definition of CHAR in keymap MAP,
  • or an extended menu item definition.

Lisp is granddaddy of dynamic languages like Python, where variables don't have type, they just "point" to some object that can be everything. So it's sort of convention.

In Emacs Lisp, you have two types of functions, simple functions and commands. Commands must have interactive declaration. This tells Emacs how to choose arguments when command is called interactively (by user).