: that for a newbie, there is a certain confusion when it comes to "one : thing with comma a separated list, the other can have multiple : values". This could also be solved perfectly in the wiki (i.e. making : it very clear multiple GET params with the same name can be used, or : if a comma-separated list should be used).
We've certainly tried to be consistent about this. Any param that "parses" the value you give it should say so on the wiki ("sort" goes into a lot of detail on this, as does "fl" ... things like "qf" forthe DismaxHandler could probably be more explicit about spliting on whitespace instead of just giving an example). Any param that can be specified multiple times should say "This parameter can be specified multiple times..." and explain how multiple values will be interpreted. If you notice any inconsistencies or vagueness in the wiki, feel free to clean it up (if you don't know what the right thing to write is, just ask) ... I've said it many times in the past: "Experts" tend to be the worst documentation writters for new users, because they are too aware of how things work to really understand what type of information is most needed (or already obvious) to new users. *Hopefully* I'll get some time tomorow to make progress on SOLR-555 and we won't have ambiguious wiki pages for plugins with inconsistently formated sections on each param -- we can start having more explict structured info about all of the concepts that are really "core" to how a param works (ie: name, datatype, is it multivalued, can it be overridden per field, what is/are the value(s) used for). Of course: the "structured" documentation built from the code would still link to (or dare i say: iframe include?) wiki pages where users can add notes, comments, and additional exampless of configuration and use. (much like the PHP documentation, which really setthe bar for integrating "refrence" documentation with user contributed adendums) -Hoss