See comment on original issue #11092. In short: they are non-duplicates. So at most, I'd recommend adding explanations above the respective examples providing the context and link to the other one(s).

@ImportanceOfBeingErnest @jklymak. I think you will find my changes much more acceptable now. I moved the code around in the non-toolkit file to line up better with the yes-toolkit one. Besides that, I added a bunch of comments to clarify why there are two files there to begin with. I've documented all the other changes I made through review comments here, all of which I think are legitimate cleanup.

In the simple Anchored Box01 example, I would not change the text actually. This example is meant to be the simplest case for an anchored text (as opposed to a text positionned by coordinates). But you can get rid of the loc=2 and replace it with "upper left". As said it would be good if the code shown in the example and the user guide are equal.

at = AnchoredText("Figure 1a",
                  prop=dict(size=15),
                  frameon=True,
                  loc="upper left")

Maybe instead you can use the misc_anchored_artists example to display a two-line text, if that is important for you?

As said, I think there should be links between the files. E.g. to link from the misc_anchored_artists example to
to the axes_grid1_simple_anchored_artists you'd use

:ref:`sphx_glr_gallery_axes_grid1_simple_anchored_artists.py`

What exactly would be the purpose of :ref:`sphx_glr_gallery_axes_grid1_simple_anchored_artists.py`? The text would just appear in a comment, or am I missing something?

The purpose would be that one can click on the link and land on the example page. Did you try that? Is it not working?

@ImportanceOfBeingErnest I actually don't know how to build the docs locally. Will figure it out and let you know.

Building the docs can be a little bit cumbersome the first time you try it, especially on windows. Of course it's ideal to test locally first before committing anything, but you may also rely on the CI tests here on the server for building the docs. It might be a bit overkill going through all the hassle for testing if a single link it working correctly.

I'm doing this on a Linux box that's not doing much else at the moment. It sounds like the kind of thing I'd want to try once for fun just to get an idea, so if you have a pointer to some instructions, I'd be happy to do it.

https://matplotlib.org/devel/index.html

In general, the instructions at writing documentation apply. In addition make sure not to use Sphinx 1.7.3. Have an up to date latex available, including xetex. I think that's it for linux. (You never know what else can go wrong until you try it.)

@ImportanceOfBeingErnest Tried it, ran into the issue of no such package matplotlib. I would prefer to build the docs in place without installing mpl into my current environment. I suspect that this can be done by setting up the PYTHONPATH to point to my source folder, but I was hoping there is a more "appoved" solution.

Mhh not sure if I understand this. Did you build matplotlib in a source folder and then installed it in a python environment? In that case inside that environment you should be able to do import matplotlib - that's the whole point of it, right? Otherwise you couldn't even test any of the changes to the code.

@ImportanceOfBeingErnest. I was basically looking for python setup.py develop, or more optimally pip install -e .. My lack of knowledge of the build system is apalling. I am used to numpy's runtests.py, which builds everything in place and does not properly install it as far as I am aware.

I've made all the requested changes. I did not understand how the comments in the examples were being rendered because most of the examples I have seen don't have proper docstrings. Thanks for bearing with me on this one. I've learned a lot about building and installing matplotlib, as well as how to work with the docs.

Thanks for the effort on this @madphysicist

There seem to be a conflict, please backport manually