10 ms·
Until they fix the 2MB limitation on editing files. No way.
by sigzero 12y ago
Until they fix the 2MB limitation on editing files. No way.
- cordite 12y agoOr syntax highlighting breaking because some code you've been given has some 8K-long regex on one line in the middle.
- VieElm 12y agoRegular expressions are not the way to do syntax highlighting yet many of the popular editors do it this way. Create a super huge string in vim, textmate or sublime text and watch it blow up. Then try it in Xcode or Intellij and see that there is no problem. The reason for Xcode and Intellij's fast syntax highlighting is because these do not use regular expressions, they use a lexer. They're examining the text one character at a time with some amount of forward and backward looking state and building the syntax highlighting and smart completion/features that way. As long as your editor is using regular expressions for syntax highlighting this will be a problem for you.
- thesz 12y agoLexing IS regular expressipn matching (except for some esoteric features like Haskell's nrsted comments). Difference is in the handling. As a matter of fact, Visual Studio uses semantic analysis - classes show differently than other identifiers.
- deleted 12y ago[deleted]
- cordite 12y agoIt can be, it can also be a context free grammar, which is 'higher' than a state machine (or regular expression)
- hyperpape 12y agoBut there are also higher complexity bounds on CFGs (since they include regular expressions, they certainly can't be lower). In any case, I've never heard of someone using non-regular expression CFGs for lexing. Are there cases?
- thesz 12y agoI mentioned Haskell above. It has nested block comments which should be balanced. Thus CFG.
- JohnBooty 12y agoI believe cordite is saying that Atom's syntax highlighting fails when your code contains a huge regular expression. I don't believe cordite is claiming that Atom's syntax highlighting fails because it uses regular expressions internally. (I don't know if Atom's syntax highlighting even works that way, FYI. Though I would guess that it does.)
- cordite 12y agoThis is the correct interpretation of what I said. I don't know if it is also related to long strings in general on one line (have not tested)
- PlzSnow 12y agoMoore's Law should apply, and eventually processing power should catch up. I think we'll see the 2MB limit removed by 1997/1998.
- _pmf_ 12y ago> Moore's Law should apply, and eventually processing power should catch up. I think we'll see the 2MB limit removed by 1997/1998. That's a nice summary on the quality on web technologies. 2009: "Hey guys, we can now draw on a widget; we called it Canvas!" 2011: "Wow, look at this cool OpenGL wrapper that locks up your system in ways VoodooFX didn't manage to do in 1998! But you can use it on your web site, which is what people want, right, guys?"
- s_kilk 12y agoYeah, I find this stuff depressing. I see people jumping up and down over a demo of the Unreal-1 engine running at 0.04 fps in javascript and I think to myself, if my old compaq POS from the late nineties could run that engine without trouble, why can't my brand new Macbook do better, or at least the same? It feels like we've redefined "progress" to mean "the same thing as 20 years ago, but worse"
- m_mueller 12y agoI think you would enjoy Alan Kay's talks, especially "the PC revolution hasn't happened yet".
- anon4 12y ago> the same thing as 20 years ago, but worse More like the same thing as 20 years ago, but the dominant language is a LIS.. I mean a Schem... I mean it's a bit like Self.. look, it has garbage collection, a JIT, supports objects and goes somewhat fast. Oh, and it's used to drive a GUI made up of stringly-typed ... things that kind of looks like SGML and has no chance in hell of achieving good draw performance. But you can calculate fibonacci in CSS and get even worse performance than doing it at compile-time with C++ templates!
- 12y ago
- frewsxcv 12y agoWhy do all threads about Atom seem to be full of people opening huge files with text editors? I've never had performance issues with Atom with a 2013 MBA.
- hurin 12y agoBecause no one wants to use a laggy text-editor, it doesn't matter how sleek and hip it is if they can't fix that.
- delluminatus 12y agoIt depends on your usage. Sure, source files are (hopefully) not going near that size, but many people regularly open multiple-MB log files or data files. Also, for me at least, it's the principle of the thing -- we are talking about a measly few MB of text; if you can't even open that, IMO something has gone horribly wrong.
- frewsxcv 12y agoWhy are you opening log files with a text editor?
- cdelsolar 12y agoPlease enlighten us.
- sea6ear 12y agoIf you are looking for unusual conditions, scanning through visually is sometimes easier than it would be to try to grep for the particulars of an entry, especially if you don't know the particulars of the unusual condition yet. Some editors with "minimap" functionality (Sublime Text and Emacs that I'm aware of, maybe others) can give you a fairly good visual overview of large swaths of a file at once. Sometimes strange entries are obvious just because of the shape of the line and in those cases the minimap makes it easy to see when something unusual is happening.
- deleted 12y ago
- mirekrusin 12y agoyou can write loops or recursive functions to make your code smaller.
- bdg 12y agoI'm so happy I don't work on the files you work on.
- greggman 12y agoI like that my editor can edit hex and it doesn't barf if I give it a giant file. But yea, it's only maybe once a year I open a file that big.
- chisleu 12y agoSeriously. 2MB files have to be doing it wrong. Right?
- paulhodge 12y agoDefinitely situational but not out of the question. Maybe I want to use my favorite text editor to examine a logfile. 2mb is nothing when it comes to production logs.
- eunoia 12y agoCrazy, but not out of the question. I use Sublime to edit conflicts in .xcodproj files. These brutally detailed XML files - necessary to iOS/OS X development - can be huge. At my previous job one was 7mb.
- JohnBooty 12y agoIn addition to log files (covered in another reply)... - Database dumps (if you're dumping a database to a text file, how often will it be under 2MB?) - Data, in general. Tab/CSV text files are still the lingua franca of non-hierarchical data and that will probably never change. - Code you don't control or haven't refactored yet. OK, we can all agree that a 2MB source code file is probably "doing it wrong." But maybe you don't control it. And even if you do control it... well, you need to edit it to refactor it, right? That said, I don't think the 2MB limit is a total death knell for an editor. I keep TextWrangler (OSX) and UltraEdit (Win) around precisely because they're good with larger files. If my primary code editor is good at large text files, that's a bonus, but it's not a total necessity.
- 12y ago
- deleted 12y ago[deleted]
- pbiggar 12y agoSo the thing about Atom (and any "disruptive" software) is that it doesn't have to be amazing at everything. It only has to be 10x better for some niche of people who will be this product's early adopters and evangelists. That will gain it enough traction to prove itself in the market, and over the next few years it will fix all the problems such as the 2MB limit, and whatever else is there. And then, laggards (well, you're probably more of an "early majority" type of person in Crossing the Chasm lingo) will see enough value to join.
- PlzSnow 12y agoThe 2MB/slowness isn't something that can just be "coded away". It's a direct result of the technology stack chosen. It is not a solvable problem. Therefore Atom cannot succeed beyond niche usage.
- pbiggar 12y ago"not a solvable problem" and "cannot succeed" are very strong assertions that are not backed up by evidence.
- laurent123456 12y agoWhy is there a 2MB limit anyway? Is it because the document is rendered to HTML? In this case, why don't they render only the part currently visible on screen?
- iends 12y agohttps://github.com/atom/atom/pull/1607/files https://github.com/atom/atom/pull/1607/files The editor is intentionally crippled.
- davidy123 12y agoThey were probably tired of people complaining about problems with this corner case of opening humongous files in an editor meant for editing source code. Atom properly should be optimized for kilobyte sized files, not megabyte.
- JohnBooty 12y agoI see this limitation mentioned often when Atom is discussed. On the constructive side of things, anybody have recommendations for editors that do handle large text files well? Obviously vi and emacs do. (Correct?) OSX - TextWrangler and its big brother BBEdit are the best I've found - but this is not something I've extensively researched. Windows - UltraEdit boasts that it can edit files of arbitrarily large sizes and in my experience this is true. UltraEdit costs money but I have an old version I keep around for when I need to work with bigger files.
- JamesMcMinn 12y agoSublime Text. I've used it for files > 2GB and it seems to handle them fine.
- osw 12y agovi, nano, micro emacs, vim, emacs, gedit, geany, Kwrite, Kate, notepad++, sam, acme
- aragot 12y agoI haven't looked at it for long, but as I remember it could help if there was a visualized for those files. Often it's a png, a jar, it would be less frustrating if it could open anyway, just in the right editor?
- jussij 12y agoWhat do you define as a large file? For example Atom seems to think a 2 MByte file is large. I personally think 100 MBytes files are quite large. But some users with massive log files consider Giga Byte files as being large.
- JohnBooty 12y agoYour definition sounds fine to me!
- bengotow 12y agoOn the mac BBEdit is incredible. A several hundred MB log file will bring Sublime Text to it's knees, and BBEdit has no problems at all. +1
- Hapa 12y ago2MB limitation should be handled when 1.0 is released, meanwhile view-tail-large-files package might help.