Apparently it's not the "node" cask anymore in the base CI image,
it's the "node@20" cask. Wow.
The workaround of uninstalling this is still needed,
it's just that the package name has changed.
…especially syntax highlighting.
This change brings in `morphdom` to allow us to be more efficient about how we apply the changes needed when the Markdown source re-renders. Instead of replacing all the content with every single change, we apply only the selective edits needed to adapt our existing markup to the target markup.
Once this process is done, we introduce one `TextEditor` instance for each `pre` tag in the markup, then persist those editor elements in the rendered output so that we don't have to spend so much time creating and destroying editors. This is a _huge_ performance win, especially in documents with lots of code blocks. The editor instances are cached using the `pre` elements as keys, which is now possible because the `pre` elements themselves are preserved across re-renders.
Editors are created when new `pre` elements appear, and are destroyed when they are no longer needed, change their contents whenever the contents of the `pre` changes, and change language modes whenever the code fence language identifier changes.
This approach is now used no matter which Markdown renderer is employed; we manage syntax highlighting ourselves in all cases rather than letting `atom.ui.markdown` do it.
There is an issue with the libiconv library not being available
in macOS 14 out of the box. We can get it from Homebrew perhaps,
but for now pin to macos-12 runner images so we can be assured
of having working CI faster, without having to R&D a libiconv-
related workaround for macOS 14.
This PR is basically to add some debugging info for providers and
consumers. Currently, when a package registers as a service provider or
a service consumer, and doesn't actually implements the right interface
(a function, basically) the package loader silently ignores it. This
commit adds a warning to console so that we know a package did the wrong
thing.
Most of these were old versions of actions
which were running on Node 16. Upgraded them to newer versions
which run on Node 20 instead.
Also tried to replace setup-xvfb action with a direct xvfb-run command.
Let's hope this works.
Odd this wasn't caught in our initial specs. But this issue only effects specs, as the actual production code is able to assign the callback with a function reference rather than a string which is then used to assign the callback itself.