The markdown for CIDER about configuring the CIDER repl starts off by saying:
You can certainly use CIDER without configuring it any further, but here are some ways other folks are adjusting their CIDER experience.
And then list several expressions like (setq nrepl-log-messages t). But where do those expressions need to be written to??
If you're using CIDER (maintained by Bozhidar Batsov), then also check out his own project for setting up emacs called Prelude. It's an alternative to emacs live (as pointed out by Arthur).
I've used both, but switched to Prelude as the CIDER updates tend to be more tightly matched as versions change due to it being the same author.
These examples go in a file called (assuming linux or mac)
~/.emacs.d/init.el
It's also worth knowing about the emacs live starter package which already includes a decently configured cider amongst a bunch of other stuff. I publish my much smaller config here if you're interested in something closer to the defaults or just want more examples.
Another good 'canned' configuration is Purcell's emacs.d. It has a good initial cider and clojure configuration. I also found it was easier to modify/update and (for me anyway) I found it easier to understand, which means easier to fix when something doesn't quite work the way you want. One of the big drawbacks with some of these canned emacs configurations is that you don't get to understand how they work and then when they break, your lost until the author or someone else fixes it. I found Purcell's version was a nice complete setup, but one I was able to easily modify to better fit my needs. Tweaking emacs to fit your needs rather than tweaking yourself to meet the needs of the editor is possibly the greatest strength of emacs and why people end up loving it. Unfortunately, it can also be a PITA when all you want to do is start coding!
See http://www.github.com/purcell/emacs.d.git
Related
I've read many topics regarding this issue, but couldn't get it to an end. I want to be able to code in LISP on Mac, using Emacs and XLispStat.
So far, I've installed Emacs with HomeBrew but I got stuck when installing XLispStat. Can someone detail the steps for doing this? I'll appreciate!
P.S.: This is the required installation for Lisp. If there is something easier to achieve on Mac, I'll try that as well!
I posted a similar answer on this question. Short version: your options for an OS X Lisp environment are LispBox, LispWorks personal (crippleware warning) or Emacs+SLIME via quicklisp/ELPA.
Since your comments imply that you're casting a pretty wide net for workable Common Lisp tools, I'll also mention that CLISP seems to be supported via various OS X ports/package managers and has a fairly comfortable REPL (you can, of course get the same in SBCL with Linedit).
EDIT: As Rainer and Vsevolod mention below, Clozure and MCLIDE also exist. I've used neither myself, so I can't give you any details (though Clozure has been recommended to me on multiple occasions).
Oh, and is there a possibility to write the code is some normal text editor and compile it somehow in the terminal?
Not in the way that I think you mean, but yes, you can write a .lisp file with Sublime or whatever, then sbcl your-file-here.lisp. Note that sbcl your-file-here.lisp starts a running Lisp instance with a REPL, and incurs all the overhead that implies. If you're dead set against Emacs, what you could do is run a REPL separately from your project directory, then just (load "file-you-changed.lisp") or (ql:quickload :your-project-name) every so often.
xlispstat can be compiled on Mac OS 10.8 and works perfectly fine. It needs a couple of little edits for the nitpicking compiler but works perfectly with XQuartz. The people who are telling you to use other systems don't know how well integrated xlispstat is for people doing numerical work.
I am tring to setup an environment for editing clojure in emacs. I'm relatively new to emacs
(only 1 yr) and totally new to clojure (2 weeks). I've found lots of tutorial online about how to setup most of which talk about lein, swank-clojure, slime and nrepl.
It seems that swank-clojure and slime need to work together but swank-clojure is deprecated, so what left is nrepl and some built in lisp repl mode.
I tried inferior lisp mode first because it is the default for clojure-mode and it looks fine to me. But I can't seem tp find a way to switch namespace easily within it.
I then tried emacs-live which is like a kit for emacs newbie that comes with nrepl.
I can then do "nrepl-jack-in" to get a repl even though it is very slow..
It can switch namespace easily with "C-C M-n". Howevre, sometime after switching, a buffer called nrepl error would pop up and won't let me close. I have to force close emacs instead. Also, nrepl does not have much of syntax highlight.
To sum up:
after swank-clojure been deprecated, which repl should I use? slime-repl? nrepl? or others?
I don't know much about clojure now so I'm not sure bwhat feature is important to a repl but it would be nice to at least have syntax highlight and can easily switch between namespace like "C-C M-n" in nrepl, and maybe a debugger.
I heartily recommend nREPL.el for various reasons:
swank-clojure is dead officially, but has been dead for a long while. While it was getting some job done, nothing much has changed or improved in it after its initial inception. The development of swank-clojure required significant expertise in Common Lisp, which Clojure developers generally lack and are unwilling to attain.
clojure-mode 2.0.0 doesn't support swank-clojure + SLIME at all. This move was hugely beneficial to both clojure-mode (which dropped a lot of legacy code) and nrepl.el (which's development pace was increased after the announcement).
nrepl.el is picking up features really FAST. I'm one of its contributors so I should know :-) Recently a lot of cool things like macroexpansion, compilation error highlighting and multiple connections support were added, just to name a few. Many more features and refinements are in the pipeline. nrepl.el's architecture is much simpler than SLIME's and it's much easier for regular Clojure hackers to extend nrepl.el.
SLIME syntax highlighting? The REPL has the same font-locking in both SLIME and nrepl.el and the source buffers are using clojure-mode's font locking. It other words - syntax highlighting's the same in both.
Emacs Live relies on vendorized git submodules and generally the versions of the extensions it ships are lagging behind the upstream a bit. You might want to try as an alternative Emacs Prelude, which also ships with Clojure support, but always uses the latest packages available in MELPA.
There is no slime-repl (outside SLIME that is). At this point it's just swank-clojure + SLIME or nrepl.el. Given that nrepl.el even now implements most of what SLIME has - you'd better get used to using nrepl.el.
Update
nREPL.el was renamed to CIDER after version 0.2.0.
nREPL is probably your best bet. It's the officially suggested replacement for swank-clojure, and it's really easy to set up. (As for SLIME, swank-clojure is SLIME support for Clojure. SWANK is the backend communications channel for SLIME. If you want to use SLIME, you'll want swank-clojure — but of course that's been abandoned in favor of nREPL.)
My experience at the moment is that nrepl.el is somewhat less usuable than SWANK was; it is however picking up fast, both in terms of features and in terms of stability.
Installing Swank is now a bit harder because Clojure-mode has dropped it, so you'd need an older version. So, my advice would be, if you already have a working swank setup, then don't change anything for a couple of months; on the other hand, if you don't have a working setup, go for nrepl because it's going to happen so or later, and Swank is going to involve old versions.
If you end up with nrepl, as I say, it's not perfect yet, but keep the knowledge that, to coin a phrase, things can only get better.
I have come accross vi-style keybindings for Emacs, but my past experience in mixing Lisp based config in .emacs file for enabling various modes etc., hasn't been very pleasant so far.
Read several articles on Emacs + Erlang, but is there something that might be slightly easier for folks familiar mostly with vi (and who are unfamiliar with Lisp)?
The entire set of possibilities (keybindings) is quite overwhelming. Is there a condensed key-map/shortcuts reference specially relevant for Erlang development?
Just use vi and a command line. There are numerous people doing that and it seems to work just fine for them. Even though I use Emacs, it is not the Emacs-erlang interaction I use. Rather I usually just have a separate Erlang shell and then I load modules in that shell with the l() command for interaction.
Answering your questions one by one:
Debugging in Erlang is funny. Firstly, if your program is kept functional you will find that you need much less debugging to figure out what the program does incorrectly because you can simply write small tests for each of the numerous functions to test its correctness. And you can add those into unit-test frameworks.
As soon as you add multiple processes to the mix you will find that traditional debugging doesn't work anymore anyway. The trick is then to trace and assert, and you will need to learn a way to read programs without running them and see where they go with a debugger.
That said, try to execute debugger:start() in an Erlang shell :) There are also the tracing systems and redbug, a 3rd party tool built on top of them (part of the eper suite).
Profiling can be done with one of the 3-4 profilers: cprof, eprof and fprof are all slightly different in scope and in how much impact they have on your program and if they can be run on a production system or not. I tend to use eprof and I have a knob in my program which will spawn an eprof and then attach it at program start.
Try appmon:start() in a shell.
The standard vi-way of browsing large code bases is to create tags-files so you can jump to the definition point of the thing-under-the-cursor. Emacs can do the same. I have a make tags target to create these files so I can easily make jumps around in the source code. When jumping you have a stack of the former jumps so you can return to the point you jumped from later on.
Finally there are tools like xref which can be worked to create call graphs and find odd things in the code. It will require some coding on your part, but it does provide you with the necessary tooling.
Viper mode provides Vi-style keybindings. That's probably the easiest way to start. Enabling a new mode in your .emacs is a pretty fundamental part of using Emacs, so it's a learning hurdle best cleared early!
The Emacs manual contains more detailed information about making individual changes to your keybindings.
You may find Xah's keybinding tutorial helpful, as it provides many examples.
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.
Emacs is the IDE of choice for programming Erlang.
There are plenty of good modes (distel, erlware-mode, the default erlang mode,...), but what are your recommendations for setting up Emacs for professional Erlang development?
Set up erlang-mode as described in the README, and then activate Flymake:
(require 'erlang-flymake)
That gives you highlighting of warnings and errors as you type.
I'd recommend using erlang-mode from the latest Erlang/OTP release (R14A as I type this), regardless of what release you normally use, as it evolves quite rapidly and is now just as good as erlware-mode, IMHO.
If you're using Emacs 24 or later, I recommend installing erlang-mode from MELPA. The 'erlang' package tracks the 'maint' branch of the Erlang/OTP Git repository, so it is always reasonably up-to-date.
If you want more than erlang-mode offers, a possible alternative to Distel is EDTS, the Erlang Development Tool Suite. To quote the readme file:
EDTS is meant to be a able to replace Distel but only provides part of the most
commonly used of Distel's features, specifically the equivalents of
erl-find-module, erl-find-source-under-point, erl-who-calls and
erl-refactor-subfunction. As far as I know, those are the only Distel features
that 98% of people use, but if there is anything from Distel that you are
missing in EDTS, please let me know.
If you are using EDTS, please remove Distel from your configuration, since
running both can create some confusion.
Look onto this article about different packages for work with Erlang from Emacs. I personally use erlware-mode + distel
erlang.el (for indentation and font-locking) and Distel (debugger, M-. etc.) are essential. ESense, I've never used, and I've no idea what the erlware mode does. You may want to use some of the standard Emacs utilities (flymake, interface to version control, and so forth) when writing Erlang.
I've found erlang-mode ok but it doesn't support kerl (which is a useful thing, kinda like rvm for erlang, except it works).
So I started this:
https://github.com/nicferrier/emacs-erlang-extras
which supports multiple erlangs.
I'm intending that it will support rebar as well:
https://github.com/rebar/rebar/wiki/Getting-started
I found out ESense on emacswiki. Might worth a try.