Archive for the ‘wireframes’ Category

MP-WP Patch Viewer and Code Shelf

Monday, January 13th, 2020

After some brief discussion in #ossasepia, which itself was prompted by a suggestion from MP on Diana's blog, I decided it would be worth compiling the thoughts into a proposal and including a few wireframes for illustration.

There are actually two proposals, the first is for the ability to embed vpatch code snippets into an mp-wp article by way of some custom markup, e.g. [[ code goes here ]]. The second proposal is for providing some level of vpatch management from within mp-wp, to facilitate the concept of a code shelf as well as a better format for full-length vpatch1 reviews. I'll discuss the former proposal first because it makes sense as a standalone whereas the second proposal requires work from the first. So from an implementation and release standpoint it makes sense to support embeddable snippets before full-length vpatch management.

Embeddable VPatch Snippets

Embedded Code Snippets Full Embedded VPatch

This feature would:

  • Allow users to embed vpatch content within an article via some new markup, e.g. [[]], similar to (()) for footnotes
  • Display patches with diff syntax highlighting2 and line numbers
  • Allow linking to anchored line numbers. Clicking a line number navigates to its anchor, e.g. clicking line '22' appends '#L22' to the URL. useful for sharing in the logs or referencing in comments on the article

This is pretty straightforward. It would only require a new mp-wp plugin to parse the new markup and minor updates to a theme to support the diff formatting. This feature would work great for most quick vpatch reviews, and could even be used for larger vpatch reviews for the time being.

The only thing I could see making this feature more involved would be the notion of inline comments (wireframe) in an embedded vpatch. If we wanted to do that we might have to add a new comment type (to render it separately from the other post comments) and field (to indicate the line a comment is referencing). I do think this would be useful for full-length vpatch reviews but it's also something that can be added in a phase two of this feature.

Code Shelf, or MP-WP as a VPatch Repository

This feature is less clear in terms of scope and implementation. It is being proposed here to solicit feedback to help determine its viability and usefulness, as well as to shape the requirements. The name and inspiration comes from Diana Coman's excellent overview/map of the current V landscape.

The basic idea is to add a set of capabilities to mp-wp to make it work seamlessly as a vpatch repository. This might roughly include:

  • The ability to upload vpatches and signatures within the mp-wp admin UI
  • Automated storage and organization of uploaded vpatches, plus the ability to manage these
  • Portability of uploaded vpatches (ability to embed in an article or include in one's Code Shelf)
  • From within the Code Shelf: links back to the articles that introduced the patches, links to download VTree tarballs

Here's an example of what a Code Shelf might look like:

Code Shelf

Having this feature could be very cool, and standardizing this could allow for aggregation of vpatches into a central (or federated) repository tool that pulls from a specified list of code shelves—something like but auto-generated, and with links back to introductory blog posts.

Again, this second feature is still a little fuzzy in my head, and I haven't thought too much on how it would be implemented, so I'm sharing this mainly to get others thinking about it and collect feedback from anyone who is interested. There are also still a number of other items in the mp-wp queue3 so it might be worth getting an updated priority ranking as well.


  1. This is only intuition for now, but I currently think it would be easier to deal with full vpatches if they were their own entity, rather than text inside an article. For example, they could be stored in a new mysql table, which would allow for querying and referencing without having to parse article text.

    It also seems like it would be a more pleasant experience when editing an article to update a reference to a vpatch rather than finding the opening '[[' and then scrolling however far down until you find the ']]' and making sure you paste exactly between them (for full patches of decent size, if that's what you wanted to include). []
  2. In theory this could be expanded later to include support for other syntaxes besides UNIX diff files. []
  3. Completion of the test suite, slimming patches, a proper theme or two, the addition of the new server-side select mechanism as a standard feature (and removal of the old mechanism), and bulk upload support. []