Feature request: Markdown support in the command line and command history

Serengeti (Rhino BETA)
, ,
1

Three requests for the command line and command history windows

I have three related requests for the Rhino command line and command history windows:

  1. Make them Markdown-compatible.
  2. Support GitHub-style notification blocks.
  3. Allow the output to contain clickable actions that execute Rhino commands or macros.

1. Make the windows Markdown-compatible

Please make the Rhino command line and command history windows Markdown-compatible.

A command could then display structured output using simple formatting such as headings, bold text, lists, tables, code blocks, and links.

I understand that commands needing an elaborate interface can use Eto, but these two windows still feel very limited and dated. Adding Markdown rendering would make them immediately useful for many simple commands without requiring every developer to build and maintain a custom UI.

For example, today a command might print a report as plain text:

A12 Clip 128 0.08 kg
BRACKET-LEFT-HAND-EXTENDED Stainless-steel reinforcement bracket 4 12.6 kg
P7 Cover plate for upper rail 23 1.42 kg
ASSEMBLY-204 Complete entrance framing assembly 1 486.75 kg

With Markdown support, the same command could display:

Part Description Count Weight
A12 Clip 128 0.08 kg
BRACKET-LEFT-HAND-EXTENDED Stainless-steel reinforcement bracket 4 12.6 kg
P7 Cover plate for upper rail 23 1.42 kg
ASSEMBLY-204 Complete entrance framing assembly 1 486.75 kg

The different lengths of the part numbers, descriptions, quantities, and weights make the current plain-text output difficult to scan. A rendered table solves that immediately.

2. Support GitHub-style notification blocks

Please also support GitHub-style Markdown alerts for consistent notifications.

GitHub extends Markdown with blocks such as:

> [!NOTE]
> This object is already on the target layer.

> [!WARNING]
> Three open curves were skipped.

> [!CAUTION]
> This operation cannot be undone.

Rhino could implement a similar convention and define the appearance of each notification type, including its icon, colors, spacing, and light- or dark-mode presentation.

Native commands and third-party plug-ins could then use the same semantic notification styles instead of each developer inventing a different format.

3. Allow clickable command actions

Please also add a small Rhino-specific extension that allows Markdown output to contain clickable actions.

These actions could use normal Markdown link syntax with a Rhino-specific destination. For example:

[Open drawing](rhinomacro:_Open "path")

Rhino could render links using the rhinomacro: scheme as buttons, including an optional icon, and execute the associated command or macro when clicked.

A command could then display an interactive table such as:

Part Description Count Weight Action
A12 Clip 128 0.08 kg Open drawing
BRACKET-LEFT-HAND-EXTENDED Stainless-steel reinforcement bracket 4 12.6 kg Open drawing
P7 Cover plate for upper rail 23 1.42 kg Open drawing

This would suddenly make the command line and command history interactive. A command could display results and let the user immediately open a drawing, select an object, zoom to an item, correct a problem, rerun an operation, or request more details.

Markdown alone would substantially improve the presentation of command output. Markdown plus a small, controlled mechanism for command links would open many additional possibilities for both native commands and plug-ins, without requiring a complete (and very likely inconsistent) Eto interface for every simple workflow.

2

I gave it a shot and created CommandHistoryMD. You can see a preview in the video.

The Markdown formatting works really well, and custom styles are especially useful for making command output clearer and easier to scan.

The interactive buttons are useful too. Normally, when a button generates more output, the content updates and the button scrolls upward. The panel has a Freeze checkbox: as shown in the video, freezing the output keeps the rendered content in place, so the same button can be clicked repeatedly. Unfreezing catches up with the latest output.

These buttons are intended to give commands a quick, simple, but still rich UI, and I think they do that job well. Even with their limitations, they are much better than today’s lack of interactivity in command output.

I plan to use Markdown output in all my plug-ins. For now, I’ll use my CommandHistoryMD while waiting for this feature request to be satisfied.
:wink:

3

Hi

very brilliant idea :ok_hand:

4

I don’t feel comfortable with making the command history so large I only get a tiny drawing area. So why not be even more radical and make the command history window floating so it could then be floated off to a second monitor?

5

You know Rhino 9 is now in the beta phase so no further new features will be added before release, right?

6

My plugin is a floating panel.

In the video is docked on the side of the official one, but you can shrink the official one and dock it above it, so it replaces it, or undock it and place it wherever you like it. You can put it on the side screen or, on ultra wide curved monitors you could dock it on the side instead of on top.

7

Yes, I know. I don’t expect this before Rhino 9 is released.

I’ll use Markdown in my own plug-ins because their users will run them alongside CommandHistoryMD. I may publish it, but it has no real-world mileage yet, so I want to uncover any surprises first, and it would be only useful to other plugin developers.

The renderer itself is a tiny feature. I built this one in a few hours, and McNeel could certainly do better. The larger job would be updating Rhino’s commands to produce richer output: either gradually, with temporary inconsistency, or as one migration so large that it might never be tackled. I’d take the gradual approach.

8

One hour into using Markdown output, and my plug-ins already feel like they’ve entered the 21st century!

Tables are easy to read, warnings stand out, and the output can include useful clickable actions. I love it.

I’ve docked the standard command-line panel on the left, with CommandHistoryMD above it, then reduced the standard panel until it’s almost hidden. The visible output is essentially all Markdown, and it looks great.

I did notice one behavior I wasn’t expecting: when the command line is docked vertically, its options are listed vertically too, as shown in the screenshot. Perhaps this dates from before ultrawide monitors, when horizontal options would have wrapped unpredictably. Today, many users have plenty of horizontal space. In our office, everyone uses either a 40-inch 4K TV or a 49-inch ultrawide monitor.

The vertical option list doesn’t bother me; it’s just an interesting side effect of this layout, and so far I think it makes it easier to scan large lists of options.

Here is what it looks like after running my PDF converter and plugin setting manager commands:

image
image1086×1044 87.9 KB

9

Hi Stefano, could you maybe share a little bit more of what problem your plug-in solves? Looks really cool!

Does it analyze an existing floor plan and create interactive buttons to zoom into problematic areas that need manual fixing? I definitely understand how that can be very handy if you draft a lot of architecture!

10

My company manufactures panels used to cover buildings.

Our workflow includes laser scanning the building, creating the 3D model, laying out the panels across each facade and around parapets, windows, and other openings, creating shop drawings, adjusting everything after field measurements, generating flat patterns, nesting, G-code, BOMs, crating, shipping, and so on.

What I’m building in Rhino is essentially a new version of tools I developed over the last 20 years for another CAD system, ThinkDesign.

Those old tools needed some serious modernization, so we decided to move to Rhino because it is easier to customize and use, and rebuild everything from scratch.

The plan is to create one large plugin containing all the commands that depend on one another, our web applications, and other internal tools.

Other tools that are not tied to the internal structure of our panels, such as point-cloud management, could eventually become separate plugins of their own. The same applies to smaller independent tools like this one, which may have more general use and that I might eventually publish. This particular plugin is only useful to plugin and Grasshopper developers who want to generate richer Markdown-formatted output in the command history, including things like tables, reports, and clickable actions.

At the moment, it’s too early to show anything.

11

I’ve added a simple feature to replace chunks of output, for example to show the progress: any block of text wrapped by comments <!--chmd:<block-id>--> replaces any previous block with the same id.

Here is what it looks like:

12

I’ve started post-processing the output of some native Rhino commands so I can make the results a little more readable.

Here you can see Rhino’s normal plain-text output, followed by the same output after my plugin recognizes it and reformats it:

And here is a diagnostic command from my plugin. The command itself offers options for several kinds of repairs, but the output also contains buttons that can zoom to and highlight the problematic areas, as well as buttons that execute the corresponding repair options directly:

I’m finding this approach quite useful because:

  • I don’t need to spend time building a dedicated UI for every command.
  • All commands can follow the same visual language.
  • The output remains available in the command history for later inspection. It eventually scrolls away, of course, but it is often useful to have it there.

A dedicated UI can certainly provide a more sophisticated experience in many cases, but it also comes with some costs:

  • More development and maintenance time.
  • More opportunities to introduce bugs.
  • Greater risk of inconsistent behavior and appearance between commands.
  • Once a dialog is closed, its contents are usually gone.
  • Unless, of course, we add another mechanism to preserve them, which introduces yet another opportunity for inconsistency.

So, dear McNeel: if you agree that this is an improvement, how about adding native Markdown rendering to the command line/history and gradually migrating command output to it?

It might help Rhino look a little more like it belongs in the 21st century.
:wink:

13

this looks really interesting, thanks for showing us. Any plans to make available as a V9 plugin from the Package Manager or Food4Rhino ?

14

I have no problem publishing CommandHistoryMD as it is. It would mainly be useful for your own plug-ins and scripts, allowing them to produce richer output with tables, notices, expandable sections, and clickable actions.

For native Rhino commands, it currently reformats Distance and EvaluatePt into easier-to-read tables. Other native commands won’t benefit until I add specific postprocessing for them.

Are there other Rhino commands whose output you think would benefit from this? Suggestions are welcome!