I don't quite get how node.js comes into play here. I've seen lots of blog posts about it, but never used it. It seems to be about network programming. Indeed, the node website says "Node's goal is to provide an easy way to build scalable network programs."
Would someone enlighten me what the motivation is to use it as an editor's scripting environment?
node.js is a way to get people to click on an article. If it said "new editor" no one would care. But the buzzword fashionable 'node.js' means people will assume it's earth changingly awesome.
Comments like the parent make me sad. It could be summed up as "node.js, damn hipsters." It's just another form of fanboyism, except negative.
There are not many good, scriptable editors for programmers. Actually, I would consider only 3 for serious use: Emacs, Vim and TextMate. Of these, only one has really good integration with OS X.
If I was considering switching editors, the language that is used to extend it would be one of the most important factors (I love Emacs, but Emacs Lisp is seriously broken). The fact that Kod uses node.js means two things:
1) It's JavaScript, so it's high level, has nice semantics and it's extremely popular;
2) It uses a reasonably fast dialect of JS, and has the necessary infrastructure, like CommonJS modules and access to the filesystem.
So, Node.js is the thing that makes this topic actually hacker-news-worthy.
I don't really see the language used to script an editor as being really important. But then I've never considered an editor as being that important. As long as it works any will do.
Don't get me wrong, I wasn't trying to beat this project down, I'm just pointing out that 'node.js' carries a "wow it must be awesome" weighting at the moment.
Give it a couple of years and node.js will be old and boring and there'll be a new fashionable language everyone has to jump on.
I would have whole-heartedly agreed with you right up until a couple weeks ago. Since then I've taken note of the wave of activity happening and really dug in. There are a lot of issues still with Javascript and it's history, but there are some compelling things happening and I think we need to start paying attention and keep an open mind.
I suspect that next fashionable thing will be Go btw...
Node.js is a universal environment much like Python or Ruby, but runs the highly performant V8 JavaScript virtual machine. The choice of JavaScript is simple — many people know it and it's the future of scripting. Also, I'm active in the core dev of Node.js which makes it extra fun to use.
Performant[1] (comparative more performant, superlative most performant): (jargon, chiefly computing) Capable of or characterized by an adequate or excellent level of performance or efficiency.
"Ours is a performant network monitoring and systems monitoring tool."
"This software is ten percent more performant than its predecessor."
Yes, but somebody adding it to wiktionary doesn't make it a word. It just seems lazy to make up new words rather that taking the trouble to use an existing one.
The "Chromium-like user interface where tabs can be torn off and moved between windows" would be awesome if it were implemented directly in Mac OSX. Then applications could drop all of that code and just let the OS deal with it. Also, you'd be able to group distinct applications. I'd love to have a [Browser, Text Editor, Terminal] tab group.
EDIT: Another thought... Chrome tabs don't look like any other tabs in Mac OSX. Applications lose uniformity as they're forced to define more about themselves.
Chrome tabs are some of the best-behaving and best-looking tabs on any OS, though. See TotalFinder for a Finder mod that applies Chrome tabbing to all Finder windows. Makes D&D a snap.
Most people in word have 1-2 documents open at once.
Most people in text editors like gedit, kate, eclipse, VS have maybe 10 or 20 tabs
But most emacs users have at least 80 or 90 buffers open! It's an interesting phenomena that I haven't seen elsewhere. Why is this? Are tabs too much overhead or does emacs have really good buffer management?
Not a criticism, I'm slowly picking up some emacs after 2 years of vi, and I'd like to understand more of the nuances.
I haven't met many people who casually use emacs (other than those trying it out for the firs time, or giving it another shot, (or another, or another))
For those who really GET emacs, and think in emacs, it becomes their entire workflow - as they can automate everything from emacs, incrementally. Those guys that work with 80 or 90 buffers open didn't start out that way - they grew over the years to working that way by tweaking more and more functionality to bend it to their will.
You can extend lots of editors - but there's something about emacs and it's lisp nature that lends itself to this kind of developer.
It's because Emacs is one of the few editors where you can actually manage 90 and more buffers -- thanks to the fact that you can refer to them by name.
Exactly. To switch to a different buffer I don't pick it from a list, I just enter its name. Actually, thanks to iswitch, I only start typing a few characters that are unique to the buffer name. It's an incredably fast way of flicking between different buffers and it scales very well to a large number of files.
Also, hippie-expand will expand to stuff contained in open buffers.
That's because in many respects Emacs isn't so much an editor as an operating environment. You can do pretty much anything from/in Emacs if you're so inclined. If you know Emacs' lisp well enough you don't ever need to leave. Heck, Emacs can even make Coffee (http://www.emacswiki.org/emacs/CoffeeMode).
To view Emacs as an editor, while technically accurate is not necessarily a fair comparison because it does so much more.
I believe you may want to check with java programmers close to you.
When using eclipse I usually have 30-60 files open, probably for the same reason emacs users have them: it's very easy, has little overhead and accessing the working set is faster this way.
The reason it does not happen with gedit & kate is that tab-based interface fall into uselessness with too many tabs, if they do not provide alternative methods of navigating them than "click on the right one".
Tabs are one of those design decisions where everyone else is doing it, so it must be smart. I don't bother with tabs myself, most of my projects are small enough that I can find the files in the file list on the side in TextMate, Eclipse, etc..
I think a smarter solution would be to put recently accessed files in that file list on the side, vertically.
Much the same as it does in TextMate, probably. As many tabs as can realistically be identified plus an extra drop down menu with all of the rest.
(But I use the project view anyway, because I also see tabs as pointless, and most other developers I know rely on things like PeepOpen or Cmd+T's file finder.)
To expand on that: I really like the notion of tabs in text editors. I like having a quick and visual represantation of how many files I'm working on. It's also very easy to memorize where a certain file is spatially.
But then I'm a very visual person, if I can only see one file at once without knowing all the open files at a glance, I go absolutely nutters.
It would be just lame to have another editor on just OSX only, considering that most people have used some script-able code editor (like emacs or vim) that are openly script-able (or compilable).
If it is just for OSX, then there is a specific scripting language called AppleScript which is OSX only and should be even more integrated to the OSX APIs.
Well at least the "Chromium-like" part triggers my thoughts on web based editor.
It wouldn't be lame; it would be awesome to have another kickass editor for Mac OS X, especially one that takes full advantage of the features of Snow Leopard and modern hardware.
Signed up for the beta; looking forward to trying it out.
You've listed three browser based editors and one which seems to be completely focused on JavaScript editing. If I understand correctly, Kod is supposed to be a universal editor for programmers, only scripted in JS.
(But thanks for the link to cloud9, I didn't know about it and it looks interesting.)
EDIT: meh, it was actually 4 browser based editors :(
I hear this more and more lately - and sure, competition would be good.. but, what's wrong with textmate at this point?
I bought a few copies a few years ago, and I've been using them ever since, lots of extensions, still nice and light, still awesome to use... I dont' find myself sitting around thinking "Man I wish this guy would hurry up and bring out a new version!"....
like, it's not minecraft....
I'm a TM user, and I'm happy with the product, but there are some areas that could use improvement. First, there's undo. Undo in TM is letter-by-letter. That makes it pretty useless for moving very far back in to history. Then there's any kind of intelligent auto-completion. Auto-complete in TM is as rudimentary as it gets. It's basically word matching for the current document, or from a bundle.
I still think TM is the best editor for me, and I'd happily use it for the next 25 years without a single gripe if I had to, but I'm not sure the editor community is going to just sit around while TM stagnates.
I actually agree 99% with you- I happily use TM more or less constantly, and have since it was first released. That said, there are four features (or feature areas) that I feel like would add immeasurably to my TextMate experience:
1. Split-window editing
2. Multithreaded searching, pasting, etc.- having the whole app hang while doing a "find in project" is a major drag, especially when it's due to, oh, say, having a bunch of files open from a slow network share. Which brings me to...
3. Better handling of files opened from remote volumes- another case where multiple threads would probably help.
4. Better handling of really long lines when word-wrap is turned off. There is obviously something O(n) going on at the line level (where n is the number of characters on the line), and it makes handling long runs of text rather painful at times.
So, there it is: my TextMate wish list. Modulo those four things, TextMate is currently pretty close to ideal, IMHO. I love its syntax highlighting grammar, its snippets, its macro capabilities, etc. etc. The Latex package is fabulous, and has singlehandedly done a lot to make my dissertation-writing process bearable.
The big issue is that Textmate 2.0 was announced as a free upgrade years ago and it has yet to appear. Joe Hewitt's tweet kinda says it all: http://twitter.com/joehewitt/status/14998671708
While there are certainly some nice features in Kod it has a long way to go before it offers some of the features that textmate does (e.g. snippets). With that said, I'm hoping Kod becomes a real alternative to textmate!
Emacs is a fantastic editor (and I think I can say that I am what you call a power user), but Emacs Lisp is a terrible, terrible language. The more I use it, the more I hate it. And it's not because of the lispiness or parens -- Common Lisp was my Language of Choice for many years.
Having an editor that I could extend in a real programming language (and JS is actually very nice once you grasp stuff like prototype inheritance and learn to avoid the... uhm, bad parts) would be simply awesome. And if it was pretty and integrated with OS X I would be willing to pay hard cash for it.
If Node.js were to get a little bit of language agnosticism (write code and source debug in Coffeescript and anything else that treats Javascript as a compiler target) then you'd have programmable-editor nirvana for web developers.
I find it much more useful than the file trees in any of the gui editors I've tried. You don't need to leave your keyboard and you can create, delete and move files directly from the tree which some gui editors don't even allow you to do. If you haven't tried it give it a shot.
Fair enough I guess, although "doesn't look like crap" is pretty subjective. Based on the number of "switching to Vim" blog posts (some on OS X) submitted to HN over the past few months, I would say the old editors are still putting up plenty of competition.
Looks good. But I don't really care if I can style the editor with CSS3.
Concretely, why should I scrap my current code editor and start using Kod? Is it somehow targeted to Node.js devs; how is that better than Cloud9?
No browser stuff and Node.js is running in an isolated process. CSS is simply the "language" in which you define the looks of the editor and has nothing to do with web browsers or html.
Are you the author of Kod (that's what some of your comments suggest)? If yes, do you have a roadmap? Do you want to make it open source? I would be pretty excited to try it, out even if it was in scary-alpha state.
Will it do C++? I still haven't found a good C++ editor (with class member autocomplete popups and such) - at least, nothing that compares to Visual Studio over in the Windows world.
The popup with the list of class members (I think XCode calls it "Code Sense") tends not to work if your code is too complicated. I know that sounds like a silly reason not to use an IDE, but I surprise myself with how much I miss it.
not sure what you're referring to. If it's the font, well Im assuming that's changeable and if it's the brace on line 47, then that's just word wrap making it look odd. If you're referring to the fact that the open braces are on the end of the lines, well... that's where God himself intended them to be :)
Would someone enlighten me what the motivation is to use it as an editor's scripting environment?