TLDR: Typically this means the calls to Add should execute before the statement creating the goroutine or other event to be waited for — WaitGroup Docs
…and here it is the way I originally wrote it. The below code is WRONG don’t use.
The correct way is documented but without running into the issue the documentation didn’t register with me that the above code is wrong and won’t work.
That’s all really. Hoping it prevents the issue for someone else trying to make go wrappers to handle goroutines.
In part 3 we discussed syntax matching and file type detection. Here we are going to discuss layers. The thing that brought us to this dance.
In Part 1 we specified this goal: Allow layers (modes) to be defined and the behavior when entering, leaving, and interacting with to be specified. To review, the concept of layers came from a keyboard that I purchased that allows key combinations to change the “layer” of the keyboard changing how keys are interpreted when pressed. Vi has the same concepts baked in. With concepts like Insert, Normal, and Replace modes.
What we want…
In Part 2 we talked about Undoing, Cursor, and Text Objects. In this installment, we’ll start talking about the syntax highlighter. If it hasn’t already become clear we are not trying to build an editor per se, but instead, a toolkit that one or more tools can be used in text editing projects.
Let’s start with a small detour. To do syntax highlighting and detection we first need to know what the syntax of the text is. This is generally handled by file type detection.
To start with we just use extensions. …
In Part 1 we covered some of the project goals as well as the basic interface for text storage. Let’s take a side road and talk a little about undo.
Undo is another feature that is easy, hard. If we keep each version of the document as changes occur and then replace the document with the previous version when we undo, simple. Of course, if we have a 20Mb file that we keep a copy of each time a character is typed is going to be a bit of a resource problem. OK, let’s step back and look at the…
This is a really good question. VS Code, Sublime, Atom, or the venerable vim and emacs, there seem to be plenty of great editors to choose from. Well, I understand things much better if I pull them apart and try and build my own. So let’s go with this being a way to get better at text editing… I have played with this on and off for years, learning new bits as I go along. I have built nearly fully functional editors only to rip them up and keep a few bits.
Code editors are much harder and much easier…