Fix display of register names with multiple underscores in mpl and latex drawers

[enavarro51]

Summary

Fixes #7455

Details and comments

An attempt was made to deal with register names containing multiple underscores in #3827, but it did not work in all instances. This PR fixes that. The same problem would also crash the latex drawer and this has been fixed as well.

This PR now assumes any register names coming into the drawers will conform to the OpenQASM 2.0 spec. In the current main, this is not guaranteed. See #7458.

[jakelishman]

This seems to be part of a more general problem, that register names may contain special characters that can't be safely inserted into the formatters for the drawers. We'd have similar problems if a register contained ^, and everything would break horrendously if { was present without a }.

I think it might be a better strategy to keep a mapping of register: escaped_name somewhere, and then have each drawer keep its own function for safely escaping names. That'll be easier to extend in the future, and I think it ought to simplify some of the _get_text_width handling; instead of counting all the underscores/carets/whatever and then trying to correct for it later, we should possibly just scan through a math-mode match, and only count unescaped special characters. Then it doesn't matter how the escaped characters got in, it'll still work correctly.

OpenQASM 3 will add whole chunks of Unicode characters into the valid identifiers, so restricting to /[a-zA-Z_][a-zA-Z0-9_]*/ is going to be too restrictive, and it's probably a good idea for us to avoid restricting unrelated parts of Terra's behaviour on the basis of the OpenQASM 3 spec (which isn't part of Terra).

[enavarro51]

@jakelishman So this takes care of the problem with #7455 and fixes another problem with the text width if _s were used in a name. Multiple underscores would be removed in width calc which would cause the width to appear too small. Result was the name would run off the left side. The solution was to only remove 1 _ if register.size > 1, otherwise don't remove any. For gate names and labels, nothing is changed.

It also solves the problem for the latex drawer which would fail on multiple _s.

As to the bigger picture, you're right, names like abc^{def would be a mess all around. And problem is if the error gets down to the matplotlib or LaTex level, the error messages are generally not very helpful.

[enavarro51]

This also adds tests that weren't included in #3827.

[coveralls]

Pull Request Test Coverage Report for Build 1693401113

• 13 of 22 (59.09%) changed or added relevant lines in 2 files are covered.
• 3 unchanged lines in 1 file lost coverage.
• Overall coverage decreased (-0.003%) to 83.098%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
qiskit/visualization/matplotlib.py	1	10	10.0%

Files with Coverage Reduction	New Missed Lines	%
qiskit/pulse/library/waveform.py	3	89.36%

Totals
Change from base Build 1692656903:	-0.003%
Covered Lines:	51988
Relevant Lines:	62562

---

💛 - Coveralls

[javabster]

This PR fixes the original issue but I do agree with @jakelishman that it would be great if special characters could be handled in a generic way and could also include support for OpenQASM3 characters. It would be nice to do this as part of this PR but understand it wasn't part of the original issue requirements so perhaps an intermediate solution for this PR could be to convert _fix_double_script to a more generic function (stored in utils.py) that for the moment just handles the underscores but could be expanded later when we want to address other special characters? Then @jakelishman could open a separate issue covering the cases he described?

[enavarro51]

How about a fix_special_characters added to utils.py that takes a string and returns the string with whatever adjustments are required. We can add kwargs as needed for special handling of some strings, but for now just fix the mulit-underscores.

[enavarro51]

Added fix_special_characters function to utils.py in ad5010a.

[javabster]

Yeah I like this better with a more generic fix_special_characters function thanks! Although just looking through the drawers now, was thinking does it make more sense to call fix_special_characters from get_bit_label? Then we don't need to call it multiple times in the drawers

[jakelishman]

Thanks for this - the new separate function looks like a neater way of handling things to me. Certainly it's easier for me to follow the code this way through. I just left a couple of minor comments (and Abby's comment), but this is certainly moving to merge.

The new tests look good - thanks for those.

[enavarro51]

@javabster I went ahead and did what you suggested on putting the special char call inside get_bit_label in 0a5356e. I discovered that all the latex creg labels were not wrapped in {} when cregbundle is on, unlike what happens with all the other bit labels. It works either way, but I thought it might cause a tricky bug if left like it was. This is why there are a bunch of updated latex refs.

[jakelishman]

This looks good to me now, thanks for the changes, and for the stewardship of the drawers!