3 ms·
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
by 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 agoCodeMirror 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 agoI 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...