Kod is a new Node.js scriptable code editor for OSX(kodapp.com)
kodapp.com
Kod is a new Node.js scriptable code editor for OSX
http://kodapp.com/
71 comments
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.
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.
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...
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.
OT: Is "performant" really a word? I see it on HN all the time, and it strikes me as made-up business jargon.
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.
[1]: http://en.wiktionary.org/wiki/performant
"Ours is a performant network monitoring and systems monitoring tool."
"This software is ten percent more performant than its predecessor."
[1]: http://en.wiktionary.org/wiki/performant
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.
http://ngrams.googlelabs.com/graph?content=performant&ye...
I wonder if the early appearance is OCR error?
http://ngrams.googlelabs.com/graph?content=performant&ye...
I wonder if the early appearance is OCR error?
It being used makes it a word. Words get added to dictionaries often. Where do you think they came from to begin with?
Actually my point in posting the qoute and the link was to show that it's jargon.
Anyhow do you have an issue with scalable[1] too?
----
[1]: http://ngrams.googlelabs.com/graph?content=Scalable&year...
Anyhow do you have an issue with scalable[1] too?
----
[1]: http://ngrams.googlelabs.com/graph?content=Scalable&year...
This is a separate idea, but...
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.
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.
Stack and Tile for Haiku is nice: http://www.youtube.com/watch?v=ccniJHjo_Uw
KWin in KDE can also stack and tile application windows. Sadly, nothing like that exists for OS X.
KWin in KDE can also stack and tile application windows. Sadly, nothing like that exists for OS X.
Have you tried Zooom/2? http://coderage-software.com/zooom/
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.
http://totalfinder.binaryage.com/
http://totalfinder.binaryage.com/
Here's what I don't get about tabs and the phrase "programmer's text editor" -- what programmer only has 8 files open at once?
Looking at ibuffer, I have 92 buffers open in Emacs right now. What would that look like with tabs?
Looking at ibuffer, I have 92 buffers open in Emacs right now. What would that look like with tabs?
Managable.
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.
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.
My observations:
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.
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.
There's a selection bias at work - emacs.
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.
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.
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.
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".
IMO, of course.
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".
IMO, of course.
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.
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.)
(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.)
It just seems that
a) you're not doing a very good job at staying focused
b) your editor doesn't help you much managing all this chaos
How about cloud9 (http://www.cloud9ide.com), Bespin (https://bespin.mozillalabs.com/), Codemirror (http://codemirror.net/) or Ymacs (http://www.ymacs.org/).
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 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.
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 :(
(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 :(
Exactly, considering that we still have textmate around, I am not sure if scripting in node.js with OSX API is the best way to pull it out.
As I mentioned AppleScript seems to be a better fit for an OSX-only editor.
Of course any new things are welcomed, just that I am not at the best positive about this.
As I mentioned AppleScript seems to be a better fit for an OSX-only editor.
Of course any new things are welcomed, just that I am not at the best positive about this.
Finally some potential competition for textmate.
Vim and Emacs weren't enough?
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.
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.
Vim supports scripting with MzScheme, Perl, Python, Ruby, Tcl, and Lua.
Show me a usable file tree view that doesn't look like crap for vim or emacs, and I will go back to using them.
With today's web frameworks, when I hop between files all the time, I want a neat visual file tree.
With today's web frameworks, when I hop between files all the time, I want a neat visual file tree.
What's wrong with Nerdtree? Just its looks?
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.
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.
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!
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 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 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.
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
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?
It's built using Node.js fyi.
I don't think it's a client-side in-browser editor:
"Written from scratch with modern OS X 10.6 APIs providing maximum OS integration while avoiding reinvention of the wheel."
Though CSS styling and Node scripting leads me to believe it's using some v8/browser stuff.
"Written from scratch with modern OS X 10.6 APIs providing maximum OS integration while avoiding reinvention of the wheel."
Though CSS styling and Node scripting leads me to believe it's using some v8/browser stuff.
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.
I stalked the website's author a little bit:
- rsms on Github, twitter, flickr, facebook…
- http://hunch.se/
And this rasmusfabbe is developping Kod: - http://www.youtube.com/watch?v=jHUp3sdKYJw (a cool idea on grouping documents by Levenstein distance)
I do wish people would get used to (dis)claiming when they have a stake in some product they comment on.
And this rasmusfabbe is developping Kod: - http://www.youtube.com/watch?v=jHUp3sdKYJw (a cool idea on grouping documents by Levenstein distance)
I do wish people would get used to (dis)claiming when they have a stake in some product they comment on.
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.
Why not Xcode?
screenshot appears to be C++ code (might be wrong on this though, as I've never written any C++, and only use C occasionally)
The screenshot displays C code.
I've heard good things about this plugin, which uses clang to do autocompletion inside vim:
http://www.vim.org/scripts/script.php?script_id=3302
http://www.vim.org/scripts/script.php?script_id=3302
That looks great - I'll give it a try. Thanks!
gcc and vim with proper c++ handling work really well for me.
Hey, does anybody know what font is used on that screenshot?
If they ported this to iPad, I'd pay big bucks for it.
Agreed. An extendable (Apple allows JavaScript to be downloaded, right?) text editor for the iPad would be wonderful.
This is quite exciting. Anything is known about the authors or a release schedule? I would love to beta test it.
about the author: http://hunch.se/resume/
tl;dr: was creative director at spotify, now works at facebook
tl;dr: was creative director at spotify, now works at facebook
I wonder if it is based on Chromium.
It's based on https://github.com/rsms/chromium-tabs which is a lose port + mimic of Chromium code.
If it can't fix those curly braces in the screenshot then I don't want to go near the thing.
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 :)
[deleted]
Would someone enlighten me what the motivation is to use it as an editor's scripting environment?