@prko @telephon @capital-G this is a minor cleanup after the recent s.plotTree rework.

Thank you for the update. Everything looks good, but I do have one question.

Is there no need to inform users about the 'plotTree' function?

The server documentation provides information about NodeTreeView, but there is no mention of plotTree in the NodeTreeView documentation. Would it be beneficial to include a reference to it to help users determine whether they are using it properly?

Is there no need to inform users about the 'plotTree' function?

Possibly yes. But this PR focuses on fixing the discrepancies between the documentation and implementation, not on improving the documentation in itself.

I think my main concern to consider is whether s.plotTree should return a Server, or a NodeTreeView.

• Argument for returning a Server: this is what s.plotTree was returning previously. If we change it, we'd break code like s.plotTree.meter (though this is a minor issue IMO);
• Argument for returning a NodeTreeView: s.meter and s.freqscope return a ServerMeter and a FreqScope, respectively, so returning a NodeTreeView would be more consistent with these functions.

Relatedly, I wonder whether s.plotTreeView (the method called internally by s.plotTree) should also return a NodeTreeView, or a Server (this is a change in the interface from 3.13 anyway, but that class is not typically used directly, I think)

I think my main concern to consider is whether s.plotTree should return a Server, or a NodeTreeView.

@telephon do you have an opinion on this?

In general, it should return the NodeTreeView. This is a breaking change, but probably not too severe?

@telephon thanks for the input! I updated the implementation to (again) return NodeTreeView. I updated the docs to match.

I also thought that it would be cleaner to update the instance variable Server .nodeTreeView in .plotTree instead of .plotTreeView, what do you think?