plotting

As a follow-up to #11540, we would like to add metadata to as many examples as possible. This will not only make the examples more usable as they are right now, but it will also open up new possibilities to search for and crosslink examples.

For the purpose of this issue, 'standalone examples' are all .py files in these folders in this repository:

• examples/plotting/file
• `examples/mode

Bug summary

When the build gets to https://github.com/matplotlib/matplotlib/blob/main/src/_tkagg.cpp#L262-L273 on Cygwin, the build fails with a few goto crosses initialization warnings, which are easy to fix (closed by #23051), and two error: ‘PyErr_SetFromWindowsErr’ was not declared in this scope, which are less easy to fix.

Code for reproduction

pip install matp

it's becoming more time-consuming and error-prone to manually re-test all the demos following internal refactorings and API adjustments.

now that the API is fleshed out a bit, it's possible to test a large amount of code (non-granularly) without having to simulate all interactions via Puppeteer or similar.

a lot of code can already be regression-tested by simply running all the demos and val

https://readthedocs.org/projects/chartify/builds/

It is currently a pain to use an OxyPlot.WinfowsForms.PlotView with a transparent background: it throws if you set its BackColor to transparent. To avoid this, it is necessary to set the ControlStyles.SupportsTransparentBackColor style to true on the PlotView; however, Control.SetStyle is protected, so consumers must resort to reflection or extending PlotView to do so. This could be

I think it could be useful, when one wants to plot only e.g. class 1, to have an option to produce consistent plots for both plot_cumulative_gain and plot_roc

At the moment, instead, only plot_roc supports such option.

Thanks a lot

Annotations don't look good in a Heatmap with a large amount of data and those that are rendered in the high values range are barely visible with the default color map. Heatmaps generated with the Bokeh backend don't have annotations by default.

See this example taken from the reference gallery:
![image](https://user-images.githubusercontent.com/35924738/140487561-3cdb38ea-8694-4328-ab9f-bfdda

What is the feature ?

I'm trying out this library for the first time and there's some places where it would be delightful to have shorthand functions:

1. Shorthand functions for Pos: Pos::top_right, Pos::bottom_right, Pos::bottom_center etc..
2. Short way to set colors for components. Currently, lots of boilerplate is required for e.g. white-on-black plotos
   • a cool start would b

I don't think this is a duplicate ticket, even though it's quite an obvious feature after that cat demo at SciPy2018.

The code that selects and renders the different geos is here in the THREE.js code
https://github.com/maartenbreddels/ipyvolume/blob/master/js/src/scatter.js#L57

I don't know quite where/how to inject the mesh definition compatible with the data file of this form, but i

Details

This shouldn't happen

using Plots
plot(rand(4,4), layout = 2, series_annotations = [1 2; 3 4])
Error showing value of type Plots.Plot{Plots.GRBackend}:
ERROR: type Array has no field baseshape
Stacktrace:
  [1] getproperty(x::Vector{Plots.SeriesAnnotations}, f::Symbol)
    @ Base ./Base.jl:42
  [2] serie

As I understand, the LineString type allows the user to plot multiple disconnected lines in the same plot call. However, there is no documentation to reflect this. We should add some, and possibly consider adding documentation (in the docs of lines, surface, heatmap, etc.) about which types they accept. Possibly also a listing of convert_arguments signatures which are applicable to each

Describe the bug, what's wrong, and what you expect:

This docstring listing is incorrect. We need to check the curvature method and fix the listing.

https://github.com/pyvista/pyvista/blob/68361b5f3b9ec6c74a1d905625697c905334a2b2/pyvista/core/filters/poly_data.py#L518-L529

A clear and concise description of what you expected to happen.

To Reproduce

None

# 

What should we add?

Currently, metpy.interpolate.cross_section only operates by interpolating to a geodesic between specified start and end points. This becomes problematic when:

• Data are not georeferenced (e.g., idealized cloud models)
• User wants a straight path in the projection of their data (e.g., a rhumb line in lat/lon data)
• User seeks one of the dimensions of target points t