Renderer type specified is not available in the plugin context

[JSCU-CNI]

While developing a plugin, one cannot infer which renderer is specified by the user. The self.context object does not contain such information. Sometimes, one could want to change output based on the renderer specified. I.e., if a quick or pretty renderer is chosen, a large piece of text might be truncated. If, on the other hand, json is specified, that text would not be truncated.

We considered making the renderer object (or at least the name) available on the self.context object. However, we also considered creating an extra format_hints: TruncatedText or BigText. Depending on the renderer chosen, it would render... differently! For quick and pretty, it would render at most 80 characters. For json(l) and csv it would render the full text.

@ikelos What would your preference be for a PR? Or do have any ideas for another solution?

[ikelos]

Hi there, there's a reason that plugins know nothing about the presentation layer, it was by design. The plugins are supposed to be used to produce data. Most people use the CLI and a renderer, but the design was established to allow the framework to be used as part of another program, where there may not even be a renderer.

Please ensure your plugins return whatever data they're supposed to return, and please do NOT design them for a specific output or to make them look pretty for humans. Any concerns about how to format the data for the user should be made by the UI that's taking the data and deciding to display it to the user. The UI will know it's a string, it will know how long it is, it can truncate it if that's deemed best, there's nothing the plugin needs to say that should affect that decision. (Would normal strings not be truncated? Would long strings be allowed to be longer for some reason? We really don't want the format hints to get used as an overload mechanism for people to make the CLI look prettier. It would lead to inconsistency and difficulties in the future.

We're looking at developing a data renderer, which will have the offset, layer and length for a chunk of data, the UI will have to retrieve the data, but it will allow the UI to decide how to render it best. Hopefully this will help with your needs, but if you want the output rendered better, please submit PRs to the UI, don't change the framework...