Editors need comments to work not only for explicit comments, but also to "comment out" snips of markup. This does work, but a comment opened with <!-- automatically ends at the next newline, instead of ending at the next -->. Also, it seems that the linter treats comments as markup and flags lint errors within comments. It seems to me the solution is very simple. First you remove comments according to the rules of HTML. Then you proceed with linter and gallery operations.

Thank you to the developers who made markup such as /n work. Now will someone please update en:Help:Searching/Regex to reflect these changes?

Novem_Linguae, this is interesting. I can read the :MW:Manual:Job queue page, but I don't have the background to know what to do with it, as I am intimidated by scripts. I tried a different way, combining my regex search with regular searches with various words (case drive test meaning only would been) included or excluded. It took 17 combinations to exhaust all possibilities without timeout. The final total ended up at 2614, when the regex search alone tended to time out at about 400. I now know that this editing project will take about 7 times longer than I thought. The Special:CreateBigSearch approach would be helpful for a significant pool of editors who want regex results, don't need them immediately, and are intimidated by scripts. To get the total, we shouldn't have to repeatedly bifurcate the problem by asking, what if split it according to whether this word is in or out? And with Special:CreateBigSearch, the results would be all in one place instead of broken into artificial groups. I agree, it might never get coded up or approved, but it would be helpful.

Novem_Linguae, thank you for the explanation. I assume that there are statistics on how long regex searches take at different times of day and days of week. If so, these statistics should be made available to the users, and pages like [[:en:Help:Searching/Regex]] [https://en.wikipedia.org/wiki/Help:Searching/Regex] should have a link to this info, so users can schedule their "worst" regex searches for times when things usually go faster. Also, the timing process that shuts down the actual process could allow more time during periods when the server isn't as busy, and if users could see the chart, they would know when their chances were better.

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!