johnfairh
commented
2 months ago This is a bit different to what I thought you were proposing in #1440 with your "children": ["file:GlobalUtils.h", "regex:*CommonPattern*"] example. The big difference is that there, you were just adding stuff to existing groups. Here you're trying to automatically fabricate a hierarchy of groups, and so have the additional problem of merging those into the overall group tree: it's a more ambitious problem!
The limitations of the left nav (only showing two levels) are not great here -- I'm not sure it's a step forward to not actually see (be able to search through) the list of constants (however long). (maybe if you can show a demo I'd change my mind here)
I feel that restricting the feature to just certain kinds of declaration (here, constants and functions) is not flexible enough for general use. It would be OK to parameterise it I suppose, but I'm not sure why users would want to see a mixture of by-kind ("Other Classes/classes") and by-file ("Constants/Foo.swift/FooConstants").
Options are (1) Group all left-over declarations by kind+source-file instead of by kind; or (2) Group a configured set of kinds of left-over declarations by kind+source-file, and group other kinds by kind alone.
Both/either option needs a config option to modify the default behaviour. Option (1) is a subset of (2), for (2) should probably have an 'all kinds' shortcut.
I don't understand what the demo is showing - the constants/functions pages just look empty to me?
Code changes look in the right kind of direction - you clearly have a good grasp of how everything fits together here.
doc_indexiterable.custom_categoriesare processed, group any remaining global constants / functions further based on the file they're in.Staged sample: https://serve-dot-zipline.appspot.com/asset/55d078ae-b243-597e-9a9d-257f931f2723/zpc/63fc25cv8le/GMSGeometryUtils%2BFunctions.html
Resolves #1400