5 ms·
On a semi-related note: You know what would really get me excited? A GPU accelerated, highly optimized text editor, that could display several gigabytes of text
by jcfrei 8y ago
On a semi-related note: You know what would really get me excited? A GPU accelerated, highly optimized text editor, that could display several gigabytes of text with several thousand columns wide rows, smooth scrolling, zooming and text-highlighting. That would be a real step up from current text editors. The only thing that comes close (that I know of) is still Vim minus the smooth scrolling and zooming. Meanwhile system default text editors often crawl to a near halt when selecting several rows which are a few thousand columns wide.
- codethief 8y agoNot exactly what you're looking for (I don't see GPU acceleration being mentioned anywhere(¶)) but you might still be interested in Xi (https://github.com/google/xi-editor https://github.com/google/xi-editor). For what it's worth, there's also a terminal emulator with similar goals (GPU acceleration included): https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty (¶) Then again, drawing the text is rarely the bottleneck of a text editor (as the sibling post's author correctly points out). It's usually the data structure to represent the text internally and syntax highlighting that have the greatest influence. (Advanced IDE features like syntax checks, linter and indexing aside.)
- mastax 8y agoGPU acceleration would depend on the Xi frontend. I know that xi-win (https://github.com/google/xi-win https://github.com/google/xi-win) uses Direct2D and DirectComposition. DirectWrite is on the CPU, though, AFAIK. It would be cool to hook it up to pathfinder for a full-stack GPU editor, but I'm not sure it would make a huge difference vs CPU+glyph caching.
- rossy 8y ago> DirectWrite is on the CPU, though, AFAIK. DirectWrite rasterises glyphs on the GPU when used with Direct2D. GPU path rasterisation was Direct2D's killer feature when it was initially released with Windows 7.
- vbezhenar 8y agoYou don't need GPU. You need proper algorithms. I'm using EditPad, it works pretty well with big files. I think there are many editors which work good enough. AFAIK Notepad++ can open large files.
- jolmg 8y agoWhat do you mean by zooming? Increasing the font size? :nmap + :let &guifont=substitute(&guifont, '\d\+$', '\=submatch(0) + 1', '')<cr> :nmap - :let &guifont=substitute(&guifont, '\d\+$', '\=submatch(0) - 1', '')<cr> :nmap _ - With that, you can increase the font size with normal mode +, and decrease it with - or _. EDIT: By the way, what are you doing that requires handling text files with thousands of columns and gigabytes of text? That sounds very unusual.
- rch 8y agoScientific data. Sometimes I forget that a .txt file I'm working with casually in Igor Pro will cause my laptop to seize violently if I accidentally open it with something else.
- deleted 8y ago[deleted]
- jcfrei 8y agoIt's something I would get excited about - not something I absolutely need. In the past decades so much effort has gone into optimizing rendering speeds for computer games or page rendering on browsers while text editors appear to have pretty much stayed the same (rendering wise).
- jolmg 8y agoWell, I can understand optimizing rendering speeds for computer games because the general trend has always been wanting ever more realistic graphics. However, it's surprising to see people want more rendering speed on their text editors, especially to the point that it would excite them. It's something I've never considered them lacking for their purpose. However, that's probably because I've (nearly) never had the need to handle text files with such characteristics (I usually use it for code and configuration files; none get even close to 1MB), and so to me the text editor is among the fastest, lightest programs I typically run. rch mentioned scientific data. I guess it's a valid point that there are people working with huge datasets in a practical text file format, and if there are people that can work with huge images or videos on their editors, then why can't text editors do the same.
- shanselman 8y agoVS Code? No joke.
- badloginagain 8y agoI switched from Sublime to VS Code because it was better at handling giant log files that would kill subl
- thsowers 8y agoReally? I have used sublime for years for log files, Atom and other web based editors would just crash. Hard to imagine that JS would be better at handling viewing large text than C++ (which I think the core of Sublime is written in) Edit: Benchmarks appear to back this up: https://github.com/jhallen/joes-sandbox/tree/master/editor-perf https://github.com/jhallen/joes-sandbox/tree/master/editor-p...
- nojvek 8y agoVScode improved support for handling large files. They don’t even load the whole file in buffer. Load and syntax highlight as you scroll. Pretty smart approach.
- jpeeler 8y agoVisual Studio Code's performance is impressive versus Atom. However, there's always room for improvement and I really hope with the Github acquisition that this next generation Atom project is incorporated: https://github.com/atom/xray https://github.com/atom/xray
- hiccuphippo 8y agoVSCode has a problem when lines have many columns, you are unable to view the end, it can copy them to the clipboard though. I have to wrap when I want to see to the end.
- mikestew 8y agoYou know what could open large files? The editor in Visual FoxPro. Because the devs didn't assume to just load it all in memory and call it a day. No, load the piece you need to display, you can go get more from disk if you need it. Without an install in front of me, I'm pretty sure it was limited to 2Gb, though.
- pkaye 8y agoHow does an editor handle loading from disk and updating when someones inserts to the head of a file? Everything needs to be shifted.
- ars 8y agoYou use a https://en.wikipedia.org/wiki/Rope_(data_structure) https://en.wikipedia.org/wiki/Rope_(data_structure) and not a flat string. You only flatten the string when it's time to write to disk. For autosave files make sure to store the changes to the rope, not the full text.
- lighttower 8y agoThere is a comment somewhere on HN from the guy that wrote the mapping trick that Word (or WordPerfect) invented way back. They were saving changes to the file rather than flattening. I wish I could find it now.
- seiferteric 8y ago
- babak_ap 8y agoHave you tried EmEditor? It handles gigantic files very well, supports CSV editing and more. Two major downsides are: Windows only, not free
- craftyguy 8y agoAlacritty[1] + vim 1. https://github.com/jwilm/alacritty https://github.com/jwilm/alacritty
- princekolt 8y agoFor what is worth, Sublime Text runs on OpenGL[1]. [1]: https://i.imgur.com/u4Hovt1.png https://i.imgur.com/u4Hovt1.png
- wbond 8y agoOpenGL is only used on Mac when the screen resolution is detected as fairly high. We use OpenGL because Core Graphics is too slow to copy the pixel buffer to the screen at 60 fps. We don’t, however, composite the interface using OpenGL. OpenGL is not used on Linux or Windows. Jon explained to me that Sublime Text 1.x (Windows only) was OpenGL, but he ran into so many bugs related to poor drivers that he backed away from OpenGL for ST2 and 3.
- est 8y agoSublime Text has been using OpenGL/DirectUI to render text since beginning. It's insane fast with its minimap and syntax highlight.
- wbond 8y agoWe don’t use GPU acceleration on Windows or Linux, and only on Mac to push pixel buffers to the GPU. All compositing is done in software, and we have our own library for glyph caching.
- watersb 8y agoVisual Studio Code’s terminal is GPU-accelerated [0], a work in progress. [0] https://code.visualstudio.com/blogs/2017/10/03/terminal-renderer https://code.visualstudio.com/blogs/2017/10/03/terminal-rend...
- whazor 8y agoYou do not need a GPU accelerated or highly optimised text editor.. You simply need an editor that does not load the whole file to memory, and potentially preloads some data for smooth scrolling and zooming. Operations should be done in O(1) storage as well.
- CyberDildonics 8y agoGvim can handle gigabytes of text easily.