📆 Meeting notes & project updates (June 2022)

[phillco]

Each meeting will be posted as a comment, with summaries of what we did, and what we plan to do next time.

6/4/22

Progress:

• @rntz gets hats (black squares) rendering an Emacs based on the Cursorless JSON file
• @phillco cleans up/pushes up https://github.com/phillco/cursorless-sidecar

Next steps:

• @rntz: render all hats, try setting up sidecar extension
• @phillco: write current buffer to temporary file; set up versioning

[phillco]

Between meeting progress:

• @phillco merges up https://github.com/phillco/cursorless with big upstream change
• @rntz gets multicolored hats:

[phillco]

6/11/22

Progress made:

• @rntz implements watching the hats file in Emacs, and then standardizing the paths that sidecar watches so they can be consistent across both editors: cursorless-everywhere/sidecar@08c532d. Hats now change in Emacs in response to cursor/file changes!
• @phillco added some basic documentation to https://github.com/phillco/cursorless-everywhere/blob/main/README.md
• @pokey gave us some VS Code plugin development lessons:
  • Use the "Debug Console" view/command when developing to see logs.
  • Under the "breakpoints" section, you can check "Uncaught Exceptions" to automatically break on any uncaught exception. Note that this includes exceptions from other plugins so it could be noisy.
  • "View Developer Tools" will show the equivalent of the Chrome developer tools, which you can use to see errors in the production instance of VS Code (i.e. if you're not running in debug mode). console.log() calls should appear here as well.
  • Eventually we'll need to debug with both extensions (Cursorless fork and the sidecar) running at the same time. What's the best way to do that?
    • The debug instance inherits all plugins from the root instance (except for the plugin being developed), so as long as you have the Cursorless fork installed in your main instance, it will copy over. So there can be some flow of "install the latest version of the other plugin into your main instance, and then debug the plugin you're working on"
    • You can also tweak the environment that gets run when you run "Debug" via --extensions-dir. You can copy extra extensions into that directory to control the state.
      • VS Code will also automatically ignore the plugin being developed if it's in that folder, which makes things simpler. Examples from Cursorless:
        • https://github.com/cursorless-dev/cursorless/blob/33d0a8fe266a9100ab8d29f4c3d2547cf692a9e2/src/test/initLaunchSandbox.ts#L26
        • https://github.com/cursorless-dev/cursorless/blob/33d0a8fe266a9100ab8d29f4c3d2547cf692a9e2/.vscode/launch.json#L14
  • Is there a way to make code --install-extension <path>.vsix less flaky? Answer: not really. Pokey hasn't seen much flakiness himself.

Next steps:

• @rntz + @phillco: write the buffer contents to a temporary file and have VS Code load that, so as you make changes in the superior editor they no longer get out of sync immediately
• @phillco: write up a quick wiki article on the sidecar strategy so people know WTF we're trying to do here
• @phillco: clean up/publish JetBrains extension (make the source code public)
• Either: think about making the sidecar be a completely isolated version of VS Code (e.g. with --extensions-dir) so you don't have to install everything into your production VS Code installation.
  • Given that we need to use VS Code itself to debug the plugins, it seems like we don't want risk breaking them if we make bad changes in the sidecar/Cursorless fork extension.
  • It also seems like this will inevitably be necessary (medium term) to ensure that the sidecar is as reliable as possible, by minimizing the number of other extensions that are installed and locking down the config.