Basically, you can hook Emacs up to the browser and interact with the page directly without having to refresh it. You can do some really cool stuff as shown at the end of the screencast.
All this without having to sacrifice the inherent editing and programming power of Emacs.
In the screencast, code gets reevaluated using a key command (C-x C-e), just like Emacs does for lisp. However, since Emacs is extremely programmable, it would be pretty easy to set it up to run any new code as soon as you finished modifying it, or on a timer, or however you like.
As an aside, the rest of the Emacs Rocks! videos are also worth watching--they make it very clear why people really like Emacs. For example, episode 12 (about editing HTML with Emacs) not only shows how powerful some of the default modes are, but also how easy it is to customize commands.
Live editing (or "hot swapping" as it's called in the article) is my main, long-term objective. I can only devote so much time to it, and it's not as far along as I would like it to be. But, getting there... do take a look at the other branch if you're curious.
Hot swapping is a prerequisite, but not sufficient for live editing (or live programming as I call it). You also need to ensure that you can have responsive feedback about your edit via framework or programming model affordances.
This is just hot swapping (as they claim), it's been around since before smalltalk.
Good point, I shouldn't have lumped together the two concepts. Thanks for clarifying.
I would add that this all seems to be in pretty early stages on the WebKit side, too. For example, I had hoped that when the debugger hits a breakpoint, and you hot-swap code in the current call frame and restart the frame, what would happen is what you'd expect to happen, alas--at least with Chome Canary--this doesn't seem to work yet.
So yes, you're right that true live editing is not around the corner, with or without Kite. I'm just aiming to get as close as possible.
This is stated most eloquently in Christopher Hancock's dissertation [1]:
> And yet, if making a live programming environment were simply a matter of adding “continuous feedback,” there would surely be many more live programming languages than we now have. As a thought experiment, imagine taking Logo (or Java, or BASIC, or LISP) as is, and attempting to build a live programming environment around it. Some parts of the problem are hard but solvable, e.g. keeping track of which pieces of code have been successfully parsed and are ready to run, and which ones haven’t. Others just don’t make sense: what does it mean for a line of Java or C, say a = a + 1, to start working as soon as I put it in? Perhaps I could test the line right away—many programming environments allow that. But the line doesn’t make much sense in isolation, and in the context of the whole program, it probably isn’t time to run it. [end quote]
Light Table is interesting in this regards, though I'm not sure what they are claiming yet. I (and others like Jonathan Edwards) think we'll have to accept significant changes in our programming models to achieve true live programming, that we can't just tack it on transparently to our existing stack, e.g. by snapping back a few stack frames on an edit.
Highly interesting, thanks for sharing your thoughts and the link to that paper.
Really I'm just trying to improve turnaround time when developing Web apps. I think that between full-page reloads and research into better programming models, there's some middle ground worth exploring. I guess I shouldn't be using the term "live editing" for that, though.
Surely it is worth exploring. There are many points on the "make programming more interactive" spectrum, and hot swapping is something that we still can't get right in our mainstream programming environments! But live programming is something much more ambitious (and much more difficult to achieve) than hot swapping. Its basically what we eventually want even if we have to make many smaller steps (hot swapping) to get there.
I used Aquamacs for a while, but I found GNU emacs had everything I needed- clipboard integration, cmd-s and so on. Out of curiosity, what do you want that's more OS X-y?
A bit off-topic, but I'm somewhat surprised that this is news. Not because it's not awesome, but that so many people seem to have been unaware of this feature. It makes me wonder how many things I know that I take for granted. How many simple things that I do, that I use, that others would find amazing.
Like CTRL-A in bash (I'd mentioned it in passing, and someone was excited to find out about it); ESC-. in bash as well to insert the last argument, incredibly handy for quickly injecting long paths. I did a talk on tmux at work, and it went over extremely well with those who attended, much beter then expected.
I guess the reason I think this way is I imagine I'm the dumbest person around, so I assume if I know something, everyone else must. And if I mention it, a part of me feels like I'll be exposing some weakness. It's stupid of me to think that way. It's a personal failing, I know. Even knowing it though won't change my way of thinking.
When using this feature, be aware that the saved changes stick around indefinitely and can override updated JS being served by the host. I've had this one bite me repeatedly even though I never use the live editing feature due to the thoroughly broken keyboard focus implementation in Chrome. :/
IIRC if you do a force reload (right click the reload button with the inspector open) that bypasses cache, that should reliably destroy any local edits.
It would be even better if it worked the other way around. Tell Chrome where my files are and it would watch them for changes. That way I can use my favourite editor/IDE and get the features you described.
That's pretty awesome, I don't know if the two actions are related but if they are, it's really good to see the Chrome team:
1) Taking suggestions from sources like this so easily ("Hey, look what I just read on HN, we should do that!")
2) Implementing a change so quickly - most companies as large as Google can take days to approve a change in a product as widely used as Chrome. (I am aware that most users won't use the developer tools, but with any added functionality comes an added unforeseen bug.)
I wrote an extension that does both live reload and saving from devtools: http://tin.cr. To address the comment below with regard to extensions not working, it's Chrome's fault. It will fail to hotswap JavaScript occasionally and it doesn't communicate the reason to the user or extensions built on top of it.
Speaking from experience, hot swapping JS sounds much better than it actually is in practice. First, as mentioned above it randomly fails with no explanation from Chrome. Also, I find a lot of code I want to hotswap runs on DOM ready and assumes that the page has just been loaded.
On the other hand, CSS hotswapping in Chrome works really well.
"I find a lot of code I want to hotswap runs on DOM ready and assumes that the page has just been loaded."
Maybe it would be possible to put all your "setup" code into a single myscript.load() function and then when you've edited your js in chrome devtools, then call myscript.load() in the console to reboot all your DOM events and so on.
Just an idea, completely not tested.
P.S. Just tried your extension using vim to edit a Sass file, while compass watch is running, and your extension is watching my CSS output directory. Awesome to see changes in vim almost immediately appear in my browser!
I think your extension was one of the few I tried. Sorry for the slight bashing, I appreciate what you're doing and I'd actually like to help you out in any way I can!
Have you tried getting in touch with Chrome developers? Printing out info when hot swapping failed would really make you extension useful.
Weirdly, I haven't noticed failures while using the Chrome editor. Might be that I just haven't logged enough hours with it yet, but so far it was working flawlessly.
I couldn't find one that worked consistently. Sometimes they detected source code changes and did a hot swap successfully, but other times something went wrong.
And because of this inconsistency I never knew whether I changed the wrong peace of code or the extension didn't do it's job thus making the extension pretty useless...
Keep in mind that if you use Chrome's feature of reformatting minified JavaScript, it will not let you edit it. You can only edit the JavaScript in it's "natural" state.
It's true it isn't proper news. But it still seems there are a lot of developers out there that didn't know about this feature and this is definitely news to them.
I don't understand how someone can link to his 'Inventing on Principle" video in the second paragraph of their web page and fail to comprehend the material it covers in just the first 6 minutes of its running time. Note, that Bret Victor despises the term 'live-coding' as a description of this work.
A notepad will persist your code and allow you to edit it easily, including newlines and tabs. It will also allow you to undo/redo. Try FireBug to see what I mean.
Yes, in Chrome you can technically hit "Shift+Enter" anytime you want a line break, but you cannot tab. Regardless your script will disappear after you execute it. Yes, you can make what you just typed reappear by hitting the up arrow, but then it's again difficult to edit it. It also does not support undo/redo.
Now we just need a way to connect sublime text 2 or 3 directly to the chrome-console, so that when you edit files in sublime, they are magically used instantly without page refresh - now that would be bliss....
Running Chrome 24.0.1312.57 (stable channel) on OS X.
The files in Sources tab become editable if I turn "pretty print" option on and then immediately off. But afterwards, whatever changes I make have no effect on what's displayed. Even if I right click and "save" my changes, the original unmodified source is saved (despite there being something edited in the Sources tab)...
This would be more easily possible when this[1] issue is fixed. At the moment only one debugger client can be connected at a time. So only one of chrome devtools, or a third party client can be connected.
This is a problem because your IDE/text editor could have support(native or via a plugin) for the chrome debugger protocol[2] and update the js as you edit it, but you can't have the debugger open at the same time.
I wonder if the Firefox architecture would allow for hot swapping. V8 throws everything away after compiling - it goes all the way back and reparses the source if it needs to recompile anything. So I'm guessing it's already relatively well prepared for human-edited source code.
It's good. Iteration cycles drop like mad when you can do hot-swapping.
Now of course Lisp dialects had that 50 years ago or so and... Any modern which can run JavaScript can run ClojureScript and hence already had hot-swapping ; )
But it's good to see non-Lispers getting there eventually ; )
And recently from the settings menu (low right corner) it also can change the user agent, reported resolution, the geo-location and emulate touch events. Chrome inspector is really something else.
[1]: http://emacsrocks.com/e11.html
Basically, you can hook Emacs up to the browser and interact with the page directly without having to refresh it. You can do some really cool stuff as shown at the end of the screencast.
All this without having to sacrifice the inherent editing and programming power of Emacs.
In the screencast, code gets reevaluated using a key command (C-x C-e), just like Emacs does for lisp. However, since Emacs is extremely programmable, it would be pretty easy to set it up to run any new code as soon as you finished modifying it, or on a timer, or however you like.
As an aside, the rest of the Emacs Rocks! videos are also worth watching--they make it very clear why people really like Emacs. For example, episode 12 (about editing HTML with Emacs) not only shows how powerful some of the default modes are, but also how easy it is to customize commands.