3 ms·

You're absolutely right and I appreciate the resource! I also think it's not the entire scope of the problem, because I'm getting the same performance reading

by j42 12y ago

You're absolutely right and I appreciate the resource! I also think it's not the entire scope of the problem, because I'm getting the same performance reading the file and performing simple non-regex replaces on those with >10,000 lines (and syntax highlighting off). I've checked the disk as well just to make sure it's not at fault. Sadly this machine is almost slower than my Intel Haswell MBP. This may be an ignorant question, but as a full-stack web developer with moderate C knowledge (I've written real-time bidders and high-IO finance software but never a full GUI app), how would one go about effectively transitioning that knowledge into writing a text editor? I can look up the basic open source libs/bindings and cobble them together but I'm less knowledgeable about the proper way to go about a native UI (which it would have to be because the 'cool' technologies are simply slow). Is the learning curve too steep for a 1yr timeline?

brudgers 12y ago
There are lots of one year or less effort text editors. There are a couple of four decade text editors: Emacs and vim. Really smart people have invested a lot of time in each both in extending them into green fields and working around architectural limitations. Spending a year studying their source code would be a good first research step toward writing a really good editor. That's my take on writing a text editor. The efficiency of a text editor is an XY problem. A text editor is just a tool in a workflow. The workflow is defined by inputs and outputs. If Sublime text shells out into awk or uses MySQL as a preprocessor who cares? There's little practical point in being beholden to a particular text editor if it's in the way. BTW, googling up "efficiency of sublime regex engine" provides some indication that Sublime chokes on modest json data. Then again, json data serializes to text, but it can easily be interpreted as data by a database engine. General tools are great, but knowing the specifics about the data allows for creating useful heuristics to guide workflows.

by j42 12y ago

brudgers 12y ago

There are lots of one year or less effort text editors. There are a couple of four decade text editors: Emacs and vim. Really smart people have invested a lot of time in each both in extending them into green fields and working around architectural limitations. Spending a year studying their source code would be a good first research step toward writing a really good editor. That's my take on writing a text editor. The efficiency of a text editor is an XY problem. A text editor is just a tool in a workflow. The workflow is defined by inputs and outputs. If Sublime text shells out into awk or uses MySQL as a preprocessor who cares? There's little practical point in being beholden to a particular text editor if it's in the way. BTW, googling up "efficiency of sublime regex engine" provides some indication that Sublime chokes on modest json data. Then again, json data serializes to text, but it can easily be interpreted as data by a database engine. General tools are great, but knowing the specifics about the data allows for creating useful heuristics to guide workflows.