Explicitly specifying backend for options

[jbednar]

As of PR #802 , it's easy to switch backends, because the style options supplied are first filtered so that each backend only gets the options that are valid for it. However, some backends may use the same name for options with different meanings, e.g. one could accept a width in pixels, while the other may use a width in data coordinates. In other cases, people may want to set even the same setting differently depending on the backend, to work well with the default behavior of that backend (such as the different background colors between the mpl and bokeh backends).

For both those cases, it would be great if style options could have a backend specified optionally, as in "mpl:width=5 bokeh:width=200", or some other similar syntax.

[jbednar]

Philipp suggests a syntax more like mpl:(linewidth=5 facecolor='red') bokeh:(line_width=5 fill_color='red') to separate them more cleanly.

[jlstevens]

This would definitely need updates to the opts magic parser. At that point, I would just send the keywords to the option tree or custom tree according to the specified backend. As a result, this could be implemented in a way that doesn't involve filtering at all.

Everything would be fairly easy to implement except for upgrading the parser which is hard.

[jbednar]

Ok. Also, an additional benefit of this approach is that it lets users clarify which backend the option is meant for, even if it's unambiguous to HoloViews. E.g. which one takes line_width and which one takes linewidth? I'll never be able to remember that. :-) And then it could be error-checked for that particular backend's supported options.

[philippjfr]

Right, there's another benefit to this. Currently if you've enabled one backend but switch to another for one cell using the output cell magic then the tab-completion mechanism will return the wrong options, mpl:( disambiguates that and will always tab-complete matplotlib options for example. Secondly being explicit will validate matplotlib options correctly. We can continue to ignore invalid options supplied via the regular syntax, it's just that this provides a means to get both validation and tab-completion independent of which backend is currently selected.

[jlstevens]

All great suggestions!

As much as I would love all this, I am also acutely aware that implementing the parser and corresponding tab completion would be quite an undertaking...

[philippjfr]

I'm still hoping simply registering them like this will work:

    style_options_short = pp.nestedExpr(opener='mpl:(',
                                        closer=')',
                                        ignoreExpr=None
                                    ).setResultsName("mpl:style_options")

Probably overly optimistic.

[jlstevens]

In addition to the backend-hinted keywords, you have two possibilities with respect to unhinted keywords:

1. They could target the active backend only
2. We could filter and try to apply then to all the loaded backends.

This is orthogonal to supporting the hints - I just want to enumerate the possible behaviors.

[philippjfr]

We are now only missing a way of doing so via the magics, since #2306 was merged you can now explicitly declare the backend when using obj.opts, obj.options and hv.opts.

[philippjfr]

Since we are now trying to switch away from the magics and adding any further complexity to the magics has proved to be incredibly tricky I'm going to close this as completed.