Show HN: Emacs4CL: 35 line .emacs to turn Emacs into Common Lisp dev environment | Hacker News Reader

Show HN: Emacs4CL: 35 line .emacs to turn Emacs into Common Lisp dev environment

github.com

80 pointssusam16 comments

I use emacs from time to time, and I consider myself an advanced beginner. I have wrote 2 or 3 times a relatively extensive .emacs and sinked several hours each time playing with its configuration, searching for nifty things, reading other people's blog posts; played with org mode and used eww to geek out a little bit.

This is, in my opinion, the best way to introduce people to light .emacs configuration. To the point that I think there should be 4 or 5 different minimal .emacs such as this one in the main project page.

I understand why there is resistance to enhance the default UX and configuration, and I see the allure of spacemacs, doom, prelude, etc. But it is overkill, and pushes you down a configuration slippery slope that some enjoy too much and others dread, but that kills productivity.

> you learnt that it recommends Emacs and SLIME for development environment and it seemed like a significant additional learning curve for you?

This is the key. This is what pushes a lot of people away from emacs. Just have a "1 click" better default that also serves as a tutorial / example of how to cover 1 simple use case: one for common lisp, another one for clojure, a couple of different ones for python, one for writing a book. Just feed the space between no config and 3h of research. Have something to point out to newbies.

Thank you for sharing your feedback. I agree, completely! If we can have small .emacs files for each of the popular use cases that one can read and understand completely in 10-20 minutes, it would make the journey for new Emacs users easier.

Emacs is a great piece of software. It is highly extensible. Whenever I see someone starting off directly with Spacemacs or Portacle, I feel that an important opportunity to appreciate the extensibility of Emacs is being missed. I have a similar gripe towards the current state of Java programming when I see young engineers starting off with Eclipse or IntelliJ without appreciating how to compile and run programs using the javac and java command line programs. It often bites them back when they have to troubleshoot the program on a production system where there is no IDE and they can only see very long arguments to "java -cp". But I digress here.

My hope with a project like this is that it will help in reducing the allure of readymade fully customized Emacs distributions to some extent and encourage hacking on Emacs itself to customize it to one's own needs, taste, and preferences.

I have been using Emacs for about 5 years. I don't think I will ever graduate from advanced beginner. I learn something new every week. And I would say I have done fairly sophisticated stuff with Emacs.

I also think you are right. I am very grateful I managed to get a preconfigured Emacs to start my journey.

Good question. Perhaps you could refer 'newbies' to https://emacs.zeef.com where they might find out what fits their needs?

I think that is the type of overkill options galore we are trying to avoid.

Is there an easy way to play with different configurations? I rely heavily on Spacemacs, but being able to play with custom minimal configs quickly would be awesome.

I wrote this while teaching Common Lisp. It helps in setting up SLIME, Paredit, etc. in Emacs quickly. The section "Line-by-Line Explanation" of the README at https://github.com/susam/emacs4cl#line-by-line-explanation explains every line of the .emacs file.

It provides a middle ground between manually installing SLIME, Paredit, etc. yourself with M-x package-install commands and installing Portacle that hides away the underlying details of what goes into making Emacs ready for Common Lisp development. It promotes a DIY approach to automate customizing Emacs into a Common Lisp programming environment.

The line-by-line explanation is very handy, thank you for that. I find that one of the hard balances with using Emacs is whether to fully understand everything you put into your conf-files or just accepting some degree of copy-paste.

Thank you for sharing your feedback. Understanding every line of .emacs was indeed the intention behind the line-by-line explanation.

If one does not wish to understand the customizations completely, then Portacle is a great starting point. However, my intention here was to promote a DIY approach to customizing Emacs into a CL dev environment.

I believe that with something like Emacs which is so extensible, it is good to promote customizing it to one's own taste and preferences instead of installing a readymade customized distribution of it. This project is meant to be a quick starter kit to quickly do these customizations without having to spend too much time on it.

Can I suggest you flip the menu and tool bar disable items to start commented-out and suggest people uncomment them when they are comfortable with emacs?

I started using slime as a lifetime vi (and then vim) user, and started using slime because cmucl's REPL was so primitive. I could not have survived without using the menu, and I did pickup some commonly used shortcuts from the hints in the menu.

Beautiful timing - I was just reading Land of Lisp for fun, and I use emacs! Questions: Why do you need SLIME instead of just writing into a buffer and evaluating it? Is SLIME just for REPL-ing? How do you organize a "bigger" project?

Do you mean just evaluate the expressions with C-x C-e or C-M-x? If so, you are right that we don't need the SLIME REPL buffer to do so. That is useful for REPL-ing. But we still need SLIME, so that we can send the expressions we want to evaluate to the Common Lisp implementation (SBCL in this case) via SLIME.

Since the interactive development environment involves an SBCL process running the Swank TCP server which SLIME running in Emacs talks to, I believe SLIME (or something like it) is still required. For example, when we press C-x C-e, even if we are not using the SLIME REPL buffer, we still need SLIME to send the Lisp expression to Swank which would then evaluate it within the SBCL process and send the result back to SLIME, so that Emacs can show the result in its minibuffer.

Interested in knowing your use cases for CL development. Or do you use Clojure?

Either way would be interested in learning where/how you use lisp.

Hey kamaal. Nice to meet you here! :)

Clojure is quite popular at my workplace, however I do use Common Lisp and Scheme for hobby projects.

For example, parts of http://mathb.in/ (parsing, sanitization, spam alert, etc.) are written in Common Lisp. By the way, the code of MathB.in is old, rotting, and not fully open source. If I can find the time for it, I will clean it up, add HTTPS to the website, and release the complete source code soon.

Anything like this, but for vim?

Yes, there are Slimv and Vlime, two very good plugins to provide a SLIME-like environment for Vim. In fact they both rely on Swank TCP server just like SLIME does in Emacs. Slimv, Vlime, and SLIME are all Swank clients that run in the editor, connect to Swank TCP server, send Lisp expressions to Swank for evaluation, receive the results, and display the results in the editor.

I have written about it in detail here: https://susam.in/blog/lisp-in-vim-with-slimv-or-vlime/

Here is a previous discussion about it on Hacker News: https://news.ycombinator.com/item?id=21735148

Reply on news.ycombinator.com