4 ms·

Honestly very good article - are anyone aware of a similar type of tutorial for OSX that covers small to huge text file editing?

valleyer 10y ago
TextEdit, the actual editor that ships on macOS, is open source. https://developer.apple.com/library/content/samplecode/TextEdit/Introduction/Intro.html https://developer.apple.com/library/content/samplecode/TextE... Nearly all of the load is shouldered by the Cocoa text system.
- imron 10y ago
  And it's not very good with huge text files and long lines.
  - dingdingdang 10y ago
    Yep, this is the problem, just because its bare metal sys-call wise does not mean it does partial/incremental loading correctly! :/
    - imron 10y ago
      Incremental loading is one of the things I dislike about the native cocoa text/document components - especially if you have a large file and want to scroll to the end. Scroll and wait. Scroll and wait. Scroll and wait. You can use the same basic techniques presented in the original article for loading large files instantly on macOS (I did), and then use Core Text APIs for rendering the actual text instead of the Win32 API calls. You need to use Core Text APIs over the NS equivalent, or at least you do if you want to handle text with long lines, because all the NS* eventually gets down to Core Text and one of the functions (I forget which one, but likely CTTypesetterCreateWithAttributedString) becomes noticeably sluggish when processing long lines (think > 10k characters per line), especially if most of that text might not even be appearing on the screen. At least it does for Chinese, not sure about other scripts. However if you break that same 10k chunk up in to a bunch of smaller text chunks first, and stop once you get off the visible screen, the combined time of processing each chunk is significantly less than processing them as a single piece of text. Checking my source code, I've currently got the maximum length to split on set at 1,024 and that works quite well.
JadeNB 10y ago
It's not a tutorial, but Ridiculous Fish wrote about his experience writing Hex Fiend (https://www.google.com/&q=site:ridiculousfish.com%2Fblog+%22hex+fiend%22 https://www.google.com/&q=site:ridiculousfish.com%2Fblog+%22... ); see, for example, http://ridiculousfish.com/blog/posts/old-age-and-treachery.html http://ridiculousfish.com/blog/posts/old-age-and-treachery.h... .

valleyer 10y ago

TextEdit, the actual editor that ships on macOS, is open source. https://developer.apple.com/library/content/samplecode/TextEdit/Introduction/Intro.html https://developer.apple.com/library/content/samplecode/TextE... Nearly all of the load is shouldered by the Cocoa text system.

imron 10y ago
And it's not very good with huge text files and long lines.
- dingdingdang 10y ago
  Yep, this is the problem, just because its bare metal sys-call wise does not mean it does partial/incremental loading correctly! :/
  - imron 10y ago
    Incremental loading is one of the things I dislike about the native cocoa text/document components - especially if you have a large file and want to scroll to the end. Scroll and wait. Scroll and wait. Scroll and wait. You can use the same basic techniques presented in the original article for loading large files instantly on macOS (I did), and then use Core Text APIs for rendering the actual text instead of the Win32 API calls. You need to use Core Text APIs over the NS equivalent, or at least you do if you want to handle text with long lines, because all the NS* eventually gets down to Core Text and one of the functions (I forget which one, but likely CTTypesetterCreateWithAttributedString) becomes noticeably sluggish when processing long lines (think > 10k characters per line), especially if most of that text might not even be appearing on the screen. At least it does for Chinese, not sure about other scripts. However if you break that same 10k chunk up in to a bunch of smaller text chunks first, and stop once you get off the visible screen, the combined time of processing each chunk is significantly less than processing them as a single piece of text. Checking my source code, I've currently got the maximum length to split on set at 1,024 and that works quite well.

JadeNB 10y ago

It's not a tutorial, but Ridiculous Fish wrote about his experience writing Hex Fiend (https://www.google.com/&q=site:ridiculousfish.com%2Fblog+%22hex+fiend%22 https://www.google.com/&q=site:ridiculousfish.com%2Fblog+%22... ); see, for example, http://ridiculousfish.com/blog/posts/old-age-and-treachery.html http://ridiculousfish.com/blog/posts/old-age-and-treachery.h... .