I have been a vim user for years now and recently started to try out emacs. There are a lot of components available for this editor, like mail clients, IRC clients, etc. All these components need a package manager to update them and to make handling of them easier in general.
On vim there is a plethora of plugin managers (like Vundle or pathogen) and different people use different things.
On the other side, emacs includes package.el with recent versions (which is great to begin with), but there is also el-get and the package.el package list is pretty short.
Should I stick to package.el (and maybe extend the package list with marmalade)? Or do I need el-get for sane package management?
If you use a recent Emacs version then go with package.el. And add MELPA to the repository list.
Also, it is not the case that all "packages" (or libraries) need a package manager to update them and to make handling of them easier in general. There is a world of useful Emacs Lisp code out there that is not "packaged" and uploaded to a package.el repository.
More importantly, regardless of whether you use package.el to retrieve and "install" packages, you should learn the basics of loading, byte-compiling, and using Emacs Lisp code. Don't just use package.el blindly, without understanding something about Lisp code.
The basics of "installing" Lisp code manually include the following:
In general, you will want to byte-compile libraries that you use, for better performance. Keep in mind this caveat, if you do so:
1a. Load any source files (*.el) that define Lisp macros that are needed by any of the other Lisp libraries you use.
1b. Then byte-compile (the macro-defining libraries and) the libraries that use the macro-defining libraries. This is important. It is likely that the latest versions of the macro-using libraries need the latest versions of the macros, and if you compile them without having first loaded the latest macro definitions then you are asking for trouble.
Put any libraries you use in a directory that is in your load-path. Said differently: set variable load-path in your init file (~/.emacs) to a value that includes all directories containing Lisp code that you use.
Generally, you want to use (require 'foo) in your own code (e.g. in your init file), to load library foo.
However, #3 works only if library foo (file foo.el) actually provides feature foo: (provide 'foo). If it does not, you can use (load-library "foo") instead.
(Note the difference here between using 'foo and "foo": the first refers to feature foo; the second refers to files foo.el and foo.elc.
Finally, before you try to use a library, do yourself a favor and take a look at the Commentary section of the file header. Often it tells you important things about using the library. And even when it does not say something terribly important it might say something useful (e.g. a tip or two).
I mention 1-5 because I see too many (no, not many, but too many) new users just "installing" stuff using a package manager and never taking a look at what the code they are installing is all about: what it is for, how to use it, etc. If there is something in the Commentary then read it; the library author put it there to help you.
Beyond that, have fun!
Related
I have developed some Common Lisp functions in a couple of Lisp source files that I'd like easily available to other functions I write, or make available on github if I think they'd be useful for someone else. For now, I've just been putting them in some pre-defined folder and using (require "/path/to/my/modules/module.lisp").
I'm wanting to understand what is the correct (canonical Lisp) way of defining Lisp library of modules. And the second part of the question is how to use them (whether I've defined them, or whether I've obtained one from someone else).
I've been reading a lot about defpackage and defsystem and asdf. But everything I've read seems to focus on some specific corner of the universe of this task. I'm having a lot of trouble seeing the big picture of custom module creation, deployment, and use. So assuming I have the Lisp environment in front of me (CLISP or SBCL) and one or more .lisp files I'd like to make a package or library out of, is there a document somewhere that explains what steps are required to do that? It's probably something I've already read, but didn't track due to not understanding the context. What I've read about ASDF seems functionally to be what I'm after, but I'm left not understanding whether ASDF is my only option, or whether it just happens to be a de facto standard and what most other people use, or whatever. I played with it a bit in SBCL and wasn't sure I was using it right, and didn't see info on how to set it up in CLISP. So I'm wanting to understand what is the up-the-middle, vanilla approach to this task.
I know this is a big, sloppy set of sub-questions. Again, if there are some good references to look at, I can read. I'm just having some trouble getting a big picture view of how this is supposed to work, and whether there is any "best" approach, or whether, in Lisp, it's a bit of a "Wild West" choose-the-library-manager-you like approach. I did the Google thing and read anything that looked relevant, but my brain is spinning from all of it.
Thanks.
A system is a collection of files and sub-systems. One can compile or load such a system. There are also other operations possible. It keeps track of dependencies and tries to do a minimal amount of work.
If you are using SBCL and CLISP, then ASDF is the tool to choose. See http://www.cliki.net/asdf
ASDF provides, amongst other things, a DEFSYSTEM macro to describe such systems.
Don't use PROVIDE/ REQUIRE- unless you know what you are doing. ASDF is the way to go.
To publish your code and make it easily loadable by others then use QUICKLISP. See: http://www.quicklisp.org/beta/
A package in Common Lisp is not like a package in most other senses. It's not an archive of list files, but more like what most other languages would call a module or namespace that lets you select which symbols (names) from your code you want to show to the outside world of code.
If you just have one file for your little library, you can just distribute that. If you have multiple files, that where a tool like ASDF comes in to make sure, for example, that files defining macros are loaded before the files that use those macros.
Here are some good resources for you to look at, both chapters from Practical Common Lisp:
21. Programming in the Large: Packages and Symbols: This will give you a much better sense of what packages are and how and why to use them.
32. Conclusion: What's Next?: The "Delivering Applications" section has some good resources on this stuff in general, and has some mention of ASDF.
ASDF and Quicklisp are useful tools, that is an established fact. However, I would like to give an alternative point of view on the concept of "library" as it is discussed on previous answers
ASDF is designed to automate the compilation and loading of a set of source files. It is to CL what make is to Unix. It is perfectly valid to write and distribute a program without make just as it is fine to write a program in CL that does not use ASDF.
If your project is simple enough, it is sufficient to provide a file (e.g. load.lisp) that contains the statements to load the dependent files of your project in the right order. Therefore ASDF is not involved in the concept of a library.
In a provocative way, I would say that the canonical way of defining a module in CL is to use the defpackage declaration because it is the language unit that allows a programmer to isolate his/her declarations from those of someone else.
Then is the question of how to make it available to others. If you write portable CL code, then ASDF is the most popular system definition facility and you should use it. If you want to make it easier for others to obtain, then Quicklisp is the tool that changed the face of CL in the last few years.
Finally I would like to add that neither ASDF nor Quicklisp are standards, they are tools (which does not remove to their usefulness). ANSI Common Lisp is a standard and I would love to see a system definition standardized in CL.
Yes, ASDF is a de facto standard, and Quicklisp is another standard.
From Lisp's viewpoint what you want is to define one or several namespaces (packages). This is regulated by the ANSI standard. From your code's viewpoint you want to arrange a bunch of files so that they became a whole and somehow provide that packages. This is where ASDF plugs in. And Quicklisp allows you to manage ASDF systems in the easiest way concievable. You can both download a lot of libraries from Quicklisp's repository and manage your local systems creating symlinks in the quicklisp/local-project folder.
If you have Quicklisp installed, you can type
(ql:quickload :cl-fad)
at the REPL and thus load the CL-FAD library (possibly downloading it); then the packages CL-FAD and PATH become available, you forget about ASDF-systems and stick with the logic of packages.
A good idea would be to take a look at asd-files of several projects downloaded with Quicklisp.
I setup my own libraries, that I use often, using ASDF system definitions and linking them into the local-projects (or similar named) folder of Quicklisp. That allows me to load them using quicklisp like any published package.
If you want to learn how to setup such an ASDF system, I would suggest installing Quicklisp (which for once is really easy, when it comes to installing 'unfinished' software from the internet), quickload a well known package or two and look at its .asd file, consulting the documentation when in doubt.
This way, you have your libraries already setup to be published like most of the well known CommonLisp packages out there.
I use auto-completion mode which is not inbuilt. good but not the best IMO. So I was wondering is there inbuilt generic plugins for completion in emacs like you see in IDEs.
to name,
dabbrev
hippie expansion
I think these two are different from auto-completion mode kind which I am looking for.
EDIT:
I like to extend one of any completion system to support a scripting language which I use regularly for scientific data visualization.
There is CEDET package in GNU Emacs starting from version 23, but it slightly outdated, and it's better to use CEDET from its repository. I have an article on setting and use CEDET from repository.
Why don't you want to use external packages? With new packaging system in GNU Emacs (package.el) and with things, like el-get, it's very easy to install new packages into GNU Emacs...
CEDET's autocompletion is the only drop-down completion package provided in core Emacs. The core in-place completion packages are hippie-expand and dabbrev.
The primary non-core packages which provide drop-down completion are auto-complete and company; the former appears to be the most popular these days.
There's also anything, which is an interactive completion package. While it doesn't provide drop-down completion at the cursor position, the way it works is really rather nice, so it's worth investigating.
With a bit of tweaking, dabbrev and hippie-expand can be a lot more effective than you might expect, but if you want something more visual and interactive, my advice is to look beyond the core packages and go for auto-complete or perhaps anything.
(For what it's worth, I use both hippie-expand and auto-complete myself.)
As a C programmer I tried http://cx4a.org/software/gccsense.
I read an interview where the CEDET author said that this is actually better because it hooks directly into gcc. However its quite a hassle to install gccsense because I had to compile a modified gcc. Once this package is included in distributions I would use it.
You may also want to try out predictive mode. While not exactly a code completion package, it comes close to it by predicting your frequently used words, which in a coding platform is definitely a limited vocabulary.
http://www.dr-qubit.org/emacs.php
The emacs wiki has a good explanation too.
http://www.emacswiki.org/emacs/PredictiveMode
Emacs has this seemingly very nice facility for building autoload files based on magic source code comments ("autoload cookies") of the form ;;;###autoload, which are to be placed on lines by themselves immediately above each definition to be autoloaded; see (elisp)Autoload.
This would seem to be an ideal tool for maintaining autoloads for those little one-file packages that Emacs users inevitably end up installing in their profiles. There's just one small problem: this facility (in GNU Emacs, anyway) appears to be almost entirely focused on generating the loaddefs.el file for Emacs itself, with very little (if any) concession to other uses.
This doesn't stop largish packages from using the autoloads.el machinery to build their own autoload files, but those that I've looked at have a fair bit of rather hairy code devoted to making it do what is needed, though some of the hairiness might be due to GNU Emacs/XEmacs divergence.
(I think XEmacs is a bit better on this front, probably due at least in part to the fact that its official package system uses this machinery to make separate autoload files for each package. Hopefully GNU Emacs' inclusion of the ELPA package system, which also uses this machinery, leads to similar improvements on their side.)
So, my question for you is:
How should I maintain an autoload file for all .el files in a directory, assuming they have all the necessary ;;;###autoload comments (autoload cookies) in place already?
[Hmm. block quotes look a lot coolor on tex.SE...]
I'm currently using GNU Emacs 23.2.1, though the farther back an answer works, the better. (For that matter, it'd be nice if it would also work with XEmacs.)
I'm on Windows, but have MSYS installed alongside Emacs so sh/bash scripts will probably be fine as long as they don't call anything terribly exotic.
[I'm not entirely certain this doesn't belong on superuser rather than on SO. If there is already a package that can take care of this with only a small amount of configuration, it probably does; on the other hand if (as I suspect) there are only fairly rough snippets of code that might require a good deal of direct changes, I think it probably belongs here on SO.]
Check out this answer to "emacs23 / elisp: how to properly autoload this library?".
In summary, you dump all the packages in a particular directory, and create a package of your own update-auto-loads.el, which builds the loaddefs.el and provides a function you can regularly run to rebuild the loaddefs.el file whenever you want.
In 2017, you don't have to maintain it yourself. Instead, you can use a modern package manager such as straight.el which is specifically designed to take care of this (as well as many other things) for you.
You could use package.el instead of straight.el, but package.el has a number of serious problems, and a particularly relevant one is that it's very awkward to get package.el to load a local package you've written yourself, and in particular package.el has absolutely no support for making modifications to a package once it's been installed.
You could use other package managers, as well. I wrote an extensive section comparing straight.el to other package managers.
Here is the back story skip to the bottom if you do not care and only want to see the question.
So I have been playing around in LISP for a little while. Some basic functions, some classes ,and file IO. When I run across this article:
http://www.adampetersen.se/articles/lispweb.htm
And I am excited to try and use lisp for a web application. I go and download the packages, but for the life of me do not know how to load them into my Allegro IDE.
Hmm... ok, well the hunchentoot site says a lot of the basic packages are in LispWorks. So I download that. Still not sure how to get the source for the packages that I downloaded into these IDEs. They seem to have binaries of the packages?
Oh well maybe ill switch to my ubuntu server and apt-get all the packages and setup slime (i have not used it before because I just wanted to learn lisp. Learning emacs and lisp at the same time seemed real daunting). I apt get all the packages needed and load up slime and again same problem there aren't available.
I dig around some more and see this program called ASDF. It looks like ASDF is some kind of package builder for lisp? I don't know it seems confusing. I'm about to give up at this point.
If you are still reading this here is my question.
1. How do I load the source for these packages into my lisp environment. trying to learn lisp hasn't been too hard but the information about the environments has been sparse. Do I need to build the packages I download with ASDF.
2. Is there a simple way for someone to just get up and running in lisp without having to speed a large amount of time upfront learning all the tools?
Hmm... ok, well the hunchentoot site
says a lot of the basic packages are
in LispWorks. So I download that.
This just means that the author has written a lot of Lispworks-specific code in Hunchentoot. It does not mean that Hunchentoot only works on Lispworks.
Still not sure how to get the source for the packages that I downloaded into these IDEs.
You need to use ASDF.
They seem to have binaries of the packages?
That's unlikely.
Oh well maybe ill switch to my ubuntu server and apt-get all the packages and setup slime > (i have not used it before because I just wanted to learn lisp. Learning emacs and lisp
at the same time seemed real daunting).
Don't do it then. You don't need to use Emacs or Slime.
I apt get all the packages needed and load up slime and again same problem there aren't
available.
For quick results try clbuild: http://common-lisp.net/project/clbuild/
I dig around some more and see this program called ASDF. It looks like ASDF is some
kind of package builder for lisp? I don't know it seems confusing.
ASDF is a bit like a Makefile for Common Lisp applications.
I'm about to give up at this point.
That's about the worst thing you could so (at this or any other point). I'm glad you have decided to post your problems here instead.
How do I load the source for these packages into my lisp environment.
trying to learn lisp hasn't been too hard but the information about the
environments has been sparse. Do I need to build the packages I download with ASDF.
clbuild should give you all you need, but here are some hints if you don't want to use it:
CLISP, SBCL: ASDF is part of your Lisp. Run (require :asdf). Lispworks, Allegro: you need to download and load ASDF. Save asdf.lisp somewhere then run (load "/path/to/asdf.lisp").
For every library/application ("system" in ASDF speak) you need to download und unpack it to some place. Repeat until all dependencies are satisfied. Note down these places (directories).
For every place from step #2 add the place to the ASDF registry: (push "/path/to/dir/" asdf:*central-registry*). Don't forget the trailing slash.
Load the system using (asdf:oos 'asdf:load-op :system-name).
Is there a simple way for someone to just get up and running in lisp without having to speed a large amount of time upfront learning all the tools?
See above -- use clbuild.
The quickest way in Ubuntu is to use the packages included in that distribution. It is "ok" if you just want to try some things, but these versions are often comparatively old. I would recommend the packages sbcl and slime. If you don't know emacs yet, you can get into that quite fast through its built-in tutorial (C-h t (press Control-h, release, then press t)).
You can then start emacs, start slime (through M-x slime), open a lisp file (C-x C-f ~/lisp/first-try.lisp), and you're ready to go. As a tutorial for Lisp, I think that Practical Common Lisp is a very nice book, and it's freely available.
Now, when you have come to like Lisp, you might want more up to date packages. I would recommend to use clbuild for that (see the link for further information, including FAQ). You can then also build a new sbcl (bootstrapped by the distribution's version).
ASDF, by the way, is only a system definition facility. It doesn't know how to download packages, it only knows how to load systems into a running Lisp image. In other words, it just solves the problem of automatically loading the multiple files that some "system" (library) consists of in the right order. The newest versions allow loading a package (after it is installed, e.g. through clbuild) with a simple
(asdf:load-sys 'foo)
Older versions show ASDF's internal concept of operations:
(asdf:operate 'asdf:load-op 'foo)
The above load-sys is a shorthand for this common use case. Further information (one could say, all you need to know about it) is at the ASDF Getting Started guide. ASDF is also included in SBCL.
When you load a source file, it is automatically compiled (producing .fasl files (fast-load)) so that loading is much faster next time.
Probably one of the fastest ways to get started is to use Lisp in a Box (or a spinoff like LispBox). These are full sets of everything you need.
You could also try the Lisp Resource Kit, which is a bootable CDROM with Lisp tools and documentation, all already set up for you. Just put it into your CDROM drive and boot!
All of these answers are good, however they've become a little outdated with the new popularity of Quicklisp. Very loosely speaking, quicklisp is the package manager to asdf's make. Once Quicklisp is installed on a system, you can use (ql:quickload "name of lisp library") to load that library into your lisp environment, including downloading it and any of its dependencies if required. For example, to download, install, and load Hunchentoot and all of its dependencies, use (ql:quickload "hunchentoot"). In later lisp sessions, calling (ql:quickload "hunchentoot") again will simply load the version already downloaded and installed, making ql:quickload a simple way to load any library available locally or remotely. To install Quicklisp, I refer you to quicklisp.org.
More detailed explanation
Lisp works a little differently from other languages when it comes to libraries. The first thing to know is that the language itself provides almost no library functionality- it has load (which goes through and runs each line in a file as if you'd typed them at the REPL) and compile-file (which creates a "fast load" file, a precompiled version of the file which loads and can perform much faster). Using just what the core language provides, in order to load a library you have to go to each of its files and load it (or (load (compile-file "filename")) it, for better load speed/performance). This got tedious, so a variety of libraries were created for managing the loading of libraries, and at the moment asdf is king (so much so that many lisp implementations actually bundle it). In asdf terminology, libraries are called "systems" and .asdf files describe all of the metadata involved in loading them- the systems they depend on and what order to load files in, mostly, but they still can get quite complex. Quicklisp, then, sits on top of asdf. Basically, when asdf discovers that it cannot locate a system, Quicklisp steps in and checks to see if that system is available from one of Quicklisp's online repositories, and if so downloads it and has asdf continue on its way. ql:quickload is basically just a wrapper around the asdf machinery for loading a system that enables quicklisp to help out as needed.
Can Emacs support the concept of projects? That would be where several configuration options varies depending on what project you are working on.
Yes, please look to the EDE package from CEDET library
Check out the project-local-variables plugin. I haven't used it personally, but I've seen it mentioned in the Rinari-mode documentation for scoping down a find-file-in-project function.
You generally wouldn't expect emacs to know about differences in build requirements---you let the build system (make or whatever) take care of that. To handle different coding standard define local yourproject.el files to set variables, load and unload local modes, etc... (use M-x load-file to run it).
To be pedantic, Emacs can support anything, being as it's a Lisp language runtime which so happens to have an editor on top of it.
To be specific, some addons for Emacs support Projects, such as the JDEE.
Well, as you can see there are several packages to do this.
You might like this approach:
http://blog.jrock.us/articles/eproject.pod
I just read it today.
Dude, as mentioned in another answer, EMACS can do anything. That said, let's expand a little on what a "project" means in this context. In most IDE's, like Eclipse, Netbeans, Visual Studio, or Xcode, "project" means two things: a file layout for the pieces that belong together, and instructions to the build system to build the thing composed of those pieces.
In EMACS, you have complete control of these things, but how they work together is dependent on both the target environment -- Lisp, Java, C/C++ and so on. Lisp is supported by SLIME, Java by the JDEE, C/C++ by the built in modes and a bunch of conventions; version control is also built in if you want to use it.
In most cases, the build details don't really affect the editor itself much, but you can specialize the behavior for specific files using either modelines, or local variables. JDEE has a specific "project" notion built in.
What languages and environments are you trying to work with?