Not just bold markup with three apostrophes, also bold markup with b tags, also italics with two apostrophes or i tags, or small with small tags, and I would assume just about any inline tags that open and close inside the span tags and around the div tags. See https://en.wikipedia.org/w/index.php?title=User:Anomalocaris/sandbox/Lint_Test&oldid=1104580787

This item could have been titled:
Linter false positive: "Foo px" as caption is incorrectly detected as a Linter error
It happens whether or not digits precede px.

Please move it to highest priority. Develop the fix per PamD and patch it in to the existing visual editor, or just disable the visual editor until this is done. It is unacceptable for the visual editor to generate names that (a) frequently cause name conflicts and (b) go against :en:WP:REFNAME, which discourages this style of ref name.

@cscott wrote "what we expect we will do is start a low-priority background job that will pull every page in every wikimedia project through the linter to ensure that all missing lints are regenerated. Last time we did this it took about a week for that job to run."
Well, if you're going to do that, why not wipe the linter database and start over, to clear out the nonexistent 1 Paragraph wrapping bug workaround, the nonexistent 66 Self-closed tags, the nonexistent 77 Unclosed quote in heading, and the nonexistent 14 Multi colon escape, and other miscounted lint errors.

When wikitext linting updates are re-enabled, what will happen to everything that was edited while wikitext linting updates was disabled? How long will it take to get caught up?

I came here from Help:Displaying a formula#Basics at English Wikipedia, where it says, "A script will be used to replace all <ce> with <chem>." As of today there are 192 articles in English Wikipedia with <ce> in their wikitexts, so I think that would be a good idea. What are the plans, if any, to create and deploy this script?

The problem continues. Examples:

It would be helpful if articles were sorted in order of when most recently edited, probably in order of most recently edited last. That way, if one can easily find the new additions/modifications for any type of lint, with or without namespace filter. This is particularly helpful for users who don't use LintHint, edit an article, go to page information, find that there are still errors, and want to work on the remaining errors. I have had experiences of editing an article, verifying from page information that the lint errors had been updated, going to a lint error page for a remaining type of lint error, and not finding the page I had worked on listed among the last 5,000 or even 10,000 errors. This problem would not go away by waiting minutes or hours. Things are sorted approximately in order of when last reviewed by the linter, but I have had experiences where this sort didn't work. I don't care so much about this any more, because I use LintHint, which enables me to find and remove errors of all types in one edit session.

More useful than sorting, but perhaps more work, would be searching or selecting. We can already select by namespace. It would be great if we could select by "last edited by [user]" or "last edited within X hours or days". In the case of bogus file options, it would be great if we could select by file option; sometimes I want to fix just misspellings of the word "right", or blank options. I have no idea how much effort would be involved with any of these ideas and if they are worth the trouble to code.

Re Izno's point about templates: There are three possibilities:

1. The error is in the template: Using LintHint, if the template is written without template-specific markup such as triple curly braces, #if constructions, etc., these are as easy to solve as any other lint errors.
2. The error is in the page calling the template, in wikitext within a template's parameters, or between an opening and closing template: Using LintHint, these are usually as easy to solve as if the template is not involved at all. In some cases, one has to temporarily insert a space between the opening curly braces of the opening template in order to force LintHint to be able to find the exact location inside.
3. The error is caused by the interaction of the main page and the template: Here, Izno is right, these can be difficult, especially if the template has template-specific markup. However, I haven't found many lint errors of this type.

With this in mind, I wouldn't find it useful to sort by errors without templates vs. errors with templates. Izno and other users might value this capability.

Jdforrester-WMF wrote, "AFAICT the problem is principally around using the Monobook skin; we've adjust the whitespace significantly in Vector, which is the supported interface. Sorry that we didn't spot this beforehand. We'll get it fixed soon."

Nihlus wrote, "Constant demands of 'revert it now' are as unhelpful as they are short. This is clearly a change that is here to stay (OOjs-UI, that is), so your time would be better spent making recommendations on improving it, as you began to do on VPT." OK, Here is my proposed list of improvements:
User Profile tab

• To better separate sections, use boxes around each section, or have larger headings.
• Reduce line spacing within sections.
• Move user input to the right of, not below, instructions/descriptions.
• Reduce width of pull-down menu, which now is almost 3 times the width of the longest option.
• Align checkbox with top of description.
• Reduce verbiage about signature field. One thing that is missing here is something like, "uncheck if blank".
• Better, don't allow the use to save this page with a blank signature and the box unchecked.
• Remove (i) buttons and display their now-hidden information.

Appearances tab

• To better separate sections, use boxes around each section, or have larger headings.
• Reduce line spacing within sections.
• Move user input to the right of, not below, instructions/descriptions.
• Reduce width of all 3 pull-down menus; each is many times wider than the widest option.
• Reduce width of Time offset input field, which is 5 to 10 times wider than it should be.
• Remove (i) button and display its now-hidden information.

Editing tab

• To better separate sections, use boxes around each one, or have larger headings.
• Reduce line spacing within sections.
• Reduce width of "Edit area font style" pull-down menu; it is about 3 times wider than it should be.
• Move "Edit area font style" pull-down menu to the right of, not below, its name.
• Remove (i) button and display its now-hidden information.

Recent changes

• To better separate sections, use boxes around each section, or have larger headings.
• Reduce line spacing within sections.
• Reduce width of "Days to show..." and "Number of edits" fields; they are 10 times wider than they should be.
• Move "Days to show..." and "Number of edits" fields to the right of, not below, their names.
• Remove the three (i) buttons and display their now-hidden information.
• Pending changes section should be better grouped. Reducing line spacing between radio buttons while keeping the large line spacing between the group of radio buttons and the check box would help clarify the grouping.

Watchlist tab

• To better separate sections, use boxes around each section, or have larger headings.
• Reduce line spacing within sections.
• Reduce width of "Days to show..." and "Maximum number of changes..." fields; they are more than 10 times wider than they should be.
• Move "Days to show..." and "Maximum number of changes..." fields to the right of, not below, their names.
• Remove the four (i) buttons and display their now-hidden information.
• "Manage tokens" should be "Manage token", because there is only one token ... is there the possibility of multiple tokens for one user?

Search tab

• No issues at this time.

Gadgets tab

• To better separate sections, use boxes around each section, or have larger headings.
• Reduce line spacing within sections.

Beta features tab

• No issues at this time.

Notifications tab

• To better separate sections, use boxes around each section, or have larger headings.
• Reduce width of "Send me:" and "Email format" pull-down menus; they are 2 and maybe 8 times wider than they should be, respectively.
• Move "Send me:" and "Email format" pull-down menus to the right of, not below, their names.
• Move email address to the right of, not below, "Send to:"

This is not a matter of getting used to something. This is a matter of replacing a good design with a poor design. Please stop arguing just revert it now.

I agree with Xaosflux. What were you thinking? There was nothing wrong with the old page, and many thing that were right are now wrong. On the User profile tab, there were helpful boxes separating the sections. These boxes are now gone, and because of ludicrous amounts of white space within sections, it's hard for the user to see where the section breaks are. Prompts belong to the left of input fields, not above them. The check box next to Treat the above as wiki markup is badly placed and should be right next to those words, not several lines below them. And that's just the first tab. The other tabs are equally bad. What a disaster!