Skip to content

Instantly share code, notes, and snippets.

@ryo33
Created November 10, 2023 03:52
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save ryo33/5386bb536e3cd619bb01a5f168907610 to your computer and use it in GitHub Desktop.
Save ryo33/5386bb536e3cd619bb01a5f168907610 to your computer and use it in GitHub Desktop.
Neovim No-Nonsence Protocol

"Neovim No-Nonsence Protocol" (NNNP)

I'd like to propose "Neovim No-Nonsence Protocol" as the working name for this project to help our discussion. It can also be used as the official name when releasing it if no nice names are found.

Use Cases

  • image preview
  • inline preview of latex expression in a markdown file
  • minimap.
  • color picker.
  • showing icons without Nerd Fonts.
  • pets

Design goals

  • Not specific to a GUI application like Neovide
    • We cannot assume how a GUI renders things, like Qt, winit, or Electron.
  • But specific to Neovim
    • We should not reinvented Qt or something.
    • We should keep this protocol simple and small.
  • Ease of implementation across many GUI applications
  • Easy and Kind APIs that provided to plugins

Architecture

We can use Neovim's built-in windows, buffers, and extmarks as the primitive of NNNP.

  • to indicate the position, width, height, and z-index of the widget.
  • to draw the background color (that might be transparent).
  • to represent the lifetime of the widget.
  • to tell a GUI what it should be rendered by a special filetype, nnnpwidget.
  • to receive keyboard events.

The flow of the widget system:

  • GUI sets a global variable to tell plugins that NNNP is available.
  • A plugin creates a (floating) window with a buffer with the special file type, nnnpwidget.
  • The plugin can ask for the dimension (logical size and scale factor) of one character in the grid to the GUI.
  • The plugin provides image data to UI through the buffer content.
  • UI renders the image and updates it when the buffer content has been updated.
  • The plugin can receive keyboard and mouse events through a window.

Need to discuss

  • What kind of image data should be supported? I think supporting only the bitmap is nice for simple implementation and API.
    • bitmap image
    • vector image
    • tessellated triangles
    • or other
  • How to plug between a GUI to a plugin? (RPC, buffer content, lua function, temp file, or compound of them)
    • image content (I prefer base64 encoded in a buffer content)
    • triggering of rendering from plugin
    • triggering plugins for each frame of rendering
    • provide dimension data in DIP to plugins
  • Implementation details of the extmark-based API
  • Is it suitable, the current direction of the protocol design?
  • The name of the protocol
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment