4 ms·

Probably an unpopular opinion but... Write your own text editor. I've been working on my own (https://github.com/alefore/edge https://github.com/alefore/edge)

by afc 6y ago

Probably an unpopular opinion but... Write your own text editor. I've been working on my own (https://github.com/alefore/edge https://github.com/alefore/edge) as a side project and using it exclusively for about six years. I don't expect it to be very usable by other people (it's very customized for my workflows, I suppose; e.g., it's mostly useful for writing C++ and Markdown files) but, because I know it inside out (and I've invested in making it easy to customize through its extension language), it's very easy for me to adjust it to behave exactly the way I want it, which allows me to lower the friction for any operations I care about (and it abides very exactly to my principles/expectations for how an editor should behave; e.g. never block the main thread/UI while executing some operation such as opening a file). Because I don't have to use but a small set of computers directly (mostly my laptop and my workstation), this works well enough. I don't know if overall it'll save me more time than it has taken me to implement it, but I do believe it allows me to move significantly faster than if I still used Vim or Emacs (or than most of my team mates), especially because it allows me to operate at a higher semantic level than otherwise, eliminating distractions from lower level details. ... and, I guess, it has been a lot of fun to implement it (and I've probably learned a bunch). I think it has played a role for me similar to that videogames have played for some of my friends (e.g., this weekend's challenge may be to generate visualizations for the logs I keep for every interaction I have with each file I've edited; implementing stuff like that feels similar to how in the past I felt about making progress in some videogames).

themodelplumber 6y ago
I'm so glad to see this comment. I recently got to the point where I created a text-viewer. Then I realized: This is the weak-sauce version of just admitting I need to write my own editor. My toolset is kind of weird conceptually so nobody else has created "my" editor yet. Haha :-) Thanks for sharing your experience.
- afc 6y ago
  Thank you for your response. I think most people here would disagree, but... I'd totally encourage you to go this route. It has been very fruitful for me.
applecrazy 6y ago
Genuine question: do you think that writing your own editor was a better investment than extensively customizing an existing editor like Vim or Emacs (even going so far as to change the keybinds and UI)?
- afc 6y ago
  Good question. I guess I'll never know for sure. I believe it has been worth it for me, as there are several things I can do now that I'm not sure whether I'd have been able to achieve by customizing them (unless you include "rewriting their source code extensively" as customizing them; but at that point I think I'd be roughly doing the same as what I did?). I'll give three examples: 1. Being able to run edge -view=all src/*.cc This loads all those files, splits the screen, showing all matching files (up to a minimum area for each, with "Additional files: 498" (not shown) at the bottom), and lets me modify all files simultaneously (e.g., "search for a given regexp, make all cursors active, advance 5 words, delete to end of line, save all files, quit). I just recorded an example of that (where I'm just renaming "OpenBuffer" to "Buffer"; you can trivially do that with Perl, but obviously you could do much more than just a simple regexp replace): https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad These are things that even heavy Emacs/Vim users would typically do through sed/awk/perl; I see that as a limitation in their editors (since you wouldn't use the same sed/awk/perl technique if you're just going to edit a single file). 2. I've supported multiple cursors (within one buffer) natively for a while (and I use it very often; for example, searching for a regular expression just leaves a cursor in each occurrence). I guess I'd have been able to accomplish things like this, but I'm not sure of the quality of the results. In other words, I feel that it would have to rely on putting a lot of complexity in extensions and I'd guess that it would be too brittle and difficult to maintain. There are probably extensions for these things for Vim and Emacs, but I would be slightly worried that they may not integrate very well with other features and may brittle. But I don't really know. 3. I also got fed up that these editors would block on most operations (such as when you typed ":make" in Vim or when you opened a file from a networked file system); my editor never stops responding to user commands (rather, it simply visually indicates that it is executing something; perhaps you'll see side-effects as they occur). For example, here is how "make" works (you'll see me switching back and forth; most of the time you'll see the dots next to "make" (at the bottom line) moving, reflecting make's progress; in case it helps understand what's going on, I save the file, which causes "make" to be killed and restarted): https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N I bet you can make Vim/Emacs operate this way (compile asynchronously, overlay errors with the files (as you can see around second 0:31); be able to nest commands with a pts within them, so that you can use them as you'd use tmux/screen). I'm not sure you make them load/save files asynchronously, never blocking? Those are the examples. When I started I was a heavy Vim user, but I got fed up of having to edit vim syntax, which I considered a, hmm, suboptimal programming language (yes, I'm aware that there are bindings for nearly every language under the sun, but still). I considered Lisp slightly preferable (and at the time I was still somewhat enamored with Scheme; I had been contributing some ~important modules to the Chicken Scheme implementation; these days I'll go to great lengths to avoid coding in languages that make static typing difficult, mostly because I don't think I'm smart enough to use them successfully for large/complex enough projects), but I was more into Vim than into Emacs. But I felt like it ought to be possible to do better than either. I felt that they suffered from carrying a lot of assumptions that were valid in the 90s (or earlier, perhaps 70s) but no longer applied, so I wanted to see how far one could go and experiment. For example, as the user is typing, between each keystroke, something like ... hundreds of milliseconds pass. That's an incredibly long time for a computer! However, these editors mostly just sit idly, waiting for the next keystroke, not doing anything. My philosophy is completely different: burn as much CPU as you want, as long as you can give me something useful in return (and as long as you never stop responding). In other words, do whatever you can to maximize the value for the user. You can see an example of the type of things I mean in the prompts in the above recordings: - In the 1st recording (https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad), around second 0:16, where I start typing a search regexp. As I type, the editor tells me things like "this would match 394 positions; in 32 buffers; and there's 2 search patterns in the search history that this matches". - In the 2nd recording (https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N) around second 0:12, where I start typing a path (of a file to open). The editor scans the filesystem (asynchronously, obviously) and history log and tells me something like "you've typed `buffer_` so far; this matches 17 files (in all registered search paths) and 8 entries in this prompt's history". (The key point is that all this functionality is asynchronous so it never blocks the user. If you type the next character as it is still scanning something, it just throws away those partial results (I'm somewhat simplifying; it's a bit smarter than that).) You can probably achieve these things with extensions for Emacs/Vim, but I'd guess you'd still be somewhat limited by assumptions they make? At the point where I'd be basically rewriting most of their source code ... I think it'd have been a significantly longer route (because I'd probably have had to care for a lot of additional things that are irrelevant to me). Anyhow, to wrap up (sorry for the long rant!), this has been a great experience for me. I've learned a lot (e.g., I think I have more informed opinions about things like fuzz-testing, or the use of settable futures vs continuation-passing-style vs callback spaghetti) and I'm somewhat doubtful I would have been able to achieve so much through my own custom extensions for existing editors. Thanks for asking the question. :-)
omaranto 6y ago
> Write your own text editor. This is what a lot of us Emacs users do, with the advantage that we have a huge base to start from.
pengaru 6y ago
This should be more generalized to "write your own tools that suit your workflow and use them, iterating on them as usual."
- stevekemp 6y ago
  Writing tools, and updating your dotfiles with helpers/shortcuts is absolutely useful. I had a small collection of useful utilities become somewhat popular on github, even though I mostly published them so I had somewhere central to install from. These days I've been reworking them into a single binary so that I can deploy them even more easily: https://github.com/skx/sysbox https://github.com/skx/sysbox That, coupled with my dotfiles (mostly a literate emacs config written in markdown), makes me pretty productive when moving to new systems.
winrid 6y ago
A better way to put it would be "know your editor and environment"
- jonnypotty 6y ago
  I agree. So many times I've blamed software for not doing a thing, then _actually_ read guides and documentation and find out it's me that's the idiot, not the software Devs. Over and over again.
toohotatopic 6y ago
This has been put to the extreme by Chuck Moore [1] > During the 1990s, he used his own CAD software to design several custom VLSI chips, including the F21 processor with a network interface. More recently, he invented colorForth and ported his VLSI design tools to it [1] http://www.greenarraychips.com/home/about/bios.html http://www.greenarraychips.com/home/about/bios.html

by afc 6y ago

themodelplumber 6y ago

I'm so glad to see this comment. I recently got to the point where I created a text-viewer. Then I realized: This is the weak-sauce version of just admitting I need to write my own editor. My toolset is kind of weird conceptually so nobody else has created "my" editor yet. Haha :-) Thanks for sharing your experience.

afc 6y ago
Thank you for your response. I think most people here would disagree, but... I'd totally encourage you to go this route. It has been very fruitful for me.

applecrazy 6y ago

Genuine question: do you think that writing your own editor was a better investment than extensively customizing an existing editor like Vim or Emacs (even going so far as to change the keybinds and UI)?

afc 6y ago
Good question. I guess I'll never know for sure. I believe it has been worth it for me, as there are several things I can do now that I'm not sure whether I'd have been able to achieve by customizing them (unless you include "rewriting their source code extensively" as customizing them; but at that point I think I'd be roughly doing the same as what I did?). I'll give three examples: 1. Being able to run edge -view=all src/*.cc This loads all those files, splits the screen, showing all matching files (up to a minimum area for each, with "Additional files: 498" (not shown) at the bottom), and lets me modify all files simultaneously (e.g., "search for a given regexp, make all cursors active, advance 5 words, delete to end of line, save all files, quit). I just recorded an example of that (where I'm just renaming "OpenBuffer" to "Buffer"; you can trivially do that with Perl, but obviously you could do much more than just a simple regexp replace): https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad These are things that even heavy Emacs/Vim users would typically do through sed/awk/perl; I see that as a limitation in their editors (since you wouldn't use the same sed/awk/perl technique if you're just going to edit a single file). 2. I've supported multiple cursors (within one buffer) natively for a while (and I use it very often; for example, searching for a regular expression just leaves a cursor in each occurrence). I guess I'd have been able to accomplish things like this, but I'm not sure of the quality of the results. In other words, I feel that it would have to rely on putting a lot of complexity in extensions and I'd guess that it would be too brittle and difficult to maintain. There are probably extensions for these things for Vim and Emacs, but I would be slightly worried that they may not integrate very well with other features and may brittle. But I don't really know. 3. I also got fed up that these editors would block on most operations (such as when you typed ":make" in Vim or when you opened a file from a networked file system); my editor never stops responding to user commands (rather, it simply visually indicates that it is executing something; perhaps you'll see side-effects as they occur). For example, here is how "make" works (you'll see me switching back and forth; most of the time you'll see the dots next to "make" (at the bottom line) moving, reflecting make's progress; in case it helps understand what's going on, I save the file, which causes "make" to be killed and restarted): https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N I bet you can make Vim/Emacs operate this way (compile asynchronously, overlay errors with the files (as you can see around second 0:31); be able to nest commands with a pts within them, so that you can use them as you'd use tmux/screen). I'm not sure you make them load/save files asynchronously, never blocking? Those are the examples. When I started I was a heavy Vim user, but I got fed up of having to edit vim syntax, which I considered a, hmm, suboptimal programming language (yes, I'm aware that there are bindings for nearly every language under the sun, but still). I considered Lisp slightly preferable (and at the time I was still somewhat enamored with Scheme; I had been contributing some ~important modules to the Chicken Scheme implementation; these days I'll go to great lengths to avoid coding in languages that make static typing difficult, mostly because I don't think I'm smart enough to use them successfully for large/complex enough projects), but I was more into Vim than into Emacs. But I felt like it ought to be possible to do better than either. I felt that they suffered from carrying a lot of assumptions that were valid in the 90s (or earlier, perhaps 70s) but no longer applied, so I wanted to see how far one could go and experiment. For example, as the user is typing, between each keystroke, something like ... hundreds of milliseconds pass. That's an incredibly long time for a computer! However, these editors mostly just sit idly, waiting for the next keystroke, not doing anything. My philosophy is completely different: burn as much CPU as you want, as long as you can give me something useful in return (and as long as you never stop responding). In other words, do whatever you can to maximize the value for the user. You can see an example of the type of things I mean in the prompts in the above recordings: - In the 1st recording (https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad https://asciinema.org/a/XNbNGL38kOrok2HO7zrarrQad), around second 0:16, where I start typing a search regexp. As I type, the editor tells me things like "this would match 394 positions; in 32 buffers; and there's 2 search patterns in the search history that this matches". - In the 2nd recording (https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N https://asciinema.org/a/es4O4UdxPzB0vl7Tr88TKlq9N) around second 0:12, where I start typing a path (of a file to open). The editor scans the filesystem (asynchronously, obviously) and history log and tells me something like "you've typed `buffer_` so far; this matches 17 files (in all registered search paths) and 8 entries in this prompt's history". (The key point is that all this functionality is asynchronous so it never blocks the user. If you type the next character as it is still scanning something, it just throws away those partial results (I'm somewhat simplifying; it's a bit smarter than that).) You can probably achieve these things with extensions for Emacs/Vim, but I'd guess you'd still be somewhat limited by assumptions they make? At the point where I'd be basically rewriting most of their source code ... I think it'd have been a significantly longer route (because I'd probably have had to care for a lot of additional things that are irrelevant to me). Anyhow, to wrap up (sorry for the long rant!), this has been a great experience for me. I've learned a lot (e.g., I think I have more informed opinions about things like fuzz-testing, or the use of settable futures vs continuation-passing-style vs callback spaghetti) and I'm somewhat doubtful I would have been able to achieve so much through my own custom extensions for existing editors. Thanks for asking the question. :-)

omaranto 6y ago

> Write your own text editor. This is what a lot of us Emacs users do, with the advantage that we have a huge base to start from.

pengaru 6y ago

This should be more generalized to "write your own tools that suit your workflow and use them, iterating on them as usual."

stevekemp 6y ago
Writing tools, and updating your dotfiles with helpers/shortcuts is absolutely useful. I had a small collection of useful utilities become somewhat popular on github, even though I mostly published them so I had somewhere central to install from. These days I've been reworking them into a single binary so that I can deploy them even more easily: https://github.com/skx/sysbox https://github.com/skx/sysbox That, coupled with my dotfiles (mostly a literate emacs config written in markdown), makes me pretty productive when moving to new systems.

winrid 6y ago

A better way to put it would be "know your editor and environment"

jonnypotty 6y ago
I agree. So many times I've blamed software for not doing a thing, then _actually_ read guides and documentation and find out it's me that's the idiot, not the software Devs. Over and over again.

toohotatopic 6y ago

This has been put to the extreme by Chuck Moore [1] > During the 1990s, he used his own CAD software to design several custom VLSI chips, including the F21 processor with a network interface. More recently, he invented colorForth and ported his VLSI design tools to it [1] http://www.greenarraychips.com/home/about/bios.html http://www.greenarraychips.com/home/about/bios.html