I have been using Emacs for more than three years now but it still takes me days to write even small functions in Lisp. I've looked through GNU Emacs Lisp Reference Manual but it's huge and structured completely opposite from JavaDoc, not from functions to descriptions but the other way around.
What will make my life much easier is some sort of small JavaDoc like document with most commonly used Emacs internal functions and they quick description.
(point) - returns current position in buffer
(save-excursion (p)) - saves current position in buffer before
executing (p) and restores it afterward.
Does anyone know where I can find something like that?
Have you tried the build-in manual in emacs? Open any lisp buffer (or any buffer in lisp mode), move your point to any function or variable, and hit C-h f (for function) or C-h v (for variable). Emacs will give you a fairly concise description of the function/variable.
For example, the manual content for (save-excursion) is
save-excursion is a special form in `C source code'.
(save-excursion &rest BODY)
Save point, mark, and current buffer; execute BODY; restore those things.
Executes BODY just like `progn'.
The values of point, mark and the current buffer are restored
even in case of abnormal exit (throw or error).
The state of activation of the mark is also restored.
This construct does not save `deactivate-mark', and therefore
functions that change the buffer will still cause deactivation
of the mark at the end of the command. To prevent that, bind
`deactivate-mark' with `let'.
The good thing also is the build-in manual give you "link" to to the source code of the function and to other functions that might be related, which make it nice to browse around.
Of course you can't learn lisp this way, but for looking up documentation of function this is a nice starter. When you find the build-in manual not understandable (which sometimes does happen), then it's time for you to google the function ;)
This site has some emacs lisp summary information that may be useful: http://xahlee.org/emacs/elisp.html.
In particularly, check out these links on that page: Basic Text-editing Functions, Emacs Lisp Idioms and Batch Text Processing
The GNU Introduction to emacs lisp is certainly more approachable than the reference manual.
I would add a couple of things:
M-x apropos - searches functions and variables for whatever string you specify (e.g. directory). Note that this is slightly different than C-h a, which only finds interactive functions
find a similar piece of code and copy it - you can learn an awful lot about how to do things by looking at what's already done. If you have a particular function you want to see examples of, one good way is to visit the main lisp source directory in dired (e.g. d:/product/emacs/lisp or /usr/share/lib/emacs/lisp) and do % g which will grep through all files looking for whatever string you type. Open up that file and see what other people have done with it.
C-h f and C-h v - as someone else mentioned, you can open up source, position point over a function or variable and then get documentation on it.
Check out the Emacs wiki, which has a crap-load of Emacs lisp modules for you to peruse.
I think you are taking the wrong approach. When learning a
programming language and set of libraries (collectively, "Emacs
Lisp"), you need to approach it on both the micro and macro scale.
Before you can start writing software, you need to know what tools you
have available. That is what the Emacs Lisp manual aims to educate
you on. You really need to sit down and read the whole thing. That
way you know what features Emacs provides.
After you do that, you need "micro-level" information. There are
a number of sources that provide this. If you have a general idea of
what you need to do ("working with buffers"), then the Lisp reference
is a good place to figure out what you need to know. If you know that
there's a function that does what you want, but don't quite remember
the name, then M-x apropos (C-u C-h a) will help you search the
documentation. If you know what function you want to use, but don't
remember quite how it works, then M-x describe-function (C-h f)
will sort that out for you.
So anyway, the key is to learn Emacs Lisp, and then let Emacs help you
with the details. A list of functions isn't going to teach you much.
(Oh, one more thing -- you should familiarize yourself with Common
Lisp. Most Emacs libraries use cl, which are the useful CL
functions implemented in Emacs Lisp. loop, destructuring-bind,
defun*, and so on are all there, and they are very helpful.)
Good suggestions from others -- Emacs help system is your friend.
In addition:
http://www.emacswiki.org/emacs/EmacsNewbieWithIcicles
http://www.emacswiki.org/emacs/Icicles_-_Progressive_Completion
http://www.emacswiki.org/emacs/Icicles_-_Nutshell_View#ChippingAway
In order to understand what's on, quite often it's useful having a look at the source code.
http://repo.or.cz/w/elbb.git/blob/HEAD:/code/Go-to-Emacs-Lisp-Definition.el
Have you tryed <f1> f ? It is bound to describe-function. Example with point:
point is a built-in function in C source code.
(point)
Return value of point, as an integer.
Beginning of buffer is position (point-min).
[back]
Like most Lisp systeme, Emacs has an integrated documentation tool!
Any Lisp function or variable can declare an optional doc string.
Almost all standard command or function do declare a usefull doc string.
Emacs (like most Lisp systems) allows you to display the doc string of any function or variable (<f1> f and <f1> v) at any time.
When displayed, the doc string is browsable, meaning that you can click on symbols to see their doc string, or go to the source of the corresponding function or variable.
As soon as you evaluate any defun or defvar, its doc string is available through describe-function or describe-variable: this doc is alive!
M-x find-library RET <library name> is all you really need
If you're willing to fork over money for a dead tree, I'd recommend
(source: oreilly.com)
In XEmacs, and I believe in Emacs as well,
pressing C-h f, then the tab key for tab completion, which at that point is all functions, will give you a list of functions the editor knows about.
You just use cursor keys and scroll to one you want to know about and press enter to see details.
If a list of functions, with further info available, is what you want, that will give it to you.
This list is all currently available functions, so if you have packages of lisp installed, it shows the functions those packages supply as well as native functions. In my copy of XEmacs, today, I have 6,586 functions in the list. Emacs will be similar.
The problem is that not all functions have names that make them context-meaningful (ie not all menu variables/functions have the word menu in them, so you will miss some things if you go by names only.
You can use the INFO pages (on the menu) to view them more topically arranged, and get to the same usage information.
Download source code for Emacs. Go to src/ folder and type:
grep -r DEFUN *
You will get list of all primitive Lisp functions of Emacs.
Related
as the title said, I am learning common lisp right now and using portacle, following Practical Common Lisp by Peter Seibel.
I found it quite annoying that the Slime-repl-sbcl buffer keep the writing at the end of the screen (using C-l or C-v doesn't help since once I try to execute an expression it will roll back to the end of the screen)
Is there anywhere to improve this? (should I just write on a text file and compile it? the only similar subject I found was about Cider repl and couldn't understand it, since I am still new to lisp)
Thank you for your time
I would like this fixed too. No solution yet. In slime-repl.el, I found:
scroll-conservatively (variable):
A value of zero means always recenter point if it moves off screen.
my test wasn't conclusive.
slime-display-output-buffer (function), which calls slime-repl-show-maximum-output, which role is to
Put the end of the buffer at the bottom of the window.
I rewrote slime-display-output-buffer without this call, but that wasn't conclusive either.
Maybe I tested badly.
(I'm making this answer a wiki)
You would indeed typically write in a source file, and compile each expression separately. Use the REPL only to test functions or do simple computations. To compile functions (or really, any toplevel expression), use C-c C-c - bound to slime-compile-defun by default - when the point (= your cursor) is inside the function's code. The REPL will then "know" of it, so you can test it there, but as it is now written in file, you can also modify it without having to copy/paste anything ! Just make sure to recompile functions that you modify !
If you want to compile/load entire files at once, look at the other compilation commands, e.g. slime-compile-and-load-file (see the SLIME manual, and its Compilation section)
For your problem: there is Emacs variable, named comint-scroll-to-bottom-on-input (or something along those lines, can't remember exactly ...) which enables the behaviour you are seeing, so that you don't have to scroll back to enter new expressions. It is possible that SLIME has another variable which configuring this behaviour for its REPL; in that case, it would probably be named almost the same, and you can set it to nil to disable it.
Finally, don't hesitate to look at the other tools provided by SLIME ! For example, it comes with an "inspector" (see the relevant section), that you can use instead of evaluating expressions such as *db* in the REPL. In that simple case, it makes no real difference, but if you start having - say - hash-tables or different structures/classes, it becomes an incredible tool for interactive development, to examine the internal of almost everything, redefine things directly from within the inspector without needing complex accessors, and so on.
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.
I would like to know the best way to customize auto-formatting/auto-indenting in vim for Common Lisp.
Auto-formatting (I usually do this by typing '==' in command mode per line) works very well for the base lisp language in vim (e.g., defmacro, defun, lambda, if, with-output-to-string), but any time that new language constructs are defined (e.g., using macros), I find that the formatting for the new construct is often not what I'd like it to be.
For example, here's how vim formats 'when (standard lisp construct) and 'awhen (commonly-used anaphoric version of 'when; not part of lisp standard)
(when 'this
(process 'this))
(awhen 'this
(process it))
I would like 'awhen to auto-format like 'when. Any ideas how I can do this?
Edit: Thanks Gilligan and Tamas for the Slimv recommendation. As a test, I downloaded MacVim (will need this working with terminal vim, but that's a different problem) and slimv, rsynched the slimv download into ~/.vim, launched MacVim, and loaded a .lisp file.
I then started up the lisp server (done through a GUI with MacVim), which loaded up my default lisp executable and core file.
And* since my core file is already loaded with the language extensions that I commonly use (awhen being one of them), awhen formatted correctly right out of the box.
I really like this solution. Instead of [1] having to learn how to tell vim to indent particular functions properly, and [2] writing the code that does this explicitly for each language extension that I define, and [3] updating that code every time I add a new language construct. Instead I leverage slimv to do the formatting for me. And slimv can 'learn' new language extensions, as long as those macros are already loaded into the lisp core that the server session is using. Pretty slick!
I have found that this works well for a particular class of language extensions. Usually ones defined as a macro, using the &body keyword. This seems to 'do the right thing' most of the time, but there are macros I use that still don't properly auto-format. Although I'd say that this is more likely to be an issue with how the macro is written (non-standard language extension) than anything else.
So, this solution works well for me for most cases, and I didn't have to code (and maintain) anything. Great stuff!
This might not be a direct answer to your question but I strongly suggest that you install
the slimv plugin: http://www.vim.org/scripts/script.php?script_id=2531
Its a great plugin which integrates SLIME functionality into vim and besides many other things it also comes with an improved indentation for clisp&clojure. It won't indent awhen the way you want though.
For those who are looking for this topic and don't want to run Slimv, because they aren't working with Common Lisp or other reasons, here is the scoop.
Vim's Lisp indentation is not like that for other languages; it has a special "Lisp mode". This mode is turned on by
:set lisp
which is done automatically for .lisp files. Lisp mode isn't a Vim invention; classic Vi implementations have a Lisp mode turned on with :set lisp. (It's not described by POSIX, unfortunately).
Vim's Lisp mode has a simple mechanism for recognizing forms that require operator-style indentation: namely, there is a parameter called lispwords which holds a comma-separated list of identifiers.
You can prove to yourself that this is the identifier list which is used, even when you're editing a Common Lisp .lisp file with syntax highlighting and all. Simply do :set listwords[TAB] and edit the list to remove something from it, such as defun. Then try to reindent a defun: you will see the function-style indentation now instead of the operator-style.
The syntax highlighting support for Common Lisp is separate from Lisp mode's lispwords parameter; it has its own list of identifiers. For example, in Vim 7.3 if you enter this:
(symbol-macrolet ((foo bar))
you get indented out to here!)
This is in spite of the fact that symbol-macrolet is recognized and colored. Why? It's because symbol-macrolet does not appear in the rather scanty lispwords list, whereas it does appear in the lisp.vim syntax highlighting definition file.
The upshot is that you can cob together some script which scans your directory of .lisp files for macros and generates a set lispwords=... command that is placed into a directory .vimrc.
Or if you are working on a custom Lisp dialect, you can just make its Vim syntax highlighting file customize lispwords when it loads.
Here is an implementation oversight: the lispwords option has no local value; you cannot use setlocal lispwords ... to give it a buffer-specific value. In other words, it appears that (at least in the Vim 7.3 I'm using under Ubuntu) you can't have two or more buffers open holding different dialects of Lisp with different identifiers for indentation. The default contents of lispwords contains a smattering of Lisp and Scheme symbols to try to be a kind of "one size almost fits all" solution.
If you filetype is 'lisp' then I think you need to add indenting rules for your special case in the 'lisp.vim' file in the '/vim7x/indent' directory. You can find a bit more info in help at :h indent-expr and :h indentexpr.
Someone may be able to tell you better, but I believe the default lisp.vim indent file basically does nothing because the built-in function lispindent() is used to get indent values. You will want to:
(1) set function used to get indent values (i.e., indentexpr) to a function in your own indent/lisp.vim file, e.g., GetLispIndent().
(2) in your your GetLispIndent() function you will use lispindent() to get indent values to return for all lines except your special case. See other languages' indent files and read the docs to get an idea for how indentexpr works, e.g, java.vim.
#Kaz's answer is completely correct, but they don't go all the way to answering the original question. Vim's lispwords config string is a comma-delimited list of words; when any of the words in lispwords is found at the beginning of an S-expression, Vim will change the way that S-expression is indented. In other words, it defines the "standard lisp constructs" to which the OP refers. If you view your current lispwords config with :set lispwords, you'll see "when" is included, but "awhen" is not, resulting in the following indentation:
(when 'this
(process 'this))
(awhen 'this
(process it))
To fix this, simply add "awhen" to the config string somewhere in your config, like so:
set lispwords+=awhen,
The trailing comma isn't strictly necessary, but the default value includes it, and is probably wise in case you or a plugin modifier elsewhere. That would turn the original formatting into this:
(when 'this
(process 'this))
(awhen 'this
(process it))
(Tested on my current installation of Vim 9.0)
Note that, as #Kaz points out, this config string is universal, so if you have different dialects of lisp their indentation will all be controlled by this setting. Vim is pretty good about auto-detecting lisps, but you may need so :set lisp if it doesn't recognize your filetype or dialect.
When learning a new programming language, "read source code" is a common advice received by the experts. However, with such a huge system like emacs, build over decades by many people, it is not so easy for the beginner to figure out which libraries are the best examples of idiomatic Elisp progamming. Therefore I would like to get some recommendations with regards to the following criteria:
idiomatic elisp programming style
adherence to emacs programming guidelines
clever use of the cl-package in accordance to emacs guidelines
clever use of eieio-package
exemplary organisation of a single .el file library
exemplary organisation of a multi-file/multi-package library
any criteria you consider important
Giving the reasons why you recommend certain libraries for auto-didactic studies would certainly be informative to beginners in Emacs lisp programming.
As Trey said, use the elisp from Emacs itself to learn. I usually do one of two things:
1) If I'm trying to find out how to use a specific function, I'll bring up a dired window and do:
% g foobar
where foobar is the name of the function I'm interested in learning how to use. That will mark all of the files that use foobar and then I go and search through them to see how to call it, in what context it's being called, etc.
2) If I'm trying to figure out how to do something, and I know a mode that does something similar, I'll go look at that mode's source code to see how they do it. If you don't know where to start, but you know how to execute what it is you want to do, a handy thing to do is to look it up by key-binding. For example, in a dired buffer, do the following:
C-h k % g
and that will bring up:
% g runs the command dired-mark-files-containing-regexp, which is an
% interactive compiled Lisp function in `dired.el'.
It is bound to % g, <menu-bar> <regexp> <mark-cont>.
(dired-mark-files-containing-regexp regexp &optional marker-char)
Mark all files with contents containing regexp for use in later
commands. A prefix argument means to unmark them instead.
`.' and `..' are never marked.
Clicking on dired.el in the above text (in an emacs buffer) will open up the source code and take you right to that function definition. It's a great way to learn by example.
Don't forget the elisp debugger as a way to see exactly what's going on and following along as the code executes step-by-step. You can mark the code for debugging using edebug-defun and then invoke it as usual, at which point emacs will step you through the code.
The source code I'd recommend would be that of Emacs itself. Start off with the simple stuff (pun intended), and look at other files as you are wont.
M-x find-library simple RET
I think it's self-explanatory as to why Emacs' own lisp code is a good example of Emacs lisp.
I am not a very good at using Emacs, but the feature I would like the most would be some integration with help/documentation for a particular language/API I use at the moment. I would imagine that there would be help displayed in another buffer depending on where I put my cursor while editing.
I wonder if there is a package that does that, even if it would be very simple, just displaying some file based on the keyword. I think there is, but I cannot find it ("help" is a too generic word).
(In particular, I would like to have this help for Common Lisp, but other languages, such as Java or C, could be useful.)
ILISP and SLIME provide several methods for looking up a function; see the Emacs wiki and the SLIME documentation. Or just built into Emacs itself, there are functions like C-h f to get function help or M-x man; both use the text at the point by default. You could pretty easily adapt them to work for another language of your choice.
Assuming you are using SLIME for common-lisp, you can take a look at slime-autodoc-mode.
Sorry, can't help with a generic solution for this.
You can set up the CLHS root for SLIME in your .emacs file:
(setq common-lisp-hyperspec-root "/usr/share/doc/hyperspec/HyperSpec/")
Adjust the path to where you put your HyperSpec.
Then, C-c C-d h with point at a symbol will look it up there in your browser.
One thing you might like to enable is eldoc-mode, by adding (turn-on-eldoc-mode) to your mode hook functions for the appropriate programming modes.
In ElDoc mode, the echo area displays information about a
function or variable in the text where point is. If point is
on a documented variable, it displays the first line of that
variable's doc string. Otherwise it displays the argument list
of the function called in the expression point is on.
This is probably less than you were after, but it still makes a good companion to a fuller-featured contextual help system, and there are a number of programming modes that support it.