View Source

Summarizing discussion from people on the interest list.

Editor

Likes

the editor works pretty well to help with auto indenting etc to make things look pretty and provide easy to read formatting.

Dislikes

editor is quirky
forward and backward arrows don't always work
undo is character by character
a number of people pointed out the inefficient and sluggish error checking and syntax highlighting. there are little user benefits for key-stroke-by-keystroke checking while the user is typing, 2) the constant checking is unnecessary usually and really slows down typing performance. emphasis on fixing this feature. NetBeans, for example, only sends off a check event IF the user has stopped typing for 0.5 seconds (they call this the parsing and indexing loop).
near the end of a line, the cursor seems to shift slightly so that it's not between characters.
rule/token name completion should automatically select the top choice so you can just hit return

Desired features

add ability to see matching closing/opening parenthesis/braces etc.
the "find" functionality should work in the console and other Windows
code completion for $x.attribute
using reflection, if the target allows, to code completion on the field/methods of an object like "$user." for some label user.
code complete the options

people like the visualizations: syntax diagrams (with ambiguous passed highlighting), AST, parse tree.

dislikes

Resolving ambiguities in the syntax diagrams is not always obvious; tempting but doesn't seem to help unless you already know what the problem is
Don't use A..B notation in trees or syntax diagrams; For parser it makes no sense.

A user reports that he prefers to debug and the like via Java code
A user reports that he likes the debugger, but can't use it with his large project with all of his build scripts. perhaps this means we need to make the remote debug thing more obvious?

for prototyping, quick check parsers working
The "run" but should be more obvious.
inconsistent that you type in the input on the left for the interpreter, but not for the debugger
the interpreter should ignore the actions if there are any and do the best job you cannot input (e.g., it might not work if there predicates)

export syntax highlighted html; example HTML from grammar. (If you click a defining rule name, you'll be taken to the ANTLRWorks graphical presentation of the rule)
Export PDF of a selected rule and all invoke rules or all of the rules.
Most of my students generate antlr code in the same folder as the grammar, so it might be nice if the output path was the empty string by default. Others may prefer it the way it is.
Make it easier to generate -debug output with a menu option rather than having to change preferences.

A user reports: I think of the interpreter and debugger as modes. Modes don't belong on tabs.
Would be nice to design this new version has a set of widgets that cooperate so that people can take pieces of it and inject into other development environments or whatever
Allow the visualization window to "Pin" to the bottom, like most IDE's do, effectively allowing it to auto hide.

console spews continuous error messages
clear the console when you generate or run any other kind of analysis.
More documentation; maybe that's a book thing
Preferences can only be set once a grammar is open. Preferences should be able to be set regardless of having a grammar open.
tool tips about what the various stuff is; e.g., what is an UP token?
It would be nice if the preferences window followed the standard paradigm of an Apply, Ok, and Cancel buttons. If no settings need to be changed, the apply button is greyed out.

I've only heard from a small number of people at this point, less than 24 hours after my initial post, but no one mentioned:

Refactoring
displaying decision DFA (well, one person mentioned to say that sometimes it gets stuck)
only one person mentioned showing the generated code
group/ungroup rules, rule collapsing