I don't really understand what you are saying here. Could you give an example of this type of compression, or some pointers to more information about it?
I only used this 'prefix compression' because I knew it, and it is easy to decompress in JavaScript. It is also quite effective with this list (lots of common prefixes).
See the compression method sent in by Mitja :) Seems to be promising in size :)
Dynamically loading files using JavaScript is not so easy.
Regardless of how easy it is, as it was said in this conversation before, we are not going to add any solution requiring more requests on our servers. The whole point of this new function lookup method is to ease the user's life *and* take off the extra lookup requests from our server in case the user does not type the function name correctly. So we are not going to split the JS file, and load parts dinamically. We are going to compress, compress and compress...
I really think loading the full file at once is the best way to go. If the file hasn't loaded yet, you can use the search box like it works now: enter a function name, and press enter to go to the correct manual page.
Only if the file has loaded, a list appears when you enter values. If you enter an existing function name, the script will recognise this, and send you directly to the correct manual page.
So it is only an addition, which doesn't make the loading of the main page any slower, just like loading an image doesn't prevent you from reading the text on the same page.
If we offer the user a direct search function, it should work instantly. That means either it doesn't give any results (if the JS file hasn't loaded yet), or it gives results as you type. You don't have time to wait for an additional file to load.
Hm, I see what you mean here, I have not meant this solution originally, but the maunal lookup search box we had for years as a different lookup solution. But programatically everything is possible as you explained, so why not? :)
Goba
