I noticed how SLIME (lisp development package for Emacs) does not come with a frame-source-location function for CLISP, so you can't automagically jump to a source location when inside the debugger. Given that, I figured CLISP users must be using some other IDE (though I guess IDE is a little bit misleading here, maybe they're just using a different Emacs package).
So what IDE/Emacs package are CLISP programmers using?
I think Emacs and SLIME is still what those people use.
Related
First of all, I'm forced to use LispWorks and I would like to know what compiler does it actually use and whether I can use it in CLI. Also in LispWorks there are methods like defsystem etc., are they somehow built in the environment or do they form a package I can actually load (for example) in sbcl REPL?
LispWorks is a commercial Common Lisp implementation that includes its own compiler, debugger, profiler, IDE &c &c.
It comes with its own defsystem macro (not method!) as well as adsf.
I strongly recommend that you consult the documentation that came with the software.
If one has a full LispWorks version (not the Personal Edition), then one can create a version which does not start the IDE by default:
See chapter 12.4.4 Saving a non-windowing image
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.
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.
I'm learning Emacs Lisp and I came across this decade old post saying that at some point Guile (Scheme) will replace Emacs Lisp, or Emacs will be rewritten with Guile.
https://web.archive.org/web/20081201143448/http://sanpietro.red-bean.com/guile/guile/old/3114.html
I was wondering if this is still a possibility, and if developers should be trying to write Elisp with this in mind? The original goal was for Guile to be backwards compatible with Elisp, but it seems like developing Scheme is the better choice.
It should be possible after Guile 2.0 is released to use Guile with Emacs. The current pre-release supports ecmascript as well as scheme and there is apparently an elisp branch also but I haven't looked into it. Once Guile fully supports elisp it shouldn't be too hard to replace the current elisp interpreter with Guile. The real question is whether or not people are going to rewrite their customizations and add-ons in scheme or just continue to use elisp. Regardless, Guile 2.0 should make the possibility of a Guile Emacs much closer to reality than any other development in the past 10 years.
Guile 2.0.0 (released 2011-02-06) supports Emacs Lisp.
You can switch at the repl like so:
scheme#(guile-user)> ,language elisp
Happy hacking with Emacs Lisp! To switch back, type `,L scheme'.
elisp#(guile-user)> (eq 1 2)
$1 = #nil
As to if/when someone is going to do some surgery on Emacs to extract elisp and drop in Guile-in-elisp-mode: the Guile 2.0.2 reference manual suggests this is the plan but it's not ready yet:
We hope that eventually Guile's
implementation of Elisp will be good
enough to replace Emacs' own
implementation of Elisp.
guile and emacs, again - updated Emacs src, using non-hacked Guile, 23 Aug 2009
PS: I was noticing recently that my first
commit to the Emacs source tree
relating to this project was on
1999-08-28, just shy of ten years ago.
I'm not sure if I should celebrate or
be depressed on Friday.
http://lists.gnu.org/archive/html/guile-devel/2009-08/msg00163.html
There have been some interesting discussions on this topic in recent times:
http://lists.gnu.org/archive/html/emacs-devel/2010-04/msg00665.html
http://wingolog.org/archives/2010/04/02/recent-developments-in-guile
I wouldn't worry too much about it. There are a couple of projects to use Guile with Emacs, but I sense that they're not mainline supported. As one of the developers of one of the projects observed, no one will switch unless all their existing elisp runs flawlessly in the new engine, which is a pretty tall task.
Not that it will never happen, it's just been 'in the clouds' for a few years.
Using a VM like parrot seems more interesting for the future than Guile as Parrot VM can handle many different dynamic languages and each language can reuse what has been developed in another language.
The work left to be done is :
adding emacs low-level concepts and functions to Parrot VM (basic elisp types like the buffer type, window, frame...)
creating an elisp language port to Parrot VM.
With such functionalities you could have all legacy elisp code running on Parrot VM without any porting issues, and new code could be developed and reused by any language supported by Parrot VM.