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.
Related
ctags is a simple source code tagging system, also integrated in vi (and its flavours nvi, vim, etc.). AFAIK, it builds a plain text file where all the elements (functions, macros, ...) of the source code are indexed. But this file may become too large and unmanageable when the source code tree is extremely huge: this is the case of a kernel (Linux, *BSD, or similar).
Is still ctags or exuberant-ctags suitable for a complex source tree like a kernel?
If not, what tools (with the same integration in vi as ctags) can replace it? This may become subjective, so if possible provide a list of suggested tools: any comments, and references to a guide with the keyboard shortcuts in vi, are welcome.
Supported languages should be at least C, C++, assembly. The tool should be usable through CLI. I would principally like to jump to the definition of functions, macros, struct and similar objects (with ctags, pressing Ctrl+] with the cursor over the item name), to their manpages if possible, and back to the code.
The only alternative tool I know so far is GNU global, with a pretty complex vi integration, which seems to be possible only through Perl (and I can't find the equivalent of Ctrl+]).
The answer to your first point is a resounding yes.
You can use ctags to generate a tags file for different subtrees, thus keeping the size of the generated file to a minimum. At this point, you need to have a mechanism in place for searching for these multiple tags files. Vim provides this, of course.
I have given some advice here, so you may want to check that out.
Of course, I use exuberant-ctags there, so keep that in mind.
Using xbindkeys I can register key bindings to run a command or run a guile scheme function. For example windows key + Up to maximize screen
Does racket have any libraries that could be used to register global key combination bindings, that could trigger racket functions? I would much rather write scripts in racket than in guile scheme.
Python also has something similar here
https://python-evdev.readthedocs.io/en/latest/usage.html#listing-accessible-event-devices
It's not clear exactly what you're asking, but it looks to me like you're hoping to replace the guile backend used in xbindkeys's configuration file with Racket. There might be an easier way to do this, but I think I would suggest that unless you have a need for specific features, this might be a great time to get to know Guile better :).
As described here, emacs-lisp-mode provides for special handling of s-expressions in docstrings that start in the first column. This requires them to be escaped with a backslash to avoid mucking up font-lock later on in the file.
This may be a feature for elisp, but is unfortunate in other lisp modes that reuse emacs-lisp-mode for convenience that don't have special handling of expressions in docstrings, as described/shown here.
My question is, is there any way for such "descendant" modes to configure emacs-lisp-mode to disregard "calling convention expressions" in docstrings?
The short answer is no.
The longer answer is that those other modes are simply broken. They should adapt to Emacs Lisp in this regard. There is no reason not to, is there? It is simply a bad idea to use workarounds (e.g. indent all doc-string lines), such are suggested in the link you provided (and its linked duplicate post).
Emacs doc string are not trivial strings. They have several special properties, including the handling of \\[...], \\{...}, and \\<...>, as well as the property you mention here.
If some mode cannot adjust to Emacs doc strings then it should use macros that define the things it needs without creating Emacs doc strings for them but by handling a different string argument in the special way desired. IOW, create pseudo doc strings that correspond to what the mode wants instead of what Emacs wants.
Of course, that means that you cannot directly take advantage of the Emacs documentation features. You would need to also define mode-specific doc commands that would, for example, wrap the existing doc functions such as describe-function with code that picks up the mode's pseudo-doc string and DTRT, following the mode's conventions instead of the Emacs doc-string conventions.
But I would think that the easiest approach would be to just adapt the mode to the existing Emacs behavior, so that it DTRT.
Many Emacs programming modes, and various Lisp modes are no exception, have been implemented based on parsers with regular expressions. This, unfortunately, gives the editor little idea of the document being edited. Eclipse, for example, has a very different idea of how to edit code, which is more structured, and JetBrain MPS editors are even more rigid and structured in this sense (almost like spreadsheets).
This makes Emacs modes faster and easier to implement, but it also means the code that supports the proper indentation, syntactic validation and highlighting has to re-parse more text every time it is being edited. CEDET, afaik, is trying to address this issue.
Thus, historically, there had been conventions designed to reduce the amount of code to parse on each edit. Parenthesis in the first column is one such convention. However, it also has been known to be an annoyance some times, that's why there's a open-paren-in-column-0-is-defun-start variable one can set to nil to inhibit this behaviour.
But It's hard to say what exactly the performance issues you may face when changing this setting. Lisp grammar is very regular, unless you are using many reader macros, so, perhaps, that won't be a problem.
If beginning-of-defun-function is set accordingly, i.e. checking if inside a comment or string, should be no need for such escaping.
I am a newbie on Emacs. I was going to learn how to close a buffer, so I typed M-x apropos-documentation RET close buffer. Then I got a lot of useless information.
Given the above senario, what's the right way to find what I wanna know using the self-documenting system?
Or the self-documenting system is useless compared to Google in the modern day?
When you are just beginning with Emacs, the best documentation to start with is the tutorial. You can get there with C-h t. A half hour spent doing the tutorial will show you all the basics, including buffer management. This will save you a lot of time compared to searching for each command individually, either via Google or apropos.
Another benefit of the tutorial is that you'll get a quick overview of Emacs' idiosyncratic terminology. For example, the word 'kill' is used as a near-synonym for 'delete'. Searching for 'kill buffer' with apropos would likely have answered your question.
You are better off with Google until you know the terminology and maybe even after that. I've used the emacs documentation system a lot, but mainly for looking up something which I already knew about, or something for which I already knew the exact terminology.
If you are unsure how to search for something in the documentation then Google is much more effective, because it also takes synoyms into account and it finds questions similar to yours from forums and stuff. It does not only apply to Emacs, but to any other software as well. Regardless of the software I always try a Google search first, because in most cases Google throws out the answer much more quickly than browsing the documentation,
So a basic terminology problem tripped you up here. I would say that Emacs doesn't help here by not catering for this case in the glossary, and naming the relevant menu item "Close" and binding it to a different function to the C-xk sequence (which would be to avoid prompting you again). I note that the tooltip for that menu item does at least indicate the "kill" terminology, however, which certainly would have assisted your search.
That mismatch was always going to cause problems for searching with apropos, but the self-documentation in Emacs goes beyond that. Really, the tutorial or user manual should have been your next step. (The tutorial should be your first step, in fact.)
Any of the following would have found you the answer fairly quickly, even without knowing the "kill" term.
Go through the tutorial: C-ht
Look for "buffer" in the manual's contents page: C-hr
Search the manual's index C-hrI buffers RET
(admittedly searching for buffer (singular) provides more cluttered results)
Search the keybindings: C-hbM-x occur RET buffer RET
(occur is a bit more advanced, but C-s would work too)
C-hk click the "File" -> "Close" menu item
(which is not the same binding as C-xk as commented on above; but this would also have shown the "kill" terminology)
I think it's a bit of a shame that the accepted answer for a question entitled "How to effectively use the self-documenting system of Emacs?" is one which steers you away from those systems, as once you know your way around them you'll rarely need anything other than Emacs' own documentation.
First of all, just because you did not understand the information, it does not mean that it is useless.
Second of all, once you have even the slightest idea what commands are called, you can do M-x, and tab-expand the command. Once you've invoked it, emacs will also flash up a message telling you the key binding for that command if there is one.
I wrote an extensive tutorial on learning Emacs via its built-in help and elisp source code: http://david.rothlis.net/emacs/howtolearn.html
Several people have found it very useful.
The self-documenting nature of Emacs is amazing (once you learn your way around).
Also
emacs-index-search
elisp-index-search
Get aquainted with th C-h chords [1]:
C-h a command-apropos What commands work like this...?
C-h c describe-key-briefly What command does this key sequence do?
C-h b describe-bindings What are the key bindings for this buffer?
C-h k describe-key What command does this sequence do?
C-h l view-lossage What are the last 100 characters typed?
C-h w where-is What is the key binding for this?
C-h f describe-function What does this function do?
C-h v describe-variable What is this variable?
C-h o describe-symbol What is this symbol? (function, variable or face)
C-h m describe-mode Tell me about this mode.
C-h s describe-syntax What is the syntax table for this buffer?
Although they wouldn't have helped with the particular query you were after, they come in handy very often. As for apropos, give up. Use Google and the Emacs Wiki instead.
There are several questions on SO about how to get code folding in emacs, without having to add any special characters like "markers" in the comments for example. Someone said that there was "no perfect solution."
It seems that it could be done by parsing the source of the program being written and look for matching parenthesis or bracket, or to do it based on indentation. You could also use a combination of scripts that use different methods.
So why is it commonly accepted that there is no "perfect" and straightforward way to get code-folding in emac? Is there something in emacs or its architecture that makes it hard to program? If it were easy, after so many years of smart people using emacs you would think that someone would have wrote it.
You should play with Hideshow (hs-minor-mode) combined with fold-dwim.el. It does exactly what you suggested -- looks for matching braces/parens, and can be set up to fall back on the indentation.
There's a robust folding solution out there for most common languages, and if there isn't, all the folding packages are highly customizable. In fact, the only downside is the proliferation of folding methods (fold-dwim helps quite a bit with that); I used to think that because nobody could point me to a definitive solution, folding was hard or impossible — in fact, the opposite is true. You just have to experiment a little to see what works best for you.
I have used folding.el (e.g. to group stuff in my .emacs), outline-minor-mode, and now Hideshow. There's some chance that none of them would work exactly the way you want right out of the box (e.g. you might need to set up an outline regex, or define folding marks for folding.el), but it turns out to be easy. The default keybindings can be somewhat baroque, but this is remedied by fold-dwim and/or hideshow-org (highly recommended for Hideshow, cf the Emacswiki hideshow page; you can also mimic hideshow-org's behavior for other folding modes with some quick-and-dirty elisp and fold-dwim). Once you figure out your preferred setup, just turn it on automatically via hooks or buffer-local variables, and watch your code fold away :)
You should look into CEDET. It does code-folding just fine, and many other fancy features that you're probably looking for if you're switching from an IDE to Emacs.
http://cedet.sourceforge.net/
Specifically, look for `global-semantic-tag-folding-mode'
You don't need anything extra, just enable outline-minor-mode for file types you want to fold.
But in fact, there ARE various solutions for Emacs; I have listed some of them (those I have happened to come across) at http://en.wikipedia.org/w/index.php?title=Code_folding&oldid=375300945#cite_note-2.
Though, there are things I'm missing: in some cases, I'd like to combine several mechanisms: for example, for markdown, I'd like to use outline-based folding (for sections) and indentation-based folding (for quotations, code blocks etc.) -- in order not bother with implementing a complete parser for markdown.
Here they are:
Token-based folding in Emacs
Token-based folding in Emacs is impemented by the folding minor mode.
Indentation-based folding in Emacs
One can use the set-selective-display function in Emacs to hide lines based on the indentation level, as suggested in the Universal code folding note.
Syntax-dependent folding in Emacs
Syntax-dependent folding in Emacs is supported by:
the outline and allout modes
for special dedicated "outline"-syntaxes;
by the hideshow minor mode for some programming languages;
also,
by the semantic-tag-folding minor mode and the
senator-fold-tag command for
syntaxes supported by semantic,
as well as by doc-mode for JavaDoc or Doxygen comments,
by
TeX-fold-mode
sgml-fold-element command,
nxml-outln library
in the corresponding language-specific modes, and possibly in other modes for particular syntaxes.
Several folding mechanisms are unified by the
fold-dwim interface.
See also http://www.emacswiki.org/emacs/CategoryHideStuff.
Folding of user-selected regions in Emacs
Folding of user-selected regions in Emacs is implemented by the hide-region-hide command.
I have been using folding-mode for quite some time. With auto-insert template and abrevs it works quite well for me for for some nice bricks of code.
Being able to produce the buffer folded (for printing/emailing) has always been a desire of mine. Some of my folding tags are for secure / password hiding.
I know this is a bit old but for me origami.el works perfectly well out of the box.
Yes Finally code folding is there in emacs. Try yafolding present at melpa.org package library.