3 ms·

And in fact even the "simplest" editors seemed to take quite some time even for our heroes. Ken Thompson has stated [1] that he devoted a week out of a month fo

And in fact even the "simplest" editors seemed to take quite some time even for our heroes. Ken Thompson has stated [1] that he devoted a week out of a month for what I understand was the first version of ed(1): [...] [my wife] was gone a month to California and I allocated a week each to the shell, to the operating system, the shell, the editor, and the assembler, to reproduce itself [...] [1] https://www.princeton.edu/~hos/mike/transcripts/thompson.htm https://www.princeton.edu/~hos/mike/transcripts/thompson.htm

bombcar 5y ago
An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.
- DonHopkins 5y ago
  Mind the gap! https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... https://en.wikipedia.org/wiki/Gap_buffer https://en.wikipedia.org/wiki/Gap_buffer
- vardump 5y ago
  Weird. First idea that came to my mind was to use a linked list of lines.
  - arc-in-space 5y ago
    Close, but not ideal - lines are occasionally very long, and you're wasting nodes on sequences of newlines. There's a number of useful data structures that can do this well, like a 'rope'.
  - ahefner 5y ago
    It works. Many editors have used this approach.
  - dvfjsdhgfv 5y ago
    What would you use for a line?
- mnw21cam 5y ago
  There's a very simple algorithm to deal with that. You make a buffer that is bigger than the file being edited. You copy the start of the file to the beginning of the buffer, and the end of the file to the end of the buffer. The gap in the middle is where the cursor is. Then each keystroke by the user is a very quick operation. If the user types in so much information that the gap closes up, then you need to do a buffer expand operation and copy large amounts of data around, but that won't happen very often. Ah, darn. That'll teach me to comment without refreshing the page first. I refer you to the earlier DonHopkins post.
- bjoli 5y ago
  Today I would probably reach for an RRB tree and define some kind of simple heuristic for transients, giving me free undo/redo, and reasonably simple support for multiple cursors. Back then a gap buffer seems like a great idea. Two linked lists is a simple enough idea.
  - DonHopkins 5y ago
    Kudos to you for supporting multiple cursors from the start, which a buffer with a gap can't support efficiently. Douglas Englebart would have approved! https://en.wikipedia.org/wiki/Collaborative_real-time_editor https://en.wikipedia.org/wiki/Collaborative_real-time_editor >History of key products: The first instance of a collaborative real-time editor was demonstrated by Douglas Engelbart in 1968, in The Mother of All Demos. Widely available implementations of the concept took decades to appear. https://news.ycombinator.com/item?id=21757797 https://news.ycombinator.com/item?id=21757797 Vis-à-vis mamelons, Ted Selker (who invented the Trackpoint) actually build a prototype Thinkpad keyboard with TWO Trackpoints, which he loved to show at his New Paradigms for Using Computers workshop at IBM Almaden Research Lab. While I'm not sure if this video of the 1995 New Paradigms for Using Computers workshop actually shows a dual-nippled Thinkpad, it does include a great talk by Doug Engelbart (14:22), and quite a few other interesting people! (James Gosling of Sun Microsystems talks about capabilities of Sun's new web browser HotJava, at 24:36! A classic!) https://www.youtube.com/watch?v=oD9NUWDCyHI https://www.youtube.com/watch?v=oD9NUWDCyHI The multi-Trackpoint keyboard was extremely approachable and attractive, and everybody who saw them instantly wanted to get their hands on them and try them out! (But you had to keep them away from babies.) He made a lot of different prototypes over time, but unfortunately IBM never shipped a Thinkpad with two nipples. That was because OS/2 (and every other contemporary operating system and window system and application) had no idea how to handle two cursors at the same time, so it would have required rewriting all the applications and gui toolkits and window systems from the ground up to support dual trackpoints. The failure to inherently support multiple cursors by default was one of Doug Engelbart's major disappointments about mainstream non-collaborative user interfaces, because collaboration was the whole point of NLS/Augment, so multiple cursors weren't a feature so much as a symptom. Bret Victor discussed it in a few words on Doug Engelbart that he wrote on the day of his death: http://worrydream.com/Engelbart/ http://worrydream.com/Engelbart/ >Say you bring up his 1968 demo on YouTube and watch a bit. At one point, the face of a remote collaborator, Bill Paxton, appears on screen, and Engelbart and Paxton have a conversation. >"Ah!", you say. "That's like Skype!" >Then, Engelbart and Paxton start simultaneously working with the document on the screen. >"Ah!", you say. "That's like screen sharing!" >No. It is not like screen sharing at all. >If you look closer, you'll notice that there are two individual mouse pointers. Engelbart and Paxton are each controlling their own pointer. >"Okay," you say, "so they have separate mouse pointers, and when we screen share today, we have to fight over a single pointer. That's a trivial detail; it's still basically the same thing." >No. It is not the same thing. At all. It misses the intent of the design, and for a research system, the intent matters most. >Engelbart's vision, from the beginning, was collaborative. His vision was people working together in a shared intellectual space. His entire system was designed around that intent. >From that perspective, separate pointers weren't a feature so much as a symptom. It was the only design that could have made any sense. It just fell out. The collaborators both have to point at information on the screen, in the same way that they would both point at information on a chalkboard. Obviously they need their own pointers. >Likewise, for every aspect of Engelbart's system. The entire system was designed around a clear intent. >Our screen sharing, on the other hand, is a bolted-on hack that doesn't alter the single-user design of our present computers. Our computers are fundamentally designed with a single-user assumption through-and-through, and simply mirroring a display remotely doesn't magically transform them into collaborative environments. >If you attempt to make sense of Engelbart's design by drawing correspondences to our present-day systems, you will miss the point, because our present-day systems do not embody Engelbart's intent. Engelbart hated our present-day systems.

bombcar 5y ago

An editor seems insanely simple until you realize that computers really don't like "inserting" data into existing data in memory, and then you're staring down the barrel of continuous memcpys.

DonHopkins 5y ago
Mind the gap! https://www.gnu.org/software/emacs/manual/html_node/elisp/Buffer-Gap.html https://www.gnu.org/software/emacs/manual/html_node/elisp/Bu... https://en.wikipedia.org/wiki/Gap_buffer https://en.wikipedia.org/wiki/Gap_buffer
vardump 5y ago
Weird. First idea that came to my mind was to use a linked list of lines.
- arc-in-space 5y ago
  Close, but not ideal - lines are occasionally very long, and you're wasting nodes on sequences of newlines. There's a number of useful data structures that can do this well, like a 'rope'.
- ahefner 5y ago
  It works. Many editors have used this approach.
- dvfjsdhgfv 5y ago
  What would you use for a line?
mnw21cam 5y ago
There's a very simple algorithm to deal with that. You make a buffer that is bigger than the file being edited. You copy the start of the file to the beginning of the buffer, and the end of the file to the end of the buffer. The gap in the middle is where the cursor is. Then each keystroke by the user is a very quick operation. If the user types in so much information that the gap closes up, then you need to do a buffer expand operation and copy large amounts of data around, but that won't happen very often. Ah, darn. That'll teach me to comment without refreshing the page first. I refer you to the earlier DonHopkins post.
bjoli 5y ago
Today I would probably reach for an RRB tree and define some kind of simple heuristic for transients, giving me free undo/redo, and reasonably simple support for multiple cursors. Back then a gap buffer seems like a great idea. Two linked lists is a simple enough idea.
- DonHopkins 5y ago
  Kudos to you for supporting multiple cursors from the start, which a buffer with a gap can't support efficiently. Douglas Englebart would have approved! https://en.wikipedia.org/wiki/Collaborative_real-time_editor https://en.wikipedia.org/wiki/Collaborative_real-time_editor >History of key products: The first instance of a collaborative real-time editor was demonstrated by Douglas Engelbart in 1968, in The Mother of All Demos. Widely available implementations of the concept took decades to appear. https://news.ycombinator.com/item?id=21757797 https://news.ycombinator.com/item?id=21757797 Vis-à-vis mamelons, Ted Selker (who invented the Trackpoint) actually build a prototype Thinkpad keyboard with TWO Trackpoints, which he loved to show at his New Paradigms for Using Computers workshop at IBM Almaden Research Lab. While I'm not sure if this video of the 1995 New Paradigms for Using Computers workshop actually shows a dual-nippled Thinkpad, it does include a great talk by Doug Engelbart (14:22), and quite a few other interesting people! (James Gosling of Sun Microsystems talks about capabilities of Sun's new web browser HotJava, at 24:36! A classic!) https://www.youtube.com/watch?v=oD9NUWDCyHI https://www.youtube.com/watch?v=oD9NUWDCyHI The multi-Trackpoint keyboard was extremely approachable and attractive, and everybody who saw them instantly wanted to get their hands on them and try them out! (But you had to keep them away from babies.) He made a lot of different prototypes over time, but unfortunately IBM never shipped a Thinkpad with two nipples. That was because OS/2 (and every other contemporary operating system and window system and application) had no idea how to handle two cursors at the same time, so it would have required rewriting all the applications and gui toolkits and window systems from the ground up to support dual trackpoints. The failure to inherently support multiple cursors by default was one of Doug Engelbart's major disappointments about mainstream non-collaborative user interfaces, because collaboration was the whole point of NLS/Augment, so multiple cursors weren't a feature so much as a symptom. Bret Victor discussed it in a few words on Doug Engelbart that he wrote on the day of his death: http://worrydream.com/Engelbart/ http://worrydream.com/Engelbart/ >Say you bring up his 1968 demo on YouTube and watch a bit. At one point, the face of a remote collaborator, Bill Paxton, appears on screen, and Engelbart and Paxton have a conversation. >"Ah!", you say. "That's like Skype!" >Then, Engelbart and Paxton start simultaneously working with the document on the screen. >"Ah!", you say. "That's like screen sharing!" >No. It is not like screen sharing at all. >If you look closer, you'll notice that there are two individual mouse pointers. Engelbart and Paxton are each controlling their own pointer. >"Okay," you say, "so they have separate mouse pointers, and when we screen share today, we have to fight over a single pointer. That's a trivial detail; it's still basically the same thing." >No. It is not the same thing. At all. It misses the intent of the design, and for a research system, the intent matters most. >Engelbart's vision, from the beginning, was collaborative. His vision was people working together in a shared intellectual space. His entire system was designed around that intent. >From that perspective, separate pointers weren't a feature so much as a symptom. It was the only design that could have made any sense. It just fell out. The collaborators both have to point at information on the screen, in the same way that they would both point at information on a chalkboard. Obviously they need their own pointers. >Likewise, for every aspect of Engelbart's system. The entire system was designed around a clear intent. >Our screen sharing, on the other hand, is a bolted-on hack that doesn't alter the single-user design of our present computers. Our computers are fundamentally designed with a single-user assumption through-and-through, and simply mirroring a display remotely doesn't magically transform them into collaborative environments. >If you attempt to make sense of Engelbart's design by drawing correspondences to our present-day systems, you will miss the point, because our present-day systems do not embody Engelbart's intent. Engelbart hated our present-day systems.