0e4e0c0af65eea70f64edbc68348ce0972c4bbf4
braney
  Fri Aug 28 16:45:00 2026 -0700
Correct the track types listed for trackDb settings, and the hub settings list

The "For Types" list in the trackDb docs was wrong for about sixty settings, so
the docs named the wrong track types for settings that have always worked. Most
named only the older type and left out its big* counterpart. The clearest case
is the multiple-alignment family: a bigMaf track is drawn and configured by the
same code as a wigMaf track, but only speciesOrder said so, while irows,
itemFirstCharCase, speciesGroups, speciesCodonDefault, speciesDefaultOff,
treeImage, pairwiseHeight and speciesUseFile all claimed wigMaf alone. The
hapCluster settings said vcf and not vcfTabix. noScoreFilter said bed while its
own example uses type bigBed 6 +. Six settings said "all" for something that
only works on item tracks.

Two documented settings do not exist. pslSequence describes a variable that was
replaced by the baseColor family long before the setting was listed, and nothing
has read either spelling since; it is removed. noStems is renamed to
lollyNoStems, which is what the Browser actually reads. That one mattered:
hubCheck builds its list of valid settings from trackDbHub.html, so it accepted
the spelling that does nothing and rejected the one that works.

Fourteen settings that work in hubs had no entry in the hub spec, so hubCheck
reported them as unrecognized. They are listed now: chainColor,
chainNormScoreAvailable, pairwiseHeight, barChartMatrixUrl, mouseOverFunction,
intronGap, filterBy, baseColorTickColor, speciesGroups, speciesDefaultOff,
speciesCodonDefault, itemFirstCharCase, irows, and canPack with
configureByPopup and origAssembly. The last three, along with filterBy and
baseColorTickColor, were marked "NOT FOR HUBS", which was wrong: the Browser
reads them from a hub's trackDb the same way it reads them from ours.

The type setting on the hub page listed every type the Browser knows, including
ones that only work for tracks loaded into our own databases. It now shows only
the types a hub can use. A hub-specific blurb for this already existed and had
never been referenced.

Three settings had no blurb at all, so the generated trackDbSettings.json never
saw them: metadata, noInherit and useScore. Written, and the five hand-written
copies in trackDbDoc.html that had drifted from the library are brought back
into line.

The library's header told the reader to always check their work in
trackDbTestBlurbs.html, which was deleted in November 2025. It now points at
"make settings" instead. That target regenerates trackDbSettings.yaml and .json,
which are updated here, and its name map gains an entry so the hub-specific type
blurb is still keyed as "type".

refs #37908

diff --git src/hg/htdocs/goldenPath/help/trackDb/trackDbSettingsGen.py src/hg/htdocs/goldenPath/help/trackDb/trackDbSettingsGen.py
index d7bdd54c139..3a3e857e1d6 100644
--- src/hg/htdocs/goldenPath/help/trackDb/trackDbSettingsGen.py
+++ src/hg/htdocs/goldenPath/help/trackDb/trackDbSettingsGen.py
@@ -28,30 +28,31 @@
 JSON_OUT = os.path.join(HERE, "trackDbSettings.json")
 
 # Stanzas a setting can appear in. hub.txt and genomes.txt are stanzas of their own, so a
 # trackDb "common" setting spans the four track roles, not all six.
 ROLE_ORDER = ["hub", "genome", "super", "composite", "view", "leaf"]
 ALL_ROLES = ["super", "composite", "view", "leaf"]
 
 # Doc sections named for their anchor because the keyword collides with a trackDb setting
 # of the same name. The keyword is what goes in a hub file, so map them back.
 DOC_NAME_TO_KEYWORD = {
     "hubShortLabel": "shortLabel",
     "hubLongLabel": "longLabel",
     "hubGenome": "genome",
     "trackDbFile": "trackDb",
     "groupsFile": "groups",
+    "type_for_hubs": "type",
 }
 
 # The docs use HTML entities that decode to non-ASCII punctuation. Fold them: "format" is
 # a syntax template someone pastes into a hub file, and the generated files are ASCII.
 UNICODE_TO_ASCII = {
     "\u00a0": " ",     # nbsp
     "\u2013": "-",     # ndash
     "\u2014": "-",     # mdash
     "\u2018": "'",     # lsquo
     "\u2019": "'",     # rsquo
     "\u201c": '"',     # ldquo
     "\u201d": '"',     # rdquo
     "\u2026": "...",   # hellip
 }