If you are going to add html-like syntax support it is better to use HTMLParser/html5/html5lib module for parsing instead of regular expressions and to validate it with DTD instead of hand-written validator.

This would introduce further dependencies and my idea is to have a very lightweight markup, nothing too much elaborated.

This would introduce further dependencies

HTMLParser is the part of the Python Standard Library.

Hi @rougier

I think this suggestion is overall a good idea.
Would it be possible to a couple of examples of how the API would look like?

Also, don't forget to change the MEP number of the title and to add the MEP to the index of MEPs: the documentation fails to build on your branch as the new file is not part of any tree.

@Kojoley Oh, I see. Ok, I will try to convert my code.

@NelleV Problem is that I'm not quite sure of the number to use since there may be other MEP's around (I know for sure MEP28). But anyway, I'll got for 29 and fix the tree.

That's a good point… It's also a good reason to merge MEPs as draft quite quickly.

Wouldn't it make more sense to implement this as improvements to mathtext? instead of

"Hello <b>world</b>!"
"Hello <span color=blue>world</span>!"
"Hello <span family=serif size=x-small>world</span>"

have

r"$\text{Hello \textbf{world}}$"
r"$\text{Hello \textcolor{blue}{world}}$"
r"$\text{Hello \textsf{\small world}}$"

You'll be able to have a better layout this way too (basically keep using the mathtext layout engine).
One could have some helper if "$\text{}$" is too much to type (but TBH you immediately gain back on the fact that you don't need closing tags...).

(Initially posted to matplotlib-devel.)

@anntzer This constrains the font family and I find it too verbose compared to the markup version.

In what sense is the font family constrained? The default font will be the same (DejaVu) for mathtext and non-mathtext in 2.0 (#5214), and I'd guess changing the mathtext font and the non-mathtext font is approximately as complicated...

Arguably $\text{}$ is a bit verbose, but anything inside is actually less verbose (compare

<span family=serif>foo</span>

and

\textrm{foo}

or even possibly

{\rm foo}

Isn't markdown all the rage nowadays?

I think supporting markdown or html-like support would be a nice additional feature.

As on the other MEPs, I'd suggest merging this as soon as possible as a draft, and discuss about this on the mailing list.

@rougier I suggest that you mention @anntzer's mathtext suggestion in the Alternatives sections. I would also like to see you address the question of how the html-like approach would interact with mathext. Would they be mutually exclusive? Or could one markup style occur inside another? (I suspect the former is the case.)
@NelleV, I don't see any reason not to flesh this MEP out a little bit as suggested above before merging it and discussing it on the list.

@myyc, I don't think markdown is appropriate for mpl. Markdown concentrates on aspects that don't normally occur in plots (formatting blocks of text as lists, etc.), and lacks the types of style control addressed by this MEP (color, font).

@efiring exactly nailed it: what is supposed to happen when some writes $ <span ...> $ </span>? On the other hand I like the idea of using markdown, which does allow for embedding math (at least in the pandoc dialect).

@anntzer @efiring you're right. I will update the MEP with alternative and potential problems. The fact is that I did not think at all of the latex text problem and I've no idea how to handle that case.

Also, following @Kojoley comments, I need to integrate the html5lib module.

If we decide to use html-like syntax then you should just use the stdlib's parser.

Not sure where the right place to leave this comment is, but http://matplotlib.org/devdocs/users/annotations.html#using-complex-coordinates-with-annotations item 5 has a (I think) more robust way of doing the offset (as it will recompute the offset late).

I am fine merging this MEP as a draft and continuing the discussion on the mailing list. Opinions?

I would rather wait until @rougier has made the improvements to it that he has in mind based on the comments to date. Discussion on the mailing list can be more productive if it starts from a more complete MEP, and that is well within reach.

Hope to work on it by the end of the week.

Done.

Just rebased because of conflict with MEP28 on index.rst