Bug 40110 - Colorization needed for #include <angles>
Summary: Colorization needed for #include <angles>
Status: RESOLVED FIXED
Alias: None
Product: CDT
Classification: Tools
Component: cdt-parser (show other bugs)
Version: 1.2   Edit
Hardware: All All
: P3 normal (vote)
Target Milestone: 4.0 M5   Edit
Assignee: Chris Recoskie CLA
QA Contact:
URL:
Whiteboard:
Keywords: contributed
Depends on:
Blocks: 75485
  Show dependency tree
 
Reported: 2003-07-15 10:30 EDT by Brent Nicolle CLA
Modified: 2008-06-20 10:36 EDT (History)
1 user (show)

See Also:


Attachments
proposed patch from Jason Montojo (submitted on his behalf) (12.43 KB, patch)
2006-09-25 10:22 EDT, Chris Recoskie CLA
bjorn.freeman-benson: iplog+
Details | Diff
Proposed patch (targeted for cdt_3_1) (18.32 KB, patch)
2006-09-25 16:02 EDT, Jason Montojo CLA
bjorn.freeman-benson: iplog+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Brent Nicolle CLA 2003-07-15 10:30:01 EDT
Consider:

#include "foo.h"
#include <bar.h>

Because #include is a recognized keyword, it is colorized in the editor.
Because "foo.h" is tokenized as a string, it is colorized in the editor.
Because <bar.h> is not a proper string, it is not colorized.
It looks wrong, and encourages the user to use "dquotes" instead of <angles>.

A mature software project would not want the editor to encourage
one kind of include over another.
(EMACS colorizes both "this" and <that>.)
Comment 1 John Camelon CLA 2003-07-15 10:32:58 EDT
Actually, this isn't a parser thing, this is an editor feature using simple 
rules for syntax colouring.  

I'll fire this over to Alain ... (for a change :-)
Comment 2 Kleo Hapitas CLA 2004-07-07 16:33:20 EDT
PR was targeted to the 2.0 release but not resolved, moving target to 2.1
Comment 3 Jason Montojo CLA 2006-09-07 11:38:15 EDT
I'm in the process of adding a new formatting style called "Header" to handle the angle brackets.  From what I can see, the scanner isn't context sensitive (please correct me if I'm wrong) so '#include "foo.h"' would still be formatted as a C string.
Comment 4 Doug Schaefer CLA 2006-09-07 13:17:09 EDT
I think that's true. The whole keyword highlight isn't very smart. That's probably why we haven't done angle brackets since it would be hard to tell that you don't accidentally color expressions with greater than or less than.
Comment 5 Chris Recoskie CLA 2006-09-25 10:22:37 EDT
Created attachment 50820 [details]
proposed patch from Jason Montojo (submitted on his behalf)

Attaching a patch I received from Jason Montojo which I have applied to HEAD.  This is not critical enough for 3.1.1 but I would like to apply this to 3.1.2 as soon as the branch is open for such contributions.  As a result I'm targeting this to 3.1.2 and leaving the bug open.
Comment 6 Jason Montojo CLA 2006-09-25 16:02:11 EDT
Created attachment 50862 [details]
Proposed patch (targeted for cdt_3_1)
Comment 7 Anton Leherbauer CLA 2006-09-29 11:40:40 EDT
I have just committed a rework of the preprocessor highlighting support to HEAD. Your patch is not lost of course, but incorporated into the rework. It is based on a new preprocessor partition so that it can be highlighted more finegrained. e.g. #include "..." is now colored the same as <...>, preprocessor directives have their own color key, instead of abusing the "built-in types" color key, etc. Please try it!
Comment 8 Chris Recoskie CLA 2006-11-30 10:50:37 EST
I'm marking this as FIXED.