Community
Participate
Working Groups
I200411111200 + jdt.core and ui from HEAD: In a java editor: interface I { static void m(/*caret_here*/); } The compiler message is "Illegal modifier for the interface method m in type I; only public & abstract are permitted". In the workbench window status line, '& ' is rendered as '_' (a mnemonic Alt+Space ?-). The spec for IStatusLineManager#set*Message(..) doesn't mention this behavior. Solving bug 2135 would probably solve this problem, too.
Status line for messages comes from Platform UI. AFAIK the & handling is native behavior and hence the only solution is to fix bug 2135.
Or maybe patching the string before being set if the same API applies as in Label.setText(String).
Another gem is the compiler warning for Arrays.asList(1, "X"); Status line says: Type safety : A generic array of ObjectComparable<?>Serializable is created for a varargs parameter ... and the S of Serializable is underlined. What the heck is ObjectComparable?
I see the problem and I think it needs to be addressed. Another question is whether it is a good idea to use '&' in problem messages. In my opinion the message reads badly even without this bug. Maybe worth a bug report against JDT Core. Markus? Susan, can you look at this bug (or better: bug 2135)? Thanks Dani
The bug for jdt.core is bug 154029.
In my opinion the error messages shouldn't use the mnemonic character. The word "and" should be used. If there is a legitimate case of needing to communicate the ampersand character in the message, then I'd be willing to bump up the priority in this bug. Is there such a case that we know about?
IMO, the workbench should not try to impose a restricted character set on clients of the status line. We cannot rule out that there are (human- | programming-) languages where & is a perfectly valid and common character. In the case of "...only public & abstract...", I agree that "and" would be better style. But in the case of "Object & Comparable<?> & Serializable", there's no way to avoid &, since the & character is the standard way how type intersections are expressed in Java 5.0.
Thanks for the example of type intersections, that is what I needed to understand. I'll mark this to be looked at during 3.3, keeping bug #2135 (using a read only text) in mind. One thing I want to do in 3.3 is clean up all the different error message area implementations in the dialog framework, and it's possible we could use the outcome of this to show the compiler errors. (See bug #148085)
*** Bug 169281 has been marked as a duplicate of this bug. ***
moving this to SWT for the future. CLabel hardcodes the text draw flags to include SWT.DRAW_MNEMONIC. This should be opened up to clients, since there are times when the label should not include a mnemonic. I don't think it's appropriate for JFace to render the label itself to work around this problem.
We could add this API, but it would be inconsist with the way native controls handle it. To get a &, you double them (&&).
OK, but then the bug should be moved back to Platform UI to escape &.
> OK, but then the bug should be moved back to Platform UI to escape &. Yes, back to Plat/UI. Filed bug 211696 for SWT to specify CLabel#setText(..).
*** Bug 107585 has been marked as a duplicate of this bug. ***
This should be fixed for 3.4, since org.eclipse.jface.action.StatusLineContributionItem became API with bug 102616.
Note that setToolTipText(String) has the same problem.
I've escaped any incoming & to && in StatusLineContributionItem PW
In I20071211-0010 PW
Not verified/fixed in M4. Looks like the fix also needs to go into org.eclipse.jface.action.StatusLine.
Created attachment 86318 [details] StatusLine v01 Fix for StatusLine: Arrays.asList(1, "X"); PW
Released >20080107 PW
In I20080205-0010 PW
