[erlang-questions] Erlang emacs workflow question
Tue Jun 28 20:38:52 CEST 2011
Can you post your makefile for example?
I'm currently spinning releases for every dev change and if you've got
a better way I'm dying to hear!
On Tue, Jun 28, 2011 at 8:33 AM, Garrett Smith <> wrote:
> On Thu, May 12, 2011 at 12:39 PM, Mike Oxford <> wrote:
>> Write some code
>> C-c C-k to make sure it compiles
>> Spin a release (using rebar) in another window
>> Run the code in another window
>> Is there a better/more streamlined way to do this, all from within emacs (I
>> have erl running in another window.)
> It's a bit more elaborate than what you're asking for, but I use Emacs
> and an Erlang shell under tmux, which provides a pretty nice workflow.
> Emacs is in tmux window 0, use for editing and compiling. I have a key
> binding for 'compile' (C-x C-m) and use a makefile in the src
> directory. This gives me a quick way to compile the app and use C-x ~
> to visit errors/warnings.
> I run erl in tmux window 1 and always keep it running. I have a
> 'shell' target in my makefile that handles setting ERL_LIBS (or
> explicit path settings) and starts any apps that I typically work with
> under dev.
> In particular, and very importantly, I always start Mochiweb's
> reloader module (which would be a great addition to core Erlang!).
> This will watch loaded modules for changes and automatically reload
> them. So when I compile from Emacs and switch over to the erl shell,
> all my latest changes are available.
> This "long running" shell lets me play around, test, whatever as I
> modify code in Emacs. It's a more ad hoc mode than re-running tests
> from a newly started Erlang VM. It also gives you a feel for how
> Erlang apps can indeed "run forever" with loosely coupled components
> that can be restarted, reloaded, corrupted, repaired, etc.
> While I know it's a common work flow, I'm not a fan of generating
> releases and restarting erl for routine dev changes. I actually can't
> imagine doing that, given how seamless the 'reloader' workflow is.
> Btw, tmux in this case is optional -- you could do the same thing in
> Emacs. I like (strike that, love) tmux because it does for shell
> sessions what Emacs does for text files. If you happen to do a lot of
> dev on remote servers over ssh, tmux is a life saver if you lose your
More information about the erlang-questions