9 ms·

Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations. I've jumped from ST to tr

Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations. I've jumped from ST to try and use this since I received my invite and am incredibly impressed without how little I feel the urge to switch back. Other editors that I try out (which I do far to often, ugh) are pretty, have unique features, but they lack the can't live without feature(s) that no one has matched in ST is the ease of line/text manipulation (find-next(cmd-d) + find-skip-next-next(cmd-k+cmd-d)+ undo + Multi Cursor, Block Select, Dupe...). Atom got close with this version. The duplicate function is only duplicate line but without knowing any CoffeeScript I was able to override this function to duplicate selection if there is a selection before duping the line — for every selection. There are many other areas that are close and will either be closed out by myself for my own use, addressed by others via packages, or even in the core once it hits 1.0. Anyway, this is a good write up and good look at the negatives of a web based editor, but I would argue the drawbacks of the DOM outlined are outweighed by the ability talk to it (and also the entire API) via the webkit inspector. Also, the current version number is 0.6.0.

rjzzleep 13y ago
> Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations Agreed, I too was positively surprised about it's speed. >Anyway, this is a good write up and good look at the negatives of a web based editor, but I would argue the drawbacks of the DOM outlined are outweighed by the ability talk to it (and also the entire API) via the webkit inspector. Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you? I can't really think of a good reason why this would be true. It would seem to me that an elaborate API for manipulating, and annotating the text store while being more complicated to design would be much better to create high quality plugins. This solution opens the door to lots of hard to debug memory leaks, and conflicts that can easily destroy the text your editing. You could argue that bad plugin developers don't warrant closing off the api, and i would be with you. I'm just not sure what exactly you need the DOM for. EDIT: actually I can. when dealing with web technologies, i have to admit it would be sometimes cool when you can instant preview code in the editor. this is possible with both brackets and atom. but atom has been much smarter about marketing a finished product. so this can turn into a sort of wysiwyg for the web
- kingnight 13y ago
  > Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you? No, I am not. Ha! I guess I am exposing my own ignorance of _the right way_ to do things like this along with what my comfort zone is. If I want to going to write a package to insert the current date at the cursor point, for example, I am likely going to just open up the webkit console and write code in their until it works (I did this) — instead of going to atom.io and finding their API documentation. One cop out too I was thinking about is that one could easily write a plugin to 'edit in' and assign a keyboard shortcut to handle the big files in their robust editor de jour.
albiabia 13y ago
Anyone who has ever looked at the DOM structure of an in-browser code editor (CodeMirror, Ace) knows that they are extremely nasty. So much overhead. The markup characters outnumber the content by like 50x. While the speed of Atom is much better than I expected, it just doesn't feel native enough. I still feel like I'm using an in-browser editor. Maybe Sublime has spoiled me, but that editor is pretty fast. It can open large files. It's almost as extensible, especially for any kind of practical purpose. Oh and it's cross-platform, which Atom is not at the moment. I also can already see a time when we reach Atom package hell. Someone is going to have to come up with a system to manage all these packages pretty quick. When you are literally installing packages to add a single hot-key, and all packages are treated as equals, it quickly becomes very difficult to find what you are looking for to manage your install. I'm excited and optimistic to see where Atom will go, but my thoughts before I tried it are only reinforced after a few days of use. GitHub does not mess around. I know they will fix most of my concerns pretty quick, but I'm not sure how much more can be done about performance.
- jamii 13y ago
  I don't know about Ace, but CodeMirror only loads a small portion of the file text into the dom. I regularly load 40 kloc javascript files in Light Table without any noticeable pauses.
  - chr1 13y ago
    Yes they both display only visible part of the text, which Actually Ace was the one that first used this technique for rendering. And c9.io opens 80kloc files without a problem, and have much faster searching and scrolling.
- kingnight 13y ago
  In my few reviews of the Atom DOM for creating a theme, the structure felt very tame (and I too have looked at CodeMirror/Brackets). I found it readable and straightforward. There's a bit to it, but eh, good enough to work through if I inspect elements etc. Sublime sure is fast. This is fast too. I haven't put it through its paces in normal usage, but at least I have a fallback that I like. Package hell is true for anything is it not? If you're saying Atom doesn't have N feature count that matches other editors, you could very well be right, but I have a feeling that will change. Also, I'm sure Atom will start ranking plugins at some point too.
leobelle 13y ago
I challenge anyone to find me a feature in an editor that you can't find in an IntelliJ IDEA based editor like WebStorm or RubyMine. Atom, Sublime Text, Text Mate, and even Vim and Emacs use (broken) regular expressions to do syntax highlighting and intelligent things. IntelliJ build a "PsyElement" tree which is basically an AST. As such it will always have more features and be more powerful, and it's all on the JVM and super amazingly fast, well except for the indexing and startup (yech), but Cmd+B on any variable in any language IntelliJ understands, or Alt+F7 on a variable definition or Shift+F7 or Shift+F6 for a rename. IntelliJ is actually here from the future to write our code for us, and I'm saying this as a pretty dedicated vim user.
- lmm 13y ago
  IDEA's scala support still flags bogus errors (e.g. it doesn't seem to infer the type of a Kleisli { ... } correctly). It's one of the things keeping me on Eclipse.
  - caniszczyk 13y ago
    What's bothering you about Eclipse?
    - lmm 13y ago
      Its scala refactoring is quite limited (even organize imports doesn't work, can't move a type out of a file without moving it to a different package which will sometimes fail anyway, no "generate interface implementations" or "move method to parent class"), autocomplete is painfully slow, and every so often the UI freezes for several seconds.
- jamii 13y ago
  How about watches in LT - http://www.youtube.com/watch?v=d8-b6QEN-rk http://www.youtube.com/watch?v=d8-b6QEN-rk I've only used Intellij for scala and while the static analysis was pretty useful I wasn't at all impressed by the facilities for live interaction. Maybe some of that is down to the scala repl being pretty poor - perhaps if I used Intellij with python or javascript I would find it more useful.

rjzzleep 13y ago

> Without looking at the behind the scenes memory allocation/speed — the real world speed of the application surpassed my expectations Agreed, I too was positively surprised about it's speed. >Anyway, this is a good write up and good look at the negatives of a web based editor, but I would argue the drawbacks of the DOM outlined are outweighed by the ability talk to it (and also the entire API) via the webkit inspector. Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you? I can't really think of a good reason why this would be true. It would seem to me that an elaborate API for manipulating, and annotating the text store while being more complicated to design would be much better to create high quality plugins. This solution opens the door to lots of hard to debug memory leaks, and conflicts that can easily destroy the text your editing. You could argue that bad plugin developers don't warrant closing off the api, and i would be with you. I'm just not sure what exactly you need the DOM for. EDIT: actually I can. when dealing with web technologies, i have to admit it would be sometimes cool when you can instant preview code in the editor. this is possible with both brackets and atom. but atom has been much smarter about marketing a finished product. so this can turn into a sort of wysiwyg for the web

kingnight 13y ago
> Yes, you know, I thought about that a lot. But I'm not entirely sure that's true. Are you? No, I am not. Ha! I guess I am exposing my own ignorance of _the right way_ to do things like this along with what my comfort zone is. If I want to going to write a package to insert the current date at the cursor point, for example, I am likely going to just open up the webkit console and write code in their until it works (I did this) — instead of going to atom.io and finding their API documentation. One cop out too I was thinking about is that one could easily write a plugin to 'edit in' and assign a keyboard shortcut to handle the big files in their robust editor de jour.

albiabia 13y ago

Anyone who has ever looked at the DOM structure of an in-browser code editor (CodeMirror, Ace) knows that they are extremely nasty. So much overhead. The markup characters outnumber the content by like 50x. While the speed of Atom is much better than I expected, it just doesn't feel native enough. I still feel like I'm using an in-browser editor. Maybe Sublime has spoiled me, but that editor is pretty fast. It can open large files. It's almost as extensible, especially for any kind of practical purpose. Oh and it's cross-platform, which Atom is not at the moment. I also can already see a time when we reach Atom package hell. Someone is going to have to come up with a system to manage all these packages pretty quick. When you are literally installing packages to add a single hot-key, and all packages are treated as equals, it quickly becomes very difficult to find what you are looking for to manage your install. I'm excited and optimistic to see where Atom will go, but my thoughts before I tried it are only reinforced after a few days of use. GitHub does not mess around. I know they will fix most of my concerns pretty quick, but I'm not sure how much more can be done about performance.

jamii 13y ago
I don't know about Ace, but CodeMirror only loads a small portion of the file text into the dom. I regularly load 40 kloc javascript files in Light Table without any noticeable pauses.
- chr1 13y ago
  Yes they both display only visible part of the text, which Actually Ace was the one that first used this technique for rendering. And c9.io opens 80kloc files without a problem, and have much faster searching and scrolling.
kingnight 13y ago
In my few reviews of the Atom DOM for creating a theme, the structure felt very tame (and I too have looked at CodeMirror/Brackets). I found it readable and straightforward. There's a bit to it, but eh, good enough to work through if I inspect elements etc. Sublime sure is fast. This is fast too. I haven't put it through its paces in normal usage, but at least I have a fallback that I like. Package hell is true for anything is it not? If you're saying Atom doesn't have N feature count that matches other editors, you could very well be right, but I have a feeling that will change. Also, I'm sure Atom will start ranking plugins at some point too.

leobelle 13y ago

I challenge anyone to find me a feature in an editor that you can't find in an IntelliJ IDEA based editor like WebStorm or RubyMine. Atom, Sublime Text, Text Mate, and even Vim and Emacs use (broken) regular expressions to do syntax highlighting and intelligent things. IntelliJ build a "PsyElement" tree which is basically an AST. As such it will always have more features and be more powerful, and it's all on the JVM and super amazingly fast, well except for the indexing and startup (yech), but Cmd+B on any variable in any language IntelliJ understands, or Alt+F7 on a variable definition or Shift+F7 or Shift+F6 for a rename. IntelliJ is actually here from the future to write our code for us, and I'm saying this as a pretty dedicated vim user.

lmm 13y ago
IDEA's scala support still flags bogus errors (e.g. it doesn't seem to infer the type of a Kleisli { ... } correctly). It's one of the things keeping me on Eclipse.
- caniszczyk 13y ago
  What's bothering you about Eclipse?
  - lmm 13y ago
    Its scala refactoring is quite limited (even organize imports doesn't work, can't move a type out of a file without moving it to a different package which will sometimes fail anyway, no "generate interface implementations" or "move method to parent class"), autocomplete is painfully slow, and every so often the UI freezes for several seconds.
jamii 13y ago
How about watches in LT - http://www.youtube.com/watch?v=d8-b6QEN-rk http://www.youtube.com/watch?v=d8-b6QEN-rk I've only used Intellij for scala and while the static analysis was pretty useful I wasn't at all impressed by the facilities for live interaction. Maybe some of that is down to the scala repl being pretty poor - perhaps if I used Intellij with python or javascript I would find it more useful.