Here is a copy of a recent bug report that I sent to the developers.
OS X 10.6.7
On OS X, Command-W always closes the front window as does clicking on the red "stop-light" button at the upper right of the window. It's bizarre that it doesn't work on some non-native widget sets. You might have to find a work-around or appeal the the widget-maker group for a fix. It is maddening to first hit Command-W out out of decades of habit then try closing by clicking on the red button and then having to search the window for the non-standard Close button--or is it the Cancel or OK or Save buttons? I'm not being picky about these things--Mac users expect a correct interface and a consistent interface. Just maddening.
The Edit Macro... window doesn't respond to most mouse clicks.
As a feature request, make the first 10 tabs quickly accessible by hitting Command-Number where Number is 0..9. This is common but not universal among editors and is really efficient. Oh--I see that UE instead uses those key combinations to access a bunch of clipboards. Oh well (sigh).
On OS X, Command-E is a standard combination that enters the selected text into the Find buffer. The Find buffer is also shared system-wide with other applications with a Find function. E.g., enter a string in one application, switch to another application, and the same string is already in that application's find buffer.
On OS X, preference changes are saved when the preference window is closed. There is no "Apply" stage.
Clicking once on files in the Open list should reveal that file in its tab. UE requires clicking twice, an action for which Mac users would expect some kind of "opening" action, in this case, to open in a separate window. Which leads me to...
I can't figure out how to open a file's content into a separate editor window. This should be made obvious in a contextual menu from a file tab or the file icon in the Open list or from the displayed file content in its tab window. Unless this is not possible by design, which is a real deal-killer--all-in-one editors are extremely wasteful of precious screen space, and editing code by viewing only one window at a time is just wrong, and screen-splitters (if UE has them) are not a solution because it does nothing to increase the efficiency of screen usage.
I personally need Ada functionality. Once earlier I followed the instructions on how to do that but it had absolutely no effect. I won't try again until I know I'll have success.
In at leat the Places window, there is a horizontal scroll bar to allow viewing long file names. However, when I use the standard two-finger horizontal drag in the content region on a trackpad in the content region, the list contents scroll _vertically_. When I do the same on the actual scroll bar, nothing happens. I don't know if this occurs in other places.
On OS X, Shift-Command-[ and Shift-Command-] are standard keystrokes for navigating to the previous and next tabs in programs that have a tabbed window.
All of these problems are evident in only few (5-10) minutes of use. It's possible that I missed some features by not using the program longer before reporting, but I've already donated more of my time to this bug report than the program is worth.