4 ms·

Back in the mid 90s I created a shareware text editor that ran on Windows 3.1 (on a 80386 machine) and was written in C++ using pure Win16. At that time I used

by jussij 9y ago

Back in the mid 90s I created a shareware text editor that ran on Windows 3.1 (on a 80386 machine) and was written in C++ using pure Win16. At that time I used a double link list like structure with a line cursor to help with list traversal. While this was not one of the formal text editor design patterns, I found that pattern very worked well.

usrusr 9y ago
Maybe it only worked well because you never encountered a file consisting of one very long line? Back then most somewhat human-readable data formats where line-based. Lines also where the de-facto standard work unit for stream processing so that there was an implicit understanding that a large file without newlines would not be processable as text even if all parts of that line were human readable. This only changed once XML went big which made most newlines a convenience that is frequently omitted in machine to machine communication, a paradigm shift that almost all younger formats followed. Now those m2m versions of optionally linebroken data occasionally hit our editors and make the limitations of lines as the basic unit of text editors painfully noticeable. That being said, I have often seen otherwise reliable editors choke on very long lines, so your former self would still be in good company, even two decades later.
- jussij 9y ago
  > Maybe it only worked well because you never encountered a file consisting of one very long line? You correct when you say very long lines are hard to handle, but I'm not sure this is because of the internal data structure used. In this case the internal data structure allocated a line buffer at every node of the double linked list and even on that Win16 environment that allowed for a line size of up to 64 kBytes (i.e. 2^16) in length. However, to handle tabs correctly the editor is forced to recalculate the column position on every user event and since that calculation has to consider the entire line, the time needed to do this column calculation grows with line length. So the editor could handled long lines but as the line lengths around 500 characters the speed became noticeably slow.
  - eru 9y ago
    You could guess the tab handling with some fast method at first, and asynchronously run the proper handling to catch up with a pause in user input a few seconds later.

by jussij 9y ago

usrusr 9y ago

Maybe it only worked well because you never encountered a file consisting of one very long line? Back then most somewhat human-readable data formats where line-based. Lines also where the de-facto standard work unit for stream processing so that there was an implicit understanding that a large file without newlines would not be processable as text even if all parts of that line were human readable. This only changed once XML went big which made most newlines a convenience that is frequently omitted in machine to machine communication, a paradigm shift that almost all younger formats followed. Now those m2m versions of optionally linebroken data occasionally hit our editors and make the limitations of lines as the basic unit of text editors painfully noticeable. That being said, I have often seen otherwise reliable editors choke on very long lines, so your former self would still be in good company, even two decades later.

jussij 9y ago
> Maybe it only worked well because you never encountered a file consisting of one very long line? You correct when you say very long lines are hard to handle, but I'm not sure this is because of the internal data structure used. In this case the internal data structure allocated a line buffer at every node of the double linked list and even on that Win16 environment that allowed for a line size of up to 64 kBytes (i.e. 2^16) in length. However, to handle tabs correctly the editor is forced to recalculate the column position on every user event and since that calculation has to consider the entire line, the time needed to do this column calculation grows with line length. So the editor could handled long lines but as the line lengths around 500 characters the speed became noticeably slow.
- eru 9y ago
  You could guess the tab handling with some fast method at first, and asynchronously run the proper handling to catch up with a pause in user input a few seconds later.