Hacker News Reader

Comment by whazor | Hacker News Reader

A text editor can use an array as data structure. You only need it to be fast during the typing, where you are only changing one line. But for entering new lines, the extra latency needed for rebuilding the array after pressing enter is not noticeable for several million lines.

The more challenging part of a text editor is making sure you only render what the user sees.

View on HN

And the most challenging part is making a text editor that actually works well from a usability perspective.

Which has almost nothing to do with data structures and optimization. I've used dozens of text editors. I have never once thought "man, that thing is slow". But I have thought "man, that thing is a bug-ridden, unintuitive piece of garbage" many, many times.

> I have never once thought "man, that thing is slow".

You’re either lying or incapable to detect typing latency.

Try typing while CLion indexes stuff in background or open couple hundred thousand line file in VS Code with Vim plugin and let me know how it goes.

That will not be because of an array data structure for the lines.

When properly done, plugins/extensions are in separate process which do not hang the main UI thread. It helps if these processes has a low priority. Also, ionice is good when processing many documents.

Another flaw of many extensions/language servers have, is the lack of abort controller implementation. This means that debouncing doesn't work. So if there are many document updates, the server would hang.

There's a difference between noticing latency and considering it a problem.

My car doesn't go at the speed of sound. That doesn't mean I think "man, this car is slow" each time I drive it.

But if the same car suddenly stops, and I have to open all the doors and close them again in order to keep going, that sure is a problem.

> There's a difference between noticing latency and considering it a problem.

Just because you don't consider it a problem, doesn't mean it's not a problem.

Weren't you the one lamenting about ML having potential to being 100-1000x faster if only there were real™ software engineers to implement them?

> My car doesn't go at the speed of sound. That doesn't mean I think "man, this car is slow" each time I drive it.

This isn't even remotely valid example. Put your car on track against faster cars and you'll quickly arrive to `man, this car is slow`.

I'm sure then you'd be perfectly content if your otherwise perfect car were replaced with one identical in all ways except that the acceleration was 1/4 of the previous rate.

Try re-indenting a large xml file, or something else that will result in a very large number of small deletions and insertions throughout a file. Even on a modern computer the underlying data structures will make the difference between something near instantaneous and the user giving up in despair after a few minutes. A simple array does not cut it.

Formatting a file could be a single operation that creates a single array of lines. Normally the formatter is a separate program that actually gets the input as string and returns a new string as output. So the extra concatenation and splitting would not cost much extra.

The formatting is often difficult enough that it will need a separate data structure anyways.

You must not have used Eclipse back in the day

oh man, this one hurts.

the original Eclipse was so godawful slow, this was back in the days where you would install Textpad after installing Java because it would pick up your classpath during installation and configure it for you. Java 1.4 I think.

or Atom

It is shocking to me how little known the rope data structure [0] and the order statistic tree [1] are. Especially in the context of text editors.

[0]: https://en.wikipedia.org/wiki/Rope_(data_structure) [1]: https://en.wikipedia.org/wiki/Order_statistic_tree

Reply on news.ycombinator.com