easy-extensibility

Editor crafting utilities; i.e., functions that alter the behaviour of VSCode.


Keywords
editor-crafting, vscode, extensibility, key-bindings, settings, snippets, meta-extension
License
CNRI-Python-GPL-Compatible
Install
npm install easy-extensibility@1.0.1

Documentation

Logo

easy-extensibility

Extend VSCode without the ceremony of making a full extension! Just write your code anywhere and it'll be part of VSCode!

Tour of the extension

๐Ÿ’ VSCode is itself a JavaScript REPL ๐Ÿ”: VSCode is itselfs a JavaScript REPL

Features

  • New keybinding: cmd+E to evaluate a selection of JavaScript, or the entirety of the current line.
    • Use shift+cmd+E to insert the result onto the next line.
  • New keybinding: cmd+H to provide a command pallet for user-defined commands using this extension.
  • The easy-extensibility Extension API, or โ€œE APIโ€, which acts as a high-level user-friendly alterative to the default vscode Extension API.

Accessibility

  • ๐Ÿšด Open the tutorial to learn more about using cmd+E by invoking cmd+h tutorial
  • ๐Ÿ“š To learn about โ€œsaving reusable functions and having them load automaticallyโ€, please invoke cmd+h find users init.js file, or provide a template

Extensive Docs

The E API is well-documented; for example the E.readInput method's docs even suggest an example user extension. ๐Ÿš€ Extensive Docs

Anaphoric Usage (with code completion & docstrings)

The current implementation treats VSCode as if it were dynamically-scoped: Any open editor may mention E, commands, vscode with no ceremonial import of any kind!

  • This is similar to the use of the keyword this in object-oriented programming: It's an implicitly introduced argument!

However, for discovarability and example uses, it would be nice to have code completetion: Just write E. and wait a second to see possible completions ---or write the name of the method you want to use and if it's part of the E API, you'll also get completion as shown below.

Code completetion with docstrings

A growing user-friendly API!

Growing API

Why this (meta)extension?

There is essentially only one step (โญ) to making an extension. ๐Ÿค— Sharing an extension, such as a tiny 5-line command, should be as easy as having that defintion code readily available.

In constrast, the default approach to making a VSCode extension is as follows:

  1. ๐Ÿ˜ฑ Make a new NodeJS project, say with yo code as per https://code.visualstudio.com/api/get-started/your-first-extension
  2. โญ Actually write your extension's code
  3. ๐Ÿ˜ฑ Run your code in a dedicated sandbox with F5, far from your code
  4. ๐Ÿ˜ฑ Try your extension; stop the sandbox; alter your code; repeat.
  5. Now to actually make use of your extension, you should pacakge it with vsce package

This approach doesn't encourage making extensions ---since there's so much ceremony--- and it, likewise, doesn't encourage sharing/packaging up the resulting (tiny) extensions.

๐Ÿ”ฅ Invoke cmd+h tutorial to see the tutorial, which concludes with a comparison of our init.js-style extensions versuses thats of the default VSCode style.