My two options are
Define the function before binding
For example:
(defun select-all ()
(interactive)
(mark-whole-buffer))
Then binding it:
(global-set-key (kbd "C-a") 'select-all)
Bind anonymous function
Define and bind in one go:
(global-set-key (kbd "C-a")
(lambda ()
(interactive)
(mark-whole-buffer)))
My Question
If I define and bind in one go, is there any performance implication?
References
emacswiki.org - InteractiveKeybinding seems to inform us that it is acceptable.
There is no performance hit with respect to general use of the binding. There may be a small performance hit with respect to other commands which use that information, such as C-h k, but that is also so small it is unlikely you will even notice it and given you probably don't use C-h k that frequently, the most inefficient component in the equation is the user.
There are two main benefits with defining a funtion and then binding that rather than just doing a lambda
Reuse. Having a named function means you can use it with M-x or potentially use it in other functions or libraries you write.
Documentation. This is an important one. I have often found myself looking at a lambda based key binding and having to work through it to remember exactly what it does. If on the other hand it had been a named function I was binding to, then it would likely have been more obvious. You also get the C-h k stuff and apropos support for a named function.
I therefore tend ot only use the lambda type binding when it is really trivial and obvious what it is doing and use a named funtion for all other times.
Related
I'm trying to write an emacs LISP function to un-indent the region
(rigidly). I can pass prefix arguments to indent-code-rigidly or
indent-rigidly or indent-region and they all work fine, but I don't
want to always have to pass a negative prefix argument to shift things
left.
My current code is as below but it seems to do nothing:
(defun undent ()
"un-indent rigidly."
(interactive)
(list
(setq fline (line-number-at-pos (region-beginning)))
(setq lline (line-number-at-pos (region-end)))
(setq curIndent (current-indentation))
;;(indent-rigidly fline lline (- curIndent 1))
(indent-region fline lline 2)
;;(message "%d %d" curIndent (- curIndent 1))
)
)
I gather that (current-indentation) won't get me the indentation of the first line
of the region, but of the first line following the region (so a second quesiton is
how to get that!). But even when I just use a constant for the column (as shown,
I don't see this function do any change.
Though if I uncomment the (message) call, it displays reasonable numbers.
GNU Emacs 24.3.1, on Ubuntu. And in case it matters, I use
(setq-default indent-tabs-mode nil) and (cua-mode).
I must be missing something obvious... ?
All of what Tim X said is true, but if you just need something that works, or an example to show you what direction to take your own code, I think you're looking for something like this:
(defun unindent-rigidly (start end arg &optional interactive)
"As `indent-rigidly', but reversed."
(interactive "r\np\np")
(indent-rigidly start end (- arg) interactive))
All this does is call indent-rigidly with an appropriately transformed prefix argument. If you call this with a prefix argument n, it will act as if you had called indent-rigidly with the argument -n. If you omit the prefix argument, it will behave as if you called indent-rigidly with the argument -1 (instead of going into indent-rigidly's interactive mode).
There are a number of problems with your function, including some vary
fundamental elisp requirements. Highly recommend reading the Emacs Lisp
Reference Manual (bundled with emacs). If you are new to programming and lisp,
you may also find An Introduction to Emacs Lisp useful (also bundled with
Emacs).
A few things to read about which will probably help
Read the section on the command loop from the elisp reference. In particular,
look at the node which describes how to define a new command and the use of
'interactive', which you will need if you want to bind your function to a key
or call it with M-x.
Read the section on variables from the lisp reference
and understand variable scope (local v global). Look at using 'let' rather
than 'setq' and what the difference is.
Read the section on 'positions' in the elisp reference. In particular, look at
'save-excursion' and 'save-restriction'. Understanding how to define and use
the region is also important.
It isn't clear if your writing this function just as a learning exercise or
not. However, just in case you are doing it because it is something you need to
do rather than just something to learn elisp, be sure to go through the Emacs
manual and index. What you appear to need is a common and fairly well supported
requirement. It can get a little complicated if programming modes are involved
(as opposed to plain text). However, with emacs, if what you need seems like
something which would be a common requirement, you can be fairly confident it is
already there - you just need to find it (which can be a challenge at first).
A common convention is for functions/commands to be defined which act 'in
reverse' when supplied with a negative or universal argument. Any command which
has this ability can also be called as a function in elisp code with the
argument necessary to get that behaviour, so understanding the inter-play
between commands, functions and calling conventions is important.
Very simple question but confuse me for some time:
(setq visible-bell t)
and
(visible-bell t)
both seem work.
But
(desktop-save-mode 1)
works, while
(setq desktop-save-mode 1)
not.
May I ask why is this?
They're different because they're different :)
(setq visible-bell t)
is assigning the value t to a variable named visible-bell.
(visible-bell t)
is calling a function1 named visible-bell (and passing the value t as a parameter).
(Although FYI there is no visible-bell function by default in current versions of Emacs, so it's not obvious to me that this is actually working the way you think? However, assuming for the moment that you do indeed have such a function...)
Emacs Lisp is a 'Lisp-2' meaning it has separate name spaces for variables and functions, and therefore you can -- and commonly do -- have a variable and a function with the same name. Which one is being referred to is always implicit in the context of the code (e.g. setq always refers to a variable).
In short, the two pieces of code are doing very different things. This doesn't mean they couldn't have an equivalent effect (e.g. the function might simply set the value of the variable); but whether or not that's actually the case is entirely up to the definition of the function.
1 In fact the first line of code is also calling a function2: it's calling setq and passing it two parameters visible-bell and t, and setq then sets the value in accordance with its parameters. Hopefully you're now starting to see how lisp syntax works?
2 Strictly speaking, setq is actually a "special form" rather than a function, and special forms are closer to macros than to functions; but these distinctions are not important for this Q&A.
Others have told you the basic points about what setq does and about variables versus functions.
Wrt visible-bell itself:
There is no function visible-bell delivered with Emacs, in any Emacs version I know of, and there never has been. (I've checked back through Emacs 20, and by memory I believe the same was true from the beginning. There is only the variable visible-bell.
So as #phils suggested, is not clear that what you said is true: "both seem to work". Unless some extra code you are loading defines a function of that name (and then there is no way for us to comment on it, not having it to see), evaluating (visible-bell t) raises an undefined (void) function error.
Variable visible-bell is not just a variable. It is a user option, and it has been, again, since at least Emacs 20.
You should not, in general, just use setq to change the value of a user option. In many cases you won't get into trouble if you do that, but sometimes you will, and it is not a good habit to get into.
setq does not perform any special initialization or updating actions that might be appropriate for a given user option. It is not intended for user options. Or rather, user options are not intended for setq - they can be more complex than what setq can offer.
What you should use instead of setq is Customize. Either interactively (M-x customize-option RET visible-bell RET, or C-h v RET visible-bell RET followed by clicking the customize link) or using Lisp code in your init file.
If you use Lisp code then use one of these functions (not setq):
customize-set-variable
customize-set-value
custom-set-variables
Use C-h f followed by each of those function names, to see what (minor) differences there are.
There are 3 issues here.
In Emacs Lisp, the same symbol can be both variable and function.
in the case of desktop-save-mode, it's a function but also a variable.
Because it's a function, so you can call
(desktop-save-mode 1)
Because it's a variable, so you set value to it
(setq desktop-save-mode t)
You can define your own function and also a variable of the same name to test it.
Note: exactly what a function's arguments should be or what the value of a variable makes sense depends on the function or variable.
Now, a second issue. In general, for function (commands) to activate a minor mode, the convention is that a positive integer should mean to turn it on, and otherwise turn off.
Also, for command to activate a minor mode, typically there's a variable of the same name, with value of t or nil, to indicate if the mode is on.
Now, there's third issue. For command to activate the mode, before emacs 24 or so, by convention, if no arg is given, the command toggle current state.
Because all of the above, the issue is confusing. You might see in init things like this:
(desktop-save-mode 1) ; correct. To turn on.
(desktop-save-mode) ; Confusing. Should take value 1 to turn on. Usually works because by default it's off.
(desktop-save-mode t) ; wrong. Take value of positive integer to turn on.
(desktop-save-mode nil) ; Confusing. Value should be integer
(setq desktop-save-mode t) ; wrong. Shoud call function instead
(setq desktop-save-mode nil) ; wrong. Shoud call function instead
(setq desktop-save-mode 1) ; wrong. Shoud call function instead. Besides, only t and nil make sense
So, there's a lot confusion. In emacs 24 (or 23.x), the convention changed so that, if it receives no value, it will turn on, if called in elisp code. (when called interactively as command, it toggles.)
In the end, always call describe-function or describe-variable to read the doc.
Well setq (which is "set" with an auto-quoting feature) is used in assigning a value to a variable. In this example, it's obviously not required because as you mentioned, omitting it works for the first set of examples.
Basically, visible-bell is a variable, and you assign it the value "t" to enable visible bells.
However, desktop-save-mode is an interactive function, so you don't use setq to assign it a value, you call it with parameters.
One good thing to do when you're not sure what something is, is to use the built-in help function:
C-h v visible-bell RET
This will return the information for visible bell -- notice the "v" in the command is because it's a variable. If you wanted to search for information on a function, you would do this:
C-h f desktop-save-mode RET
Incidentally in this case, desktop-save-mode is also a variable, but it's a read-only variable to determine whether or not desktop-save-mode is enabled, so trying to alter it will not work.
Is there a way to hook onto command A, so that B is always called after A executes?
I think the most straight-forward way to accomplish this is through the use of advice.
You would do something along the lines of:
(defadvice command-A (after b-after-a activate)
"Call command-B after command-A"
(command-B))
This approach has the advantage that it works even when command-A is redefined. It does not, however, work on macros or on primitive functions called from the C code. But, in practice the thought of advising those functions is rare.
That said, it might be worth looking into just defining a new command (command-C) which first calls command-A and then command-B.
You could also play around with symbol function indirection and writing a new command.
It kind of depends on what you're trying to solve.
You can advice a function using defadvice:
;; This is the original function command-A
(defun command-A () (do-it))
;; This call will cause (do-sometihng-after-command-A) to be called
;; every-time (command-A) is called.
(defadvice command-A (after after-command-A)
(do-something-after-command-A))
;; Enable the advice defined above
(ad-activate 'command-A)
See the info node (elisp)Advising Functions for more information and examples.
I'm familiar with scheme, but new to emacs (switching over from VIM) and elisp.
I know how to do the following:
make a simple key binding
C-c iwb = indent whole buffer
F2 = turns folding on/off
use slime from emacs
some basic keys, like C-x 2, paredit keys, some basic movement keys
I need help doing something a bit more advanced:
I want F3 to equal:
put emacs into C-x 2 mode
in bottom window, switch to "slime-repl" buffer
in the "slime-repl" buffer, send the command "(test/run)" <-- note, this is meant to be sent to the swank server, NOT to elisp
I realize it's terrible form to ask people to write a script for me; however, if anyone could do that, I would learn rather quickly from it. [And it would allow me to do more complicated types of scripting through studying your example.]
Thanks!
This is not exactly what you want, but should be a good starting point for further tweaking:
(defun slime-run-test ()
(interactive)
(slime-interactive-eval "(test/run)")
(slime-pop-to-buffer (slime-output-buffer) t))
(global-set-key (kbd "<f3>") 'slime-run-test)
I don't use slime, but assuming it uses comint-mode then I would think the following might do the trick:
(defun my-slime-test-run ()
(interactive)
(delete-other-windows)
(split-window-below)
(with-selected-window (next-window)
(switch-to-buffer "slime-repl")
(goto-char (point-max))
(insert "(test-run)")
(comint-send-input)))
(global-set-key (kbd "<f3>") 'my-slime-test-run)
There is probably a better way to do this, but hopefully that gives you a little insight into how you can write elisp functions to carry out tasks in the editor (and note how the function reads very much like a set of editor instructions -- you can do a lot simply by converting the keystrokes you would use into equivalent code -- or even not writing code at all, and simply recording & saving keyboard macros).
Use C-hf name-of-the-function RET to get documentation on any of the function/macro calls in that function.
For the keybinding, I used C-hkF3 to check how Emacs referred to that key, and then used that string as the argument to kbd (and note how you can use that sequence to find the name of the function bound to any given key sequence, which you can then utilise in code if desired).
Many things are far less obvious if you don't already know them, but that's only to be expected with a code base as large as this (and dating back as long as this).
The great thing is that if you don't know what you're looking for, you can always search for function names matching patterns with C-uC-ha (and similarly for variables, values, libraries, and documentation; see M-: (info "(emacs) Apropos") RET for more about this facility). Plus the info manuals (complete with indexes -- press I or i within any particular manual, or use the info-apropos command to search all info manuals at once).
Truly one of the very best things you can do is to learn how to use the self-documenting nature of Emacs to find answers to the things you don't already know.
After a few years customizing my .emacs file, I find I used two different
kinds of constructs to setup major-mode-specific key bindings:
1. using a hook and local-set-key. For example:
(defun my/bindkey-recompile ()
"Bind <F5> to `recompile'."
(local-set-key (kbd "<f5>") 'recompile))
(add-hook 'c-mode-common-hook 'my/bindkey-recompile)
I would say this construct makes it easy to use the same key bindings for
different major-modes by adding the same function to all relevant major-mode
hooks (in other words, the "which keybindings do I want" is clearly separated
from the "for which modes do I want them"). However, I'm not comfortable with
the fact that such customizations are done at the buffer level, whereas I would
think they belong to the major mode.
2. using define-key (often combined with eval-after-load to delay
evaluation until the relevant keymap is loaded). For example:
(eval-after-load "cc-mode"
'(progn
(define-key c-mode-map (kbd "C-c o") 'ff-find-other-file)
(define-key c++-mode-map (kbd "C-c o") 'ff-find-other-file)))
By contrast, this construct customizes the major-mode itself, but is less
flexible: if I want to use the same key bindings for another mode, I will have
to find the correct file and keymap names for this mode, and almost duplicate
the eval-after-load expression (although this could probably be automated with
a function/macro).
Question: although both construct types work well and produce the result I
want, they are technically very different, setting-up the key bindings in
different keymaps at different times. So my question is: among these two
constructs, is there a "preferred/better" way to do things? (Or maybe the "best"
construct is a third one which I'm not aware of?)
By "preferred/better", I mean such things as:
less prone to break with new emacs versions
less prone to disturb/be disturbed by active minor-modes
more idiomatic / readable / shareable with others
I believe the two approaches you describe are less different than you think.
Notice that local-set-key does in fact evaluate (define-key map key command) where map is the value of (current-local-map), which is typically set by the major mode.
So although they could be doing different things; most of the time the only real difference will be that the hook function with the local-set-key call will be setting that same key repeatedly/redundantly, whereas the other approach sets it only once.
You can demonstrate this to yourself by using local-set-key in a mode hook, removing that hook function after it has been used, and then creating a new buffer in that same major mode, and testing the binding.
less prone to break with new emacs versions
I guess you could argue that the name of a keymap might change in future and therefore not needing to know the name is an advantage, but you could equally say the name of the mode hook might change. I don't think either is enough of a concern to worry about.
One thing to note is that local-set-key will work even if the major mode did not establish a current-local-map, which I guess makes it slightly more robust as far as generalised approaches go.
less prone to disturb/be disturbed by active minor-modes
There's no difference. All minor mode keymaps take precedence over all major mode keymaps, and neither approach is going to have any effect on the order of minor-mode-map-alist (which determines the precedence of minor mode keymaps).
more idiomatic / readable / shareable with others
They're both entirely readable to my mind, so I can't distinguish them in this aspect either.
I say just use whichever approach seems best to you in each context. I do think it's good to have a standard approach for most things for the sake of consistency in your code, but I doubt it matters which one you choose. There's obviously a saving of a few CPU cycles to be had by not evaluating the same code unnecessarily, but that should matter so very little as to be of no concern whatsoever.
I think the most obvious case for one over the other is the one you already mentioned -- if you want to apply the same binding to multiple modes using a common hook (but not to all modes -- for that I thoroughly recommend creating a custom minor mode), then a local-set-key within that hook is definitely the way to go.
I have lots of custom keyboard commands and I couldn't bother with various ways to set them in Emacs and all these keymaps overriding each other, so I just installed John Wiegley's bind-key as per my relevant answer.
(require 'bind-key)
(bind-key "C-l" 'goto-line)