Community
Participate
Working Groups
Doc on Templates says I can use ${cursor} both java and javadoc comments. However when I tried to use it the template for a method comment I could not as the edit dialog said that ${cursor} was an unknown variable.
Works fine for me if I add a javadoc template on the Java->Editor->Templates preference page. Note that you cannot use the cursor variable for the special code generation templates on Java->Code Style->Code Templates, as these are not interactive. What doc are you referring to that talks about the cursor variable?
o Yes I am looking Java->Code Style->Code Templates. o Think it is wrong that users are presented with two different types of templates. Particularly if the distinction is 'interactive'. Consider what the user experience is - 1. the user is typing in the editor and they begin a javadoc comment. 2. the editor notices this and generates a comment based on the location where the edit is occuring. ( i.e. Generates a comment for a method. ) Isn't this an interaction? o Here is how I found this doc. 1. Was in dlg and wanted to know what ${tags} was so hit F1. 2. Above didn't provide answer so searched for ${tags}. Got way too many hits. 3. Tried ${tags} templates instead and got much more reasonable result set. ( 5 hits ) 4. While first hit didn't give me what I want it had link, 'Template preferences', to http://127.0.0.1:59492/help/index.jsp? topic=/org.eclipse.jdt.doc.user/reference/ref-preferences-templates.htm And while above page didnt' tell me what in the world ${tags} was it did give me this little tidbit- ${cursor} works in javadoc and java. o Finally the exact thing I was want is was support for /** * <!-- ${eclosing_method} --> * * ${cursor} * * ${tags} * * @since 1.0 * @author me */ where ${cursor} just denotes where the caret is positioned after the code has been inserted. As it stands what I am getting is something like /** * ${cursor} * <!-- ${enclosing_method} --> * * * * ${tags} * * @since 1.0 * @author me */ .
There are templates (that's what the doc talks about) and Code Templates. They are two different things.
Am not going away empty handed.... Want at least one of o ${cursor} support in code templates o change doc so that every page warns you that there are 'templates' and 'code templates' and that they are not the same. o get rid of 'code templates' and just have templates, as code templates just add confusion.
>o ${cursor} support in code templates This is not possible. Example: you create a new class which has some methods. Several code templates are used to create that class. Where would the caret be at the end? We have no plans to cange the doc at the moment.
So looking back over this I see I don't mention how I got into this mess initially.... I noticed when I typed /**<cr> just before a method the editor expanded some template. I investigated and found that it was 'code templates'. ( Assuming I have the names correct...) Now since I wanted something like /** * <!-- ${eclosing_method} --> * * ${cursor} * * ${tags} * * @since 1.0 * @author me */ and couldn't get it I logged a bug. Looking at the above situation doesn't it seem there is a hole somewhere? That is, if you cannot do this with templates because in templates you don't have conditions 'is getter', 'is setter', etc. and you cannot do this with code templates because you cannot specify the cursor location. Perhaps it is the case that I what I should have really done is logged two bugs - i. Need access to member categories ( method, getter, setter, ... ) in templates. ii. When user types /**<cr> just before a member editor should expand a template instead of a code template. Where the second bug depends on the first.
There are two kinds of templates: - user templates which you can select from a list when invoking code assist or quick assist (Ctrl+1, Ctrl+Space). Those allow to place the caret since they are done while typing - code templates which are used then code (and comments) get generated. Those are also used e.g. if you add Javadoc comments to n methods. The caret will not be moved
Moving to the doc component.
Actually, we could offer the variable but only resolve it where appropriate. That's then bug 37312. *** This bug has been marked as a duplicate of bug 37312 ***
