I'd like to set up a number of keybindings globally for all modes. I understand that there are certain Emacs keybinding prefixes that are "reserved" for the user but is there a keybinding prefix that is "safe" across all the different kinds of modes?
Safe for whom? A library or a user?
See the Elisp manual, node Key Binding Conventions for exactly which keys are reserved for users, for major modes, and for minor modes.
As you don't say just what you are doing, it's impossible for us to guess which category your question falls into.
As for a prefix key, you can see that you should not count on using C-c, C-h or <f5> through <f9>, if you want your prefix key to be "safe" in all contexts.
As #drew points out, look at the tips section of the manual for some guidance on key binding conventions. It can be a bit challenging to work out where to bind things, especially when you don't want to possibly interfere with standard bindings or end up having your bindings shadowed etc.
The problem with answering this type of question is that key bindings are very much a matter of personal taste. For example, I see many suggestions that the first thing you should do is redefine the caps lock key to be a ctrl key. This seems like good advice given the ctrl key is often difficult to press in key chord combinations and has the potential to create various strain issues. However, I don't do this because I don't seem to have an issue with Ctrl being where it is and more importantly, I want to have a ctrl key for both my left and right hand to use. I find keyboards with only a single ctrl key far more frustrating than the key being down low and only really accessible to my pinky!
The other thing which can make advice in this area difficult is the variation you get on different platforms and with different desktop environments. Nearly all platforms now have some level of keyboard shortcut mechanism. The problem with this is that in some cases, various key combinations will be 'stolen' by the underlying OS or more often, the desktop environment. This frequently means that to get your ideal emacs environment, you will often need to also tweak your OS or desktop environment as well.
Something which may help is if I describe my approach to addressing this issue. It won't provide you with an exact or specific answer, but it may provide you with some ideas which will help you find the most appropriate solution for your circumstances.
I run emacs under Linux and OS X. I don't use windows and have never run emacs under windows.
I try to use a scheme for my key bindings which will work the same across environments. However, my approach is constantly evolving. I only started using OSX a while ago and it has required me to change my scheme a bit to improve the consistency across platforms.
There are two packages I find very helpful when trying to sort this out. Both are available via MELPA. free-keys and the bind-keys package. The free-keys package can show you what keys are available and the bind-keys has a very useful command describe-persoanl-keybindings, which shows what keys you have bound and in some cases, what the key use to be bound to. I find this an extremely useful command for both planning and diagnosing problems.
Originally, my approach was to find a global key binding for a command which I seldom or never use, for example C-z => suspend-frame or M-` => tmm-menu-bar and undefine it. I would then define those keys as prefix keys for my own personal keymap and define keys under that.
The advantage to this approach is that I can be fairly confident that nothing will cause my bindings to be shadowed or get redefined and all my bindings are tied to a separate prefix.
Something I'm experimenting with now is the use of the super and hyper modifiers. In particular, the super modifier has become easily accessible as the 'windows' key on most keyboards and these days, is trivial to configure under most Linux distros. The key position is also close to the position of the 'option' key under OSX.
The only problem with using these keys is that they are frequently used by the OS or desktop environment. In some cases, this is easy fixed us the OS or desktop environment preferences mechanism, but in other situations, it seems the key binding is too tightly coupled with the OS or desktop environment and you cannot change it. The only solution I've found is to conduct a bit of trial and error. However, once you do have it sorted, it is very unlikely that any emacs libraries or features will clobber your bindings and unlikely you are clobbering something you are unaware of. Extremely useful and often overlooked modifiers IMO.
finally, remember C-h k - this key is essential when trying to work this stuff out.
Could someone please have a brief explanation on (defadvice ...), I'm not getting when is the suitable context to use it, seems it's not common in C/C++/Java languages? Such as the example shown in the figure attached. Many thanks.
Advising a function (whether using defadvice or the more recent advice-add etc.) is an alternative to redefining it.
If you are not the author of a function, and if it might already be used in various places beyond your code, you can either redefine it or advise it, and thereafter each use of that function will use your redefinition or your advice. And this is reversible: you can disable your advice.
Redefining a function does not, in general, play well with other libraries, which themselves might want to redefine or extend it in some way.
The point of advice is that it allows multiple libraries to alter or enhance a function definition in a reasonably controlled way, so that there is less chance of the different libraries stepping on each others' toes. Or at least so that it is easy to remove the effect of any of the library changes to the function.
Recently, I want to make a library to operate the Windows registry.
The first thing I want to do is making the input of registry key path easily. Since it looks like a file path, maybe this can be achieved by methods like read-file-name'? Every time the user input the/' and push key, I can use the `reg query' shell command get the next possible sub keys.
But how to make it really in real emacs lisp code?
Or maybe there is already a full functional library?
You'll basically have to write a "completion-table" for your registry keys. I don't think this completion table already exists in Emacs. You can use the code of completion-file-name-table as inspiration.
I'd like to re-map my EMACS to put the most common commands on the home row. Which commands are the most common? Is there some way I could measure this? Has someone already attempted this?
The most common command is probably self-insert-command, but that's already bound to most keys directly. :)
I'd say it depends on the user. So measure your own most-frequently used:
Link
And although Randal was mostly making a joke, self-insert-command is my most frequently used, consistently around 20-25%.
If you take a look at the web page for command-frequency, you'll see that the most common commands are:
self-insertion
movement
isearch
paste
save-buffer
...
We're struggling to come up with a command name for our all purpose "developer helper" tool, which we are using on our project. It's like a wrapper for our existing tools like cmake and hg. The purpose of the command is really just to make our lives easier by combining multiple commands into one (for example, publishing packages). For example, we have commands like:
do conf
do build
do install
do publish
We've considered a few ambiguous names like do (as above) and run, but obviously, do is a Linux bash command and run is pretty ambiguous.
We'd like our command to be 2 chars short, preferably - but who thinks we're asking the impossible? Is there a practical way to check the availability of command names (other than just typing them into your terminal), or is it just a case of choose one and hope nobody else will use it? Are we worrying about nothing?
Since it's a "developer helper" tool why not use hm [run|build|port|deploy|test], Help Me ...
Give it a verbose name, then let everyone alias it to whatever they want. Make sure you use the verbose name in other scripts so that it removes ambiguity.
This way, each user gets to use whatever makes sense to him/her, and the scripts are more readable and more easily searchable (for example, grepping four "our_cool_tool" will usually yield better results than grepping for "run").
How many 2-character words are useful in this context? I think you need four. With that in mind, here are some suggestions.
omni
torq
fluf
mega
spif
crnk
splt
argh
quat
drul
scud
prun
sqat
zoom
sizl
I have more if you need them.
Pick one: http://en.wikipedia.org/wiki/List_of_all_two-letter_combinations
To check the availability of command names, I suggest looking for all two-letter filenames that are in the directories in your path. You can use a script like this
for item in `echo $PATH | sed 's/:/ /g'` ; do
ls -1d $item/??
done
It won't show builtins in your shell (like "do" as you mentioned) but it's a good start.
Change ?? to ??? for three-letter files, etc.
I'm going to vote for qp (quick package?) since it's easy to pronounce, easy to type, and easy to remember where the keys are on the keyboard.
I use "asd". it's short and most developers type it without thinking
(oh, and you can always claim later that it stands for some "Advanced Script for Developers" if you need to justify yourself a few years from now)
How about fu? As in Kung Fu. It's a special purpose tool. And it's really easy to type.
I think that run is a good name, at least anybody that will download your project will know what to do. Calling it without parameters should reveal your options.
Even 'do' will do, I think you can use backquotes to run it from bash scripts.
Also remember that running the tools without parameters will tell you what options you have.
Use makefiles to do everything for you.
How about calling it something descriptive, like 'build_runner', and then just aliasing it to 'br' (or preferred acronym) in your .bashrc?
There is a really crappy tool called cleartool (part of clearcase), and people will alias it on their machine to "ct". Perhaps you can have a longer command and suggest users alias it.
It would probably be best to do something like ire_and_curses suggested, name it descriptively then alias it to a 2 letter command. If I was choosing, I would name it dev_help and alias it to dh.
I think you're worrying about nothing. Install the program as 'the-command-to-do-evertyhing-and-if-you-dont-make-your-own-alias-for-it-you-should'. I don't think that will be too long for any modern filesystems, but you might need to shorten it to 'tctdeaiydmyoafiys'. See what common aliases are used, and then change the program's name to that. In other words: don't decide, let natural selection decide for you. If you are working with a team of < 10, this should not even remotely cause any problems.
Call it devtool alias to dt
Custom tools like that I like to start with the prefix 'jj-'. I can type (with big index-finger power) 'jj ' and see all my personal commands. Also, they group together in alphabetical lists. 'J' is not a very common character for built-inc commands, but you can pick your own.
Since you want two characters, you can use just 'zz', or something starting with 'z'.
Are you sure you want to put all your functionality in one command? That might be simultaneously over-constraining and over-loading the interface a little.
do conf
do build
do install
do publish