50 ms·

> powerful text manipulation Have you read the article you are commenting on? It talks about the exact opposite: > Compared to Atom the search [in Textmate] i

by adamors 13y ago

> powerful text manipulation Have you read the article you are commenting on? It talks about the exact opposite: > Compared to Atom the search [in Textmate] is blazing fast. > Doing regex searches in vim on that file is instant. The memory barely moves. Searching for the character d takes almost 10 seconds in Atom, and significantly increases memory usage. When I say significantly, I'm talking 200 megs. That doesn't mean powerful anything to me. Especially not text manipulation. EDIT: Also, I don't care if people actually like things. What bothers me is blind fanboyism/praise for something people used for 2 days at the max.

doorhammer 13y ago
I'm pretty convinced to stick with vim at this point, myself, and see where the neovim project goes, but I thought I'd throw out that when I think of "powerful text manipulation" I'm not necessarily thinking of how fast it takes to do basic operations. For instance, I messed around with sublime text and I really dug how it handled multiple cursors. I'd never say something like vim couldn't do that, but sublime (for me) made multiple cursors seem intuitively powerful and useful, in that I could perform quick operations in seconds that I wouldn't have thought to perform in that way before. I'd say it's similar to me if you were to compare regex find/replace with normal find/replace. It's a more powerful/flexible idea. Whether or not it's a good one is up for grabs. That said, the speed does sound like it could be a problem. I just don't think power text manipulation is referencing processing efficiency. I'm wondering how the efficiency of this setup is played out in stuff like Light Table and Brackets, which seem pretty similar (I think the front end on those is just html? I could be totally wrong). And like I said, so far I'm way more interested in neovim than any of the newer other browsers.
- jamii 13y ago
  CodeMirror has had a ton of work put into it and Light Table mostly rides on that. Opening a 40kloc javascript file and searching in it is totally smooth. Auto-complete, jump-to-definition etc are fast and don't block the UI. We still have performance issues in places (eg watching large directories which change often, serialising large inline results) but we haven't had any problems with the DOM being too slow. CodeMirror deals with all of that for us. I'm playing around with React (and Om, Quiscient etc) at the moment and it's by far the nicest UI model I've ever encountered. If I could get Cassowary working reasonably fast too it would be miles ahead of anything else. The only thing that I don't see improving soon is not having shared memory threads (or even zero-copy messaging). Webworkers are all well and good but sometimes the serialisation overhead is still enough to block the UI. thread.
  - STRML 13y ago
    I agree 100% about React - I can't help but think that an editor based upon it could really speed up all the DOM manipulation that holds back every webkit-based desktop app. Re: Web workers, this probably isn't news to you but you can use transferable objects [1] to eliminate the serialization hiccup. Of course, if you're really trying to share objects across threads in real time, rather than transfer data, parse, and fire events, you may have bigger issues. 1. https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers#Passing_data_by_transferring_ownership_(transferable_objects) https://developer.mozilla.org/en-US/docs/Web/Guide/Performan...
jbeja 13y ago
Agree, IMHO speed is everything, and the fanboyism of some people about this make me little bit uncomfortable, i was rolling my eyes every time that i read something like "is so pretty, look at that dark colorscheme, i am gonna switch now", sigh -_-.

by adamors 13y ago

doorhammer 13y ago

I'm pretty convinced to stick with vim at this point, myself, and see where the neovim project goes, but I thought I'd throw out that when I think of "powerful text manipulation" I'm not necessarily thinking of how fast it takes to do basic operations. For instance, I messed around with sublime text and I really dug how it handled multiple cursors. I'd never say something like vim couldn't do that, but sublime (for me) made multiple cursors seem intuitively powerful and useful, in that I could perform quick operations in seconds that I wouldn't have thought to perform in that way before. I'd say it's similar to me if you were to compare regex find/replace with normal find/replace. It's a more powerful/flexible idea. Whether or not it's a good one is up for grabs. That said, the speed does sound like it could be a problem. I just don't think power text manipulation is referencing processing efficiency. I'm wondering how the efficiency of this setup is played out in stuff like Light Table and Brackets, which seem pretty similar (I think the front end on those is just html? I could be totally wrong). And like I said, so far I'm way more interested in neovim than any of the newer other browsers.

jamii 13y ago
CodeMirror has had a ton of work put into it and Light Table mostly rides on that. Opening a 40kloc javascript file and searching in it is totally smooth. Auto-complete, jump-to-definition etc are fast and don't block the UI. We still have performance issues in places (eg watching large directories which change often, serialising large inline results) but we haven't had any problems with the DOM being too slow. CodeMirror deals with all of that for us. I'm playing around with React (and Om, Quiscient etc) at the moment and it's by far the nicest UI model I've ever encountered. If I could get Cassowary working reasonably fast too it would be miles ahead of anything else. The only thing that I don't see improving soon is not having shared memory threads (or even zero-copy messaging). Webworkers are all well and good but sometimes the serialisation overhead is still enough to block the UI. thread.
- STRML 13y ago
  I agree 100% about React - I can't help but think that an editor based upon it could really speed up all the DOM manipulation that holds back every webkit-based desktop app. Re: Web workers, this probably isn't news to you but you can use transferable objects [1] to eliminate the serialization hiccup. Of course, if you're really trying to share objects across threads in real time, rather than transfer data, parse, and fire events, you may have bigger issues. 1. https://developer.mozilla.org/en-US/docs/Web/Guide/Performance/Using_web_workers#Passing_data_by_transferring_ownership_(transferable_objects) https://developer.mozilla.org/en-US/docs/Web/Guide/Performan...

jbeja 13y ago

Agree, IMHO speed is everything, and the fanboyism of some people about this make me little bit uncomfortable, i was rolling my eyes every time that i read something like "is so pretty, look at that dark colorscheme, i am gonna switch now", sigh -_-.