Research so far:
Looking at what it will take to allow arbitrary namespace selection instead of single namespace with invert checkbox that selects all but the selected namespace.
appears to take a fair bit of code such as in SearchFormWidget.php and would require additional query adjustments.
Estimate this as a medium to hard (take a couple weeks) to get working and polished, and if javascript needs updating, additional time.
Wondering how important this capability is to the community.

Ah I see, will look at fixing all of these. Seems like there could be minor risk of breaking something so will test carefully.

This change appears to have been completed.
Cannot find references to Database::select(

Part of this should be resolved by T165538 - gerrit 761070 when content model changes.

Once RESTBase has be replaced, this issue should be resolved.
Need to verify this is resolved after that takes place.

Now that there is a linter_template text field in the database, adding features like this is now feasible.
Evaluating feature list value and prioritizing.

Hmm, I see.

As the Linter UI can select a single page by Title or Title Prefix, from the search form found under the category list in the main Special:LinterErrors page, my hope is that this provides an adequate report focussing on just one pages errors. Using it, I can navigate from the reports error links to the wiki page, fix the highlighted error, save and then return to the report and select the next error. While not as convenient as LintHint which inspires me, hopefully it is adequate for others who don't use LintHint.

Three new columns have been added to the Linter table, are being written in all production wikis and the linter_params data was migrated in old records to be the same as newly written records using maintenance scripts.

Question: does the current namespace selection and invert selection check box adequately cover this feature request sufficiently. It does allow the exclusion of talk namespace while including all others.

Field added, maintenance migrate run and results verified in Beta and production.

Each linter_cat category defines what linter_params content is relevant and many categories do not have tag or template data. I did some quick checks using Quarry and all looks good for categories that should and should not have content in those fields. Some of the checks are listed below:

Ah sorry, the logger interface was recommended. I wish I had known about its quirks and limitations. Live and learn. Next time I will just output to console.

There is logging in both scripts:

		$logger = LoggerFactory::getInstance( 'MigrateNamespaceChannel' );

. . .

			$logger->info( 'Migrated ' . $updated . " page IDs\n" );

Also created a unit test to verify the tag and template field string truncation code in the linter RecordLintJob / Database code.

Ah this is great, no more drift on linter table. Thanks Amir :-)

Created https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/883649
to fix the definition of linter_params to not be nullable.

If you just edit a page with the wikitext editor, and then view it with the normal page read view, that doesn't require parsoid to reparse the page, and thus until parsoid parses it, the linter errors will not be updated. One way I trick the page into being reparsed, instead of just being in a job queue that is delayed, is by switching between wikitext and VE and back, which forces a reparse for VE to display the page. At least on my local machine this works, and I suspect it also works on production.

My research finds no evidence that the Linter error reports provide table headers for each column/field that are clickable to cause the report to be sorted on that column. Mehta (Kunal) was the last engineer to touch code that controls OOUI's sort feature which was disabled in the linter pager table code as reported by git log blame:
Mehta has function isFieldSortable() returning false since 2016, and the default sort is set to linter_id also since 2016

Looking into why the ability to sort based on clicking on table headings is not working.

Implemented in:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/769772

Implemented in:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/769772

Arlo added 'proofread-page' as an additional lintable content model in:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/766195

Search for a specific page implemented in:
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/769772
Ability to display all lint errors in a single page provided by LintHint.

I researched what it would take for a "stock" wikimedia install to provide a subset of the features of LintHint (all lint errors on a single page highlighted, possibly with mouse roll over category display in a popup bubble. The default editor in OOUI would need significant enhancements outside the scope of the project to provide a display of all lints for a single page like LintHint can already do. I looked into the VE wikitext editor and the alternative syntax highlighting editor available as a Beta feature when VE is installed. My goals recently are better search narrowing functionality and not to replace LintHint, or to provide all lint errors on a single page as highlighted regions. All lints for a single page is what LintHint provides with a very attractive UI, as a list of all errors in one pane as clickable links that jump to a highlighted text region. My goals have been to offer better stock search capabilities and the next patch in this group is a search box from the special lint page bottom that allows the editor to specify a title prefix and get all pages with any category lint error that matches the partial title prefix. This allows editors that have created a directory tree structure for all their pages in the title, can search for only those pages. For editors that want a more advanced all lints on a single page, LintHint is not too hard to enable for wikis with VE enabled.

It looks like at least searching and reporting by namespace, by category, by a title prefix is possible (database performance impacts are what gate what is safe to implement, not whether a feature technically can be implemented). Search by prefix, by namespace, for all categories also maybe possible, and be added to the report type provided for all lints for a single page. Would be good to get feedback on whether that is also a useful search/report type. But for now I will focus on prefix, namespace and category as search criteria report.

I added a brief description of the new feature "Show all linter errors for a specific page" in the help page for linter. Due to this page being translated, the guidance is to keep changes brief, but hopefully I have covered its use, caveat of syntax highlighting interfering with its highlighting, and how to work from bottom up to avoid changing character offsets.
If you feel I need to add something more, let me know.
Again thanks for your care and comments.

The new namespace column may allow the query optimizer to improve this performance significantly.

Jonesey95 and Izno,
Thanks for your care and comments. The new all lints for a single page is located at the bottom of the special lints page and takes a page titles such as "User:Delta40" and returns all lints for that page in a list which allows you to use the edit button to take you to the highlighted area of the page wikitext source. To edit a bunch of errors on a single page, I suggest editing the last error first so that any insertion or deletion of characters happens below where other errors are still present, before Parsoid regenerates the linter error list (due to caching and timeouts, etc.). This feature was added so we have a native implementation that is similar to LintHint, but requires no special efforts on the editors part to setup and use LintHint. LintHint can also add more features that we arn't able to add for various reasons.
I'll look at where in the doc I should add some info about this new feature.

Is the newish "Show all linter errors for a specific page" feature helping and providing most of what this ticket was requesting?
Other selection features are in the works (waiting on new fields being added to the linter table) such as namespace and template and tag allowing further narrowing of search results.

Two tasks address some of these stale linter data issues:
Delete lint error records when content model changes from wikitext
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/761070
and
Delete lint errors when blank page saved... (the title of this ticket implies content model change also needed but only requirement is saving a blank page regardless of content model.
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/766872

Lint errors are now being deleted during save of a blank page while the content model is being changed.
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Linter/+/766872

So in the process of creating a set of patches that add a column for part 1, start populating the new column when new records are written in part 2, will do a full pass through existing records migrating data derived form data in another column to populate the new column completely in part 3, then add code to utilize the new column for search/reporting in part 4, then do a complete refactor of old and new code, removing old code and moving new code around as needed and removing config variable enablements, etc.

It was unintentional, sorry about that,

I will look into this as I already have attempted to improve the error count results and this continues that effort in:
https://phabricator.wikimedia.org/T194872

I believe I have a fix for this and want this fix done prior to adding additional tests to RecordListJobTest.php
The issue appears to be that RecordLintJob.php run() checks the revision and then delays the job run which in a production environment is a good idea, but not for this test, so I removed the revision property. I also set the pageID to 0 instead of 1 as that seems to be a new default allowing the test to find the inserted lint error appropriately.

The Linter error no longer is generated in this case, so the issue of error running to end of page is resolved.
A new phab ticket covering broken use of Wikilink with unclosed ]] might be worth creating as a low priority.

Exploring why Linter error counts are still incorrect after a page is deleted.

So gerrit patch 677673 modifies the code which generates estimated linter error counts for a category to produce an accurate count when the actual count in the database is less than (20) or whatever MAX_ACCURATE_COUNT is set to in Database.php in the Linter extension directory. While this change will help produce more accurate counts, other issues of when the object cache gets refreshed still apply as does errors that become stale when a page with errors is deleted, prior to a full refresh of the Linter errors from all active pages is performed. Still this should provide better counts in most circumstances.
I am not going to close this ticket as resolved, until a more complete solution is implemented that has fewer caveats.

Subbu wrote in IRC: