Community
Participate
Working Groups
I200311050952 using the following template ----------------------------- public ${enclosing_type}(${arguments}) { ${cursor} } ----------------------------- I get the following error: !ENTRY org.eclipse.jdt.ui 4 10001 Nov 17, 2003 14:26:29.847 !MESSAGE formatter failed to format (no edit returned). Will use unformatted text instead. kind: 0, string: public SetViewer(arguments) { /*${cursor}*/ } and the open and close brackets do not show up in the correct columns ( i.e don't get formatted).
caused by bug 23344 *** This bug has been marked as a duplicate of 23344 ***
are you sure that bug 23344 is the problem as you can clearly see in the resulting code the ${enclosing_type} variable has been resolved to SetViewer.
I guess I assumed that since bug 23344 said it's not expanded at all then this must be a dup ;-) Anyway will fix together. Annotated bug 23344 to explicitly check this bug.
one other thing I notice is that the other bug is reported agains 2.0.1 and this one is reported against 3.0
Works for me using I20031119.
it doesn't work for me though I20031119! must be a preferences thing!
Som you still get an error? I guess we use different formatter options can you attach me yours.
Created attachment 6867 [details] my preferences
Can be reproduced using attached preferences.
I20040303 Still reproducible. What happens is: - "${arguments}" is correctly replaced with "arguments" - the resulting string has a syntax error, "Types arguments" would work but template variables (${..}) are not allowed to contain spaces - code formatting fails due to the syntax error This is reproducible with similar default templates. Preferences do not appear to be significant.
the template formatter uses core formatting currently, which is a problem in not yet complete code snippets where the formatter does not produce anything usable.
could be fixed by not having this template: --------------------------------- public ${enclosing_type}(${}) { ${cursor} } --------------------------------- This way, you still get a tab stop between the parenthesis, but we do have a syntactically correct pattern to start with and the formatter does not choke on it. This is just a workaround - not sure though what we can do as long as we use the core formatter for templates. There may be many more instances where templates are not correct. Another workaround would be to disable using the formatter (on the preference page) and require people to format the templates as they want them to have inserted - not too cool for the standard templates.
> could be fixed by not having this template: ^^^ I meant to say that this template *would* fix this particular problem.
What about adding a new variable ${tab_stop}, or similar, that is replaced by nothing but the tab stop?
*** Bug 54357 has been marked as a duplicate of this bug. ***
*** Bug 53375 has been marked as a duplicate of this bug. ***
we should find a solution that at least "usually" works or disable the template code formatter preference.
fixed > 20040525
*** Bug 60220 has been marked as a duplicate of this bug. ***
start verifying
I opened bug 64521 for the enhancement in comment 14.
