Can I have a copy of your patch (including the result of your tweaking)?

Committed, thanks.

Alright, this conversation really belongs on the lists, not in a 
bug/feature tracking system but I will respond to these comments here 
one last time, I think you misunderstood me, I am trying to help you 
in whatever it is you are trying to do by editing/changing the 
prefs.php.dist file.
In your previous post you specifically mentioned configuring what 
appears in the horde menu.  I was pointing out to you that the 
icons/links that appear in the horde menu are not configured in the 
prefs.php file, they are configured via the Administration->Settings 
interface (which generates the file conf.php as you pointed out).



Since there are only a few reasons for an administrator to actually 
edit the prefs.php file, I took some (apparently incorrect) guesses as 
to what you might be trying to accomplish by changing this file,  such 
as creating locked prefs,  providing default values for some values, 
or even changing what sections each pref is contained in.  From your 
interest in the undocumented data types it occurred to me that you 
might be trying to add your own prefs to the file, which, of course 
would require code to be added somewhere in horde/application to 
actually use it...which led me to the (again, incorrect) assumption 
that you had enough knowledge about the structure of horde apps to 
provide a meaningful patch.
Again, I agree with you on this point - in theory.  As is the case in 
most open source projects, documentation is usually lacking.  Since 
this project is worked on by people *volunteering * their time and 
knowledge, they tend to work on the things that interest them, and 
that is usually coding.



And, FYI there are many HOWTOs, tricks, documentation, etc on our wiki 
that may prove to be very helpful to an admin new to Horde.
I would hesitate to say the developers, who are working for free, had 
neglected any duty in this case...and it is these administrators that 
do take the time to track down something in the code that is lacking, 
be it a bug in functionality or lacking documentation, and provide 
fixes back to the project that help make this (and other open source 
projects) such a great platform.
...and thank you for taking the time to help out and provide whatever 
information you were able to deduce.  Every contribution helps.



<end of rant>

No. This only the coonfig.php is setup in this way; the other 
config/*.php have to be set up manually, and this is why the 
administrator needs a comprehensive documentation of the pertinent 
conventions and options.
It is certainly less work for everybody, if the administrators can 
find the neccessary documentation in the ditribution and need not 
bother all the subscribers of those lists with trivial questions.
When a developer invents a new sort of entry for some configuration 
file (such as a new prefs type), it would him cost only some minutes 
to add one or two lines, in the pertinent config file, while the 
information is readily available. If he, however, has neclected this 
duty, it will cause headaches to countless administrators, and it will 
cost hours to close the gap, later.



In this particular case, I had hoped that somebody, who knows the 
code, could provide the missing details (just a few lines) straight 
off the bat. Now, after I have spent some hours trying to fill in the 
missing information, still somebody knowledgable has to check, and 
amend, my proposal.

Here is my proposed patch to amend the in-code documentation.



As usual, I have produced this patch with the "diff -c .." command, 
but somehow the format differs from earlier patches I have made. I do 
not know why this is so. I hope that you can use that patch, 
nevertheless.



As said before, I do not know how to fill in the missing details. I 
have spent three hours testing, in order to fill the documentation 
gaps, but there are still some questions unresolved. I have marked 
these points with double question marks, in the attached patch.



I have not located the code where these configuration settings are 
evaluated; all I have done is to collect evidence from the 
config/prefs.php.dist, and imp/config/prefs.php.dist, files and to 
inspect the HTML code generated for various option sub-menus. Thence, 
e. g., the term "apparently", and the pertinent '??' mark. (I do not 
want to sell my conjectures for steadfast truth.)



So, some knowledgeable person should check this proposal, mend my 
errors, and remove the question marks (and the "apparently").

If you are referring to configuring what appears in the horde menu, 
that is done by an administrator, via the 'setup' screens for each 
application.  If *you* are asking, as an administrator how to do this, 
or how to configure 'locked' prefs,  or even if your writing your own 
horde application, you will find *very* friendly and helpful advise on 
the mailling lists.
Depending on what documentation you are looking for there are INSTALL 
files in the docs/ directories and there is *a lot* of useful 
information on our wiki (wiki.horde.org).
In some cases, I would agree, but given the choice of fixing actual 
bugs in functionality, implementing new, requested features, or 
writing documentation - I know what most of the (relatively few) 
developers that contribute to the project would choose...

Alright, tomorrow, I'll provide a patch listing them. However, the 
explanation will read "dunno", in every single case.

It seems to me that  if you know enough about the types to know that 
they are 'missing' from the list, you would know enough to provide a 
simple, 'meaningful' patch that adds them to that list?

Hello Jan,



the initial comment in config/prefs.php.dist is the only documentation 
available on the topic of configuring the Horde, and application, 
menus. (At least I am not aware of any other documentation on this 
topic).



Hence, while the documentation may well be terse, it should really be 
comprehensive.



Hence, I deem this ticket a documentation error (i. e. a bug) rather 
than a feature request (enhancement). Also, I deem any ommission in 
the documentation serious enough to deserve a higher priority than you 
have assigned to this ticket.



Cheers,

   OS

Hello Jan,



I had hoped that you, the developers, know about the configuration 
options of your program. I, the uninitiated user, do not know the 
meaning of these types, hence this bug report.



After finding an undocumented entry in horde/config/prefs.php, I have 
done a grep over Horde's and Imp's prefs.php.dist, and have extracted 
all types used there. This is all I know about this issue, and I have 
reported my findings, in the 1st place.



So I cannot provide a meaningful patch.



Regards,

   OS

Patch?

The initial comment of config/prefs.php describes the preference types:

'special',

'select'

  'checkbox'

  'implicit'

  'password'

'enum'.

However, in config/prefs.php and imp/config/prefs.php, I have found 
those addional preference types:

'link'

'number'

'text'

'textarea'

Please, amend that comment, accordingly.



Please describe also, which types can be suppressed in the UI by 
setting the respective 'locked' component. (I have just found that 
setting 'locked' => true has no effect on a link type member.)