Yes
that works. It adds a "project-scope" association. Since that is a
different list than the "workspace-scope" associations, the duplicate removal
code is not triggered.
I
think this just points out that the fact that it is case preserving is really
just an implementation detail. It is obvious from the content type code
that the author intended the content type system to be case-insensitive.
There is no documentation that says that, but the code kind of speaks for
itself. If we can somehow take advantage of this detail to get
case-sensitive matching within CDT in the short term, then I'm all for it.
But I think we really need to sync up with the platform team on this in the long
term.
Jeremiah
PS -
Separately that "use workspace setting" vs "use project settings" in the C/C++
File Types panel doesn't seem to work. Even after I change it back to "use
workspace settings", I still see my added extension in the project-scope
extension list (when stepping through the code). I'll try to remember to
file a PR later.
Yikes! What a
mess!
Jeremiah, try adding
“*.S” using the project -> Properties -> C/C++ File Types. I was
able to add “*.CPP” that way. Maybe it will work for “*.S”, but I don’t
know why…
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah Sent: Friday, July 22, 2005 4:12
PM To: CDT General developers list. Subject: RE: [cdt-dev] Loose end # 2 -
content typeextensionsandcasesensitivity
Works for me for
".C", but not for ".S". Apparently duplicates are eliminated from the
list for a content type using the case-insensitive matching, although I didn't
trace through the code to figure out where or why. So you can map ".c"
and ".C" to different content types, but not ".s" and ".S" to the same content
type. It only preserves the first one so if I change it to "S,s,asm"
then only capital works. If I change it to "s,asm,S", then only
lowercase works.
-----Original
Message----- From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott, Jeremiah Sent: Friday, July 22, 2005 3:41
PM To: CDT General developers list. Subject: RE: [cdt-dev] Loose end # 2 -
content typeextensionsandcasesensitivity
Sorry, I guess my
investigation was incomplete. If this works I would much prefer
this too. Thanks Leo,
-----Original
Message----- From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Treggiari, Leo Sent: Friday, July 22, 2005 3:47
PM To: CDT General developers list. Subject: RE: [cdt-dev] Loose end # 2
- content typeextensionsandcasesensitivity
I just tried a
test on Windows:
1. Created
an MBS C++ project and added a .C file.
2. The MBS
build does not include the .C file.
3. Changed
org.eclipse.cdt.core\plugin.xml, to add uppercase C to the list in
org.eclipse.cdt.core.cxxSource.
4. The MBS
build includes the .C file because the MBS call to
IContentType.getFileSpecs(IContentType.FILE_EXTENSION_SPEC); returns the
file extensions with case preserved.
I suggest that I
don’t change the MBS, and that we DO add .C and .S to the appropriate
content types in cdt.core.
Leo
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Lott,
Jeremiah Sent: Friday,
July 22, 2005 2:55 PM To:
CDT General developers list. Subject: RE: [cdt-dev] Loose end # 2
- content
typeextensionsandcasesensitivity
It's not JDT
behavior, it is core platform behavior. I agree 100%, but you can't
even specify .c and .C as separate extensions. The content type
system automatically converts any extension to lowercase before doing a
compare. All extension methods return lowercase, regardless of what
you specify in plugin.xml or in the UI. I actually modified CDT to
include a content type mapping for ".S", but it made no difference as the
platform converted it to lowercase after reading
it.
-----Original
Message----- From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Recoskie,
Chris Sent: Friday,
July 22, 2005 2:55 PM To: CDT General developers list. Subject: RE: [cdt-dev] Loose end #
2 - content type
extensionsandcasesensitivity
I don’t think
we can follow that per se though as we have to build .c files as C and
.C files as C++
Do we really
know if this is defined Eclipse behaviour or is it just the way that JDT
has implemented it?
If the API spec
doesn’t specify one way or the other then I’d say we’re free to handle
it whichever way we wish, i.e. in a case sensitive
manner.
___________________________________________
Chris
Recoskie
Texas Instruments,
Toronto
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Lott,
Jeremiah Sent: Friday,
July 22, 2005 2:32 PM To: CDT General developers list. Subject: RE: [cdt-dev] Loose end #
2 - content type extensions
andcasesensitivity
My
investigation lead me to believe that Eclipse treats all file extensions
in content types as case insensitive on all platforms (I tried windows
and linux). This was independent of CDT. I tried JDT, adding
extensions like ".JAVA", and also by inspecting the Eclipse content
type code. I would actually prefer they be case-sensitive, but
given this Eclipse behavior, I don't see any choice but to follow the
requirements set by the Eclipse platform and treat them
as case-insensitive.
-----Original
Message----- From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of
Treggiari, Leo Sent: Friday, July 22, 2005 2:35
PM To:
CDT General developers list. Subject: [cdt-dev] Loose end # 2
- content type extensions and
casesensitivity
In bug 103530, there is a
discussion of whether the file extensions specified for an Eclipse
content-type should be treated as case sensitive or case insensitive.
Currently, the MBS treats these as case sensitive on all
platforms. In there is a consensus on what is correct, and it is
different from the current MBS behavior, we could try to change this
for 3.0. What do others think?
Thanks,
Leo
|