A preview of LightTable 0.5
groups.google.com
groups.google.com
I'm also really excited about the behaviors stuff. It means that the entirety of LT's functionality is described in a datastructure that you could reasonably modify by hand. Here's a gist of default.behaviors: https://gist.github.com/ibdknox/6010853 The :+ is there because it's stored as a diff, which allows other behaviors files to add and remove functionality based on the order they're loaded.
There is one simple change that I would really like to see. In the Instarepl and the normal result that are shown 'in line', the result is just printed and not pretty printed, witch makes it almost useless in case of a complex datastructure. Is there any reason for that? Can I change that?
Im developing something that looks like a boardgame, and seeing the result of a function with a board in it is almost useless, I still have to pprint it to see whats going on.
Again, thanks for the great work and sorry for talking about even more functionality (the existing LightTable is just so cool that I'd love to have it be even more awesome by including my favorite features :-)
After 0.5, my goal is to remove us as a bottleneck as quickly as possible and then who knows what'll happen :D
I'm confused. Emacs embraced this principle almost forty years ago. Would you mind explaining to me what's novel about LightTable's take on this old idea?
Is it "That, But Clojure!"? or "That, But With More Webkit!"? Each of these could be valuable in their own right... Or am I missing something more fundamental?
I think you don't really have to come up with something revolutionary on top of the Emacs philosophy for it to be a very worthwhile pursuit. The things you mention plus the fact that it's as easy to get started as Sublime (or aims to) makes it a fantastic entry point for lots of new people into a tried, true and powerful way of working.
Sadly, it's not open source.
That it's based on technologies, design sensibilities and UI ideas that weren't around "almost forty years ago".
But LightTable has made it possible for me to recommend an editor that has integrated repl feedback and lets them hit the ground running with Clojure when they ask me how they should get started.
Since Lisps are so tool/workflow-dependent, it's just way too easy for a newcomer to dismiss it all after a bad experience because they simply didn't know about electric parens or they never discovered the tight repl feedback loop that makes us so productive. And it makes it frustrating for those of us as well that are trying to convince others to give Lisps a shot since we can't stand over their shoulders.
Sometime I'd like to make a well-planned gif (like that on the homepage of http://www.sublimetext.com/) that gives newcomers a glimpse of a solid workflow to strive for.
Instarepl is an awesome idea.
If someone were to implement an insta-repl as an IntelliJ plugin, or an emacs plugin, what remaining advantages would LT have? Is there something about the architecture of existing IDEs that is incompatible with an insta-repl?
Say I'm writing a medium size webapp, like, say, Gmail, in clojure + clojurescript. I don't understand how integrating my app into LT is going to 10x my productivity, outside of instarepl. Or being able to on-the-fly extend my IDE. Emacs can do that, and its not exactly a feature i can't live without.
It just seems like all the things you're talking about on the list, like [commands, settings, threading models, plugins, UX] are previously solved problems.
I also don't think LightTable's core offering is a huge boost in raw productivity unless your workflow right now is notepad.exe and manual repl reloads. - Just to point out two features from the post: "watchers" (live runtime feedback) and one big extensible datastructure.
Using paredit only for parens-matching feels to me like using only hjkl in vim. While you can use vim this way, you won't fully reap the benefits until you start to use the other movement commands.
Also, I've never done anything in clojure. I expect it to be a similar experience to CL, but the different types of parenthesis might have an effect on using paredit efficiently.
That said, I found that the following mapping really makes a huge difference when working with sexps & evil-mode:
C-l: paredit-forward-slurp-sexp C-k: paredit-backward-barf-sexp C-j: paredit-backward-slurp-sexp C-h: paredit-forward-barf-sexp
Your mileage may vary, of course. I mapped it this way because my fingers dictated it, and it plays well with vim/evil.
As to how to actually use these commands: Try them out on a few sexps, it'll be clear to you pretty soon. Also be sure to check out Emacs Rocks! ep14 (https://www.youtube.com/watch?v=D6h5dFyyUX0), it's well worth the 3:40.
I actually find learning paredit to be very similar to learning vim: You start with almost nothing (maybe hjkl in vim, but even that takes a while to get used to), and slowly add new tricks to your tool belt. Also like with vim, everyone has their own style of using the tools.
Of course, there's a ton of other things in paredit which can improve your efficiency which I haven't added to my muscle-memory yet. It's just that I found barfing/slurping to be the most bang for the buck, so I added them first.
> Lots of things that were blocking the UI no longer are thanks to some magical hackery (given the lack of threads in JS)
I thought WebWorkers where designed to alleviate these kinds of issues. It seems like Webkit supports WebWorkers so I'm surprised they weren't used - anyone know the rationale?
EDIT: I should note that I did start with webworkers for things like auto-complete, but what I'm doing now (spinning up another instance of node) is a lot more powerful and robust. As scary and sad as that may be.
This seems just like hacking around a non-existing problem if JS wasn't being used.
Good luck with Lighttable, all the luck to make it successful.
It's all ClojureScript all the time :) Clojure is only used for evaling Clojure and doing languagy things. Not much has changed since the above post except that behaviors are now added to tags outside of code in .behaviors files.
I did see on one of the mailing lists that you had spiked up an integration with JSHint, and that might make it into LT 0.5. Is that still the case, or have you deferred that for implementing the plugin framework? I ask because I'd like to push it at work, but many of our developers rely on JSHint/SublimeLinter, and it's much nicer having that integrated into our editors.