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.
> It means that the entirety of LT's functionality is described in a datastructure that you could reasonably modify by hand.
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?
How about, "Turtles all the way down just like Emacs?"
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.
>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?
That it's based on technologies, design sensibilities and UI ideas that weren't around "almost forty years ago".
I really love the philosophy of LightTable and will make a serious attempt with 0.5 to make it part of my standard dev workflow, but I keep wishing it had a single-stepping debugger built in, especially for clojure code. Am I doing something wrong that I keep depending on such an old-timey feature?
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 :-)
I'm not sure I'll do it, but that's my answer for almost everything at this point. Ultimately this is why I'm taking the strategy I am - plugins will be able to do anything I can do quickly and efficiently. Integrating a step-wise debugger won't be a completely trivial amount of work, but I'd be surprised if it took more than a few days and it's something anyone should be able to do :)
After 0.5, my goal is to remove us as a bottleneck as quickly as possible and then who knows what'll happen :D
Nice you are probebly reading this, I'll ask here. I have started to use LT for some clojure/clojure script development and real like it. As much as you can like something that new, but I really belive it will replace everything, not just for development but also for 'normal' stuff.
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.
It's something I was going to work on for 0.5. I do a fair number of things to make lazy seqs not blow everything up and pprinting will force lazy seqs to be realized causing all sorts of nastiness. There may be some decent middle ground in there somewhere though.
Ah, I see how this could be a problem. Maybe show it the like now, and then if you click on it one could pprint it. Does print-length work with pprint?
Fipp is awesome and I'd love to use it, but there doesn't appear to be a clojurescript implementation of finger trees and last I knew he hadn't solved the print-length/depth problem either.
Initially it will likely be easier to write plugins in ClojureScript, but there's nothing preventing JS ones from being written. Before the plugin stuff goes completely public, I'll probably write a little JS shim layer that makes it a bit more natural.
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.