Community
Participate
Working Groups
Currently, the code templates support forces variables to be indicated in the template text as enclosed between "${" and "}", e.g., "${date}". However, I have created a plugin for the NSIS scripting language in which ${ xyz} is a valid language construct, hence I would like to indicate variables using a different pattern, i.e., enclosed between % symbols, e.g., "%date%". However, the jface template source code has the template pattern hard-coded to using the "${xyz}" pattern. Please enhance the template support to accept other variable patterns.
Where is the JFace template support code you are referring to?
org.eclipse.jface.text.templates in the org.eclipse.text plugin. Specifically, org.eclipse.jface.text.templates.TemplateTranslator has the following Regex pattern defined for detecting variables: private static final Pattern ESCAPE_PATTERN= Pattern.compile("\\$\\$|\\$\\{\\s*+(\\w*+)\\s*+(?::\\s*+((?:\\w++\\.)*\\w++)\\s*+(?:\\(\\s*+((?:(?:\\w++\\.)*\\w++\\s*+,\\s*+)*(?:\\w++\\.)*\\w++)\\s*+\\))?\\s*+)?\\}|\\$"); //$NON-NLS-1$ Also, the parse(String string) method has the "$" character hard-coded for detecting template variable starts.
You can escape the '$' with another '$', e.g. in your case simply enter $${xyz}
I understand that. However my concern is that it may be confusing to the end user. Never mind, I can cannibalize the existing implementation and create something that functions the way I want.
If this is important for you, then you might want to implement the correct solution and contribute it back to the Eclipse project. If I get a good quality patch I would accept it.
Well, the easiest way is to: a) Allow clients to override the parse() method of TemplateTranslator b) Make the constructors of TemplateVariableType public.
Actually, now that I look at it, there is no need to make the constructors of TemplateVariableType public. However, is there any particular reason why you don't want clients to override the translate() methods of TemplateTranslator? I have been able to implement what I need simply by overriding the translate() methods.
>However, is there any particular reason why you don't want clients to override >the translate() methods of TemplateTranslator? The main reason is that the string representation in the TemplateBuffer is created by the internal parser and if clients can provide that string it could later break the framework when the proposal is applied.
I am not quite sure I understand why, but I'll take your word for it. As far as I can see, if parse() returns a valid TemplateBuffer which can be resolved using the registered resolvers for the TemplateVariables within the buffer, then there should not be a problem. Perhaps I am missing something. Never mind.
We would have to go trough our code and make sure that everywhere where we use the string from the TemplateBuffer we do not rely on the format currently generated by the internal parse() method. I'm not saying it can't be done.
