Matching template brackets

[smallB]

I think that having matching template brackets highlighted would be quite nice (specially for metaprogramming tasks). Anyway, this would also make Code::Blocks behaving in more unified way:
Why do we highlight:
a) [ and ]
b) ( and )
but not < and >
?

[oBFusCATed]

Because it is hard to do. e need a semantic highlighting, but we don't have it currently.

Think about this:

Code

if (a<b && b>c)
   ...

This one should not be highlighted, but this:

Code

if (a<int>(5, 10)==5)
  ...

should.

If can describe an algorithm, which works correctly for all the cases, then we can implement it.

[smallB]

How about (for a start only):  
If 'a' is a template then:
1. '<' means start of template parameters,
2. If above applies, then next token must be a type or if a has integral type as a template param then this token must be of this type?
3. If 'a' isn't a template then '<' means less than.

[oBFusCATed]

How about (for a start only):  
If 'a' is a template then:

When we do brace matching, we don't know if a is template or not.
The brace matching is done in core, but knowing if a is template is done/stored in CC plugin.

[smallB]

But surely there must be a way to get this info from CC or get this info in other way?

[MortenMacFly]

But surely there must be a way to get this info from CC or get this info in other way?

Plugins are generally independent. This means, a plugin must provide an interface to the core to obtain data from it. For brackets / CC internals (i.e. the SearchTree) this is not the case.

[Jenna]

But surely there must be a way to get this info from CC or get this info in other way?

Plugins are generally independent. This means, a plugin must provide an interface to the core to obtain data from it. For brackets / CC internals (i.e. the SearchTree) this is not the case.

And what's more the core can not rely on cc, because (as all plugins) the user might have disabled it.

[Alpha]

As a suggestion, would it be possible for the core to query CC (to determine if it is active, and a supported version); then using the result, enable/disable the function to match < >?
In this way the core could take advantage of the existence of CC, with a fallback to its original state (so the core does not become dependent).

[oBFusCATed]

It can probably, but someone should do it.

[ollydbg]

Our parser does not do the semantic analysis, and the C++'s grammar it too complex and context depend, so We can't even give a precise information whether an identifier is a template or not, and it is much depend on the context. (by context, I mean the #include, using directive, #if ....., all the things can change the context information)

So, it is too hard to implement this kind of feature.

[Alpha]

... We can't even give a precise information whether an identifier is a template or not...

Does this mean that there are (a few) cases in which CC can guarantee that it has correctly determined if something is a template?  If so, matching could be limited to those cases.

The following algorithm matches some basic cases.  (I do not believe it will give any false positives, but I could be wrong.)

• Define registered type as either a static list of knowns (int, char, ...) or a dynamic list acquired from CC (if CC is detected as available).  (I assume that CC knows the available types because it provides code hints on them .)
• Find a '<' with no whitespace, operators, or escape codes (in other words, a single token or nothing) between it and the next '>'.
• If there is no text between the two, match them.
• If the text between the two is a registered type, match them.

[thomas]

Does this mean that there are (a few) cases in which CC can guarantee that it has correctly determined if something is a template?  If so, matching could be limited to those cases.

That's certainly not a good idea. Either such a feature should work (to the implementor's ability) 100% or not at all. If it works 50% of the time, it is not only worthless, but actually hindering workflow. People will wonder 50% of the time whether they did something wrong when they didn't, just because a color coding they expect does not show.

[Alpha]

What about having this as an editor setting that is disabled by default (and with a tool-tip explaining why)?  This way, people who go to the effort of activating it would be the ones who want it enough not to be bothered by sporadic behavior.  Also, it would give a spot for additional algorithms to be added as they become available.

[oBFusCATed]

Because it is a waste of time to implement something which will not work 100% and will be useful to very few people.

[smallB]

@obfuscated although I agree with you that it is rather not satisfactory situation when feature doesn't work 100% I have to take and issue.
Nothing works 100%. To greater or lesser extend.
Look at c::b's smartsense. Does it work for 100% of the time? No. Is it useful? Sure. Would it be good to have it improved? Yes, but you see this is only possible if the feature is at least partially implemented. You cannot improve unimplemented feature.
Again, I also cannot agree with you when you say that only few people would use it. From where this assurance comes from? If anything mass of people would at least try it and give feedback (which in turn would allow to improve this feature and so on and so on). Why do I say mass of people not few like you're saying? My reasoning is simple: I personally don't know a C++ dev who doesn't use templates.

[MortenMacFly]

From where this assurance comes from?

Simple: After years you are the first asking for this feature and I don't see many people agree.

However, even if we agree that such an option is useful, there are plenty of others that have higher priority. You can help at most by providing a patch. This would be a real time-saver.

[smallB]

@Morgen as I've already explained to a obfuscated "I'm not there yet" to work on patches, but you can surely count on me when my time come.
Regards

[Alpha]

Because it is a waste of time to implement something which will not work 100% and will be useful to very few people.

Thanks for the logic; I had lost sight of the big picture.

[chameleon]

I come here from a search in google.
Yes.
It is very helpful to highlight template braces.

Especially with C++11

Code

typename std::iterator_traits<typename std::remove_reference<C1>::type::iterator>::value_type();

[Alpha]

It is very helpful to highlight template braces.

Useful, yes, but very hard to implement.  Do you have ideas of how this could be done?