The GWT debugger options are confusing

[supersteves]

There are many checkboxes and they don't seem to correlate obviously to

• command-line options java -jar compiler.jar --help
• CompilerOptions.java methods/fields (which I personally use directly) https://github.com/google/closure-compiler/wiki/Using-the-Compiler's-Java-API
• service API https://developers.google.com/closure/compiler/docs/api-ref
• additional webservice options https://github.com/google/closure-compiler/wiki/Additional-Webservice-Options

All this is rather confusing. To make it slightly easier when trying to create a test case in the debugger, I suggest updating the CompilationParam enum to have additional properties which describe how they map to at least some of the above options, and setting a tooltip in DebuggerGwtMain.

I might do this in a spare moment if you indicate it will be accepted as a PR.

[dimvar]

We use the debugger to debug individual passes. If you want to repro something using simple or advanced optimizations, why can't you use http://closure-compiler.appspot.com?

[supersteves]

I use the debugger to:

• find out what types are being inferred
• try to reproduce isolated test cases for specific weird errors or crashes so I can submit them; often I need to specify externs

... also I only discovered that other page yesterday!

I also don't know how to map the ~50 customisations we make (to CompilerOptions.java) to this page, e.g. specifying language in/out? If these are command-line options, I'm only familiar with the Java API.

All I'm suggesting is adding a tooltip to explain what Java API (and probably command-line option) each checkbox correlates to. And doing it myself. But only if it won't get rejected.

[MatrixFrog]

The debugger UX could definitely use some love. I don't see a reason to reject it, but I kinda feel like I'm still digging myself out from a pile of email after the holidays (which is why I haven't responded on several existing PRs), so it might take some time to get merged.