Bug 401057

Comment 1 Mateusz Matela 2016-01-10 18:48:54 EST

I'm not sure I understand your problem, but maybe it would be more reasonable to add template variables that resolve into formatter off/on tags?

Comment 2 Heiko Böttger 2016-01-11 02:36:15 EST

Adding a template variable may resolve the issue. I wasn't precise enought about what type of template I ment. The problem exists when using a code generator like ecore/xtend providing some predefined templates to generate code. Well one option would be to read out the target projects code formatter settings or a template variable as you suggest. But you need to support this in the code generator either as built-in function or by using an extension mechnism of that generator.

However that doesn't solve the problem that existing code can only be formatted correctly when the tags are configured correctly. For example copying code from one project to another with different settings always requires to update the formatter tags in the comments. Wouldn't it be much easier to just define the formatter tags to fixed values which cannot change insteadof adding a template variable. So my intend for this bug report was to have something that cannot be configured and where everyone can count on. As far as I know the NLS tags for national language,the keywords FIXME and TODO are not configurable and the same applies to other javadoc tags, why should the formatter be.

May be a better solution instead of defining a fixed value only, is to have a  default that cannot be changed and if the user wants it, one or may be a list of custom defined tags.

Comment 3 Mateusz Matela 2016-01-12 17:23:48 EST

(In reply to Heiko  Böttger from comment #2)
> However that doesn't solve the problem that existing code can only be
> formatted correctly when the tags are configured correctly.
But it can be quickly fixed with a simple find&replace, right? :)
> For example copying code from one project to another with different settings
> always requires to update the formatter tags in the comments.
I see it can be a hassle, but it's more of a general problem that when moving code between projects/workspaces, they have to be configured properly, like have a compatible compiler level and dependencies set up.

> Wouldn't it be much
> easier to just define the formatter tags to fixed values which cannot change
> insteadof adding a template variable. So my intend for this bug report was
> to have something that cannot be configured and where everyone can count on.
That's out of the question at this stage, it would break things for people who already use custom tags. Since even your clients want to change these tags, it shows the customization is necessary.

> As far as I know the NLS tags for national language,the keywords FIXME and
> TODO are not configurable and the same applies to other javadoc tags, why
> should the formatter be.
TODO and FIXME are configurable, even though they're pretty much world wide standard. You're right about NLS, but I'm not sure it's an example of a successful idea.

> May be a better solution instead of defining a fixed value only, is to have
> a  default that cannot be changed and if the user wants it, one or may be a
> list of custom defined tags.
A default that cannot be changed is problematic. How to choose such a value? What if someone happens to use the same tag for other purposes?
Having multiple custom tags is the most plausible, but frankly it seems awkward and I see no other scenario where it would be useful.

Comment 4 Heiko Böttger 2016-01-14 04:23:08 EST

(In reply to Mateusz Matela from comment #3)
> (In reply to Heiko  Böttger from comment #2)
> > However that doesn't solve the problem that existing code can only be
> > formatted correctly when the tags are configured correctly.
> But it can be quickly fixed with a simple find&replace, right? :)
> > For example copying code from one project to another with different settings
> > always requires to update the formatter tags in the comments.
> I see it can be a hassle, but it's more of a general problem that when
> moving code between projects/workspaces, they have to be configured
> properly, like have a compatible compiler level and dependencies set up.
> 
I agree you cannot move java 6 code to an java 5 project settings without updating the configuration. But in case of formatter tags there is no configuration option, because the old comments will break as soon as the tags are changed. What´s left is doing search and replace in the moved code which is always possible. In my scenario there would have been another solution, when talking about configuration Bug 105372 came into my mind. There it is requested to have multiple classpath configurations per source-folder. The same might be interesting for formatter settings. But since I no longer work with eclipse, I didn't follow bugreport to know if there was the progress, at least it's still open.

> > Wouldn't it be much
> > easier to just define the formatter tags to fixed values which cannot change
> > insteadof adding a template variable. So my intend for this bug report was
> > to have something that cannot be configured and where everyone can count on.
> That's out of the question at this stage, it would break things for people
> who already use custom tags. Since even your clients want to change these
> tags, it shows the customization is necessary.
> 
I am pretty sure that the clients I had at this time, didn't change the tag, they just have the possibility to do so, but I agree, changing behaviour later is always problematic for everyone using that feature, for that reason I proposed the additional tags solution.

> > As far as I know the NLS tags for national language,the keywords FIXME and
> > TODO are not configurable and the same applies to other javadoc tags, why
> > should the formatter be.
> TODO and FIXME are configurable, even though they're pretty much world wide
> standard. You're right about NLS, but I'm not sure it's an example of a
> successful idea.

Interesting, I wasn't aware about the possibility to configure TODO and FIXME, but I can imagine what a mess this might produce when exchange code with different settings :).
> 
> > May be a better solution instead of defining a fixed value only, is to have
> > a  default that cannot be changed and if the user wants it, one or may be a
> > list of custom defined tags.
> A default that cannot be changed is problematic. How to choose such a value?
> What if someone happens to use the same tag for other purposes?

I agree finding a default value is problematic, but that doesn't make it impossible. The current values in use are very unlikely to produce conflicts. But may be the eclipse foundation isn't able to define such a default and JSR would be the better way to do so.

> Having multiple custom tags is the most plausible, but frankly it seems
> awkward and I see no other scenario where it would be useful.

Right, it's a long time since I entered this feature request and it was already low priority for me. I have no problems if you close this as wontfix, it was just an idea to simplify things. I don't want to create another endless discussion as on Bug 262009 :).

Comment 5 Mateusz Matela 2016-01-14 16:41:19 EST

OK, thanks for the commets. Closing as wontfix.