search

abusalimov / SublimeCImproved

(NO LONGER MAINTAINED) Improved syntax for C/C++/Objective-C, with a special support for sources of Linux kernel, CPython, etc.
https://packagecontrol.io/packages/C%20Improved
MIT License
51 stars 45 forks source link

Recommend Better Support for Custom types #40

Open cujomalainey opened 8 years ago

cujomalainey commented 8 years ago

Currently custom types are not being highlighted the same as standard types, recommend indexing custom types and highlighting them like regular types.

abusalimov commented 8 years ago

Thanks for reporting this. Do you mean highlighting usages of user-defined typedefs and structs? They are left as is just to be able to distinguish them from the standard types. And even if one decided to highlight them as well, this would be hardly possible to accomplish using just regular expressions. These type are indexed though, you should be able to "go to definition" using F12 in Sublime Text. Am I missing something?

cujomalainey commented 8 years ago

Hmm, maybe something is weird with my build, no one I know has been able to get F12 to work in C, we all had to use the CTags package to get that working and yes indexing works.

Just wondering if maybe a setting could be added to color the user-defined types and structs the same as the standard types. In complex projects where the majority of types are user-defined it makes it significantly harder to read the code not having the types highlighted.

abusalimov commented 8 years ago

Hmm, maybe something is weird with my build, no one I know has been able to get F12 to work in C

Well, I've just double-checked to be sure that it works on my C projects, and it actually works. Are you talking about plain C project or C++ one? I suspect something could become broken in recent ST3 dev builds... (What is your ST version BTW?)

If it's plain C, could you ensure that C improved is the default syntax for both .c and .h files? You can check that just by opening a previously closed file - the syntax (bottom right corner) must be detected as C Improved, not just C or C++.

Just wondering if maybe a setting could be added to color the user-defined types and structs the same as the standard types. In complex projects where the majority of types are user-defined it makes it significantly harder to read the code not having the types highlighted.

As I said there's not so much I can do here... A source code is parsed using regexes, and there's even no way tell whether a given identifier refers to a type or it's just a variable name (too many corner cases). This would require either a full-featured context free parser (and even in that case it won't be able to distinguish a simple multiplication like t * v from a declaration of a pointer to type t called v), or using a plugin that looks up the index for each identifier found in an open file to check whether it refers to a custom type. Both options are (near to) impossible at the moment: ST only supports tmLanguage/sublime-syntax grammars that are regex-based, and there's no proper API to query index for the actual type of a symbol in question (one could make it work for types defined inside currently open files, see #16).

The only reasonable option is to add an ability to highlight a list of predefined types, i.e. matching some regex like prj[A-Za-z0-9_]_t. Or, if we're talking about C, just highlight everything that follows struct/union/enum keywords. What do you think?

cujomalainey commented 8 years ago

Build 3103

No my system defaults to C++, always has for .c and .h files, reinstalled C Improved and local indexing started working again (ie, i was able to use F12 for definitions in the same file)

That makes sense, I will look into some of the defines we have and see if it can work.

abusalimov commented 8 years ago

You could set "Open all with current extension as..." C Improved at least for .c files, and maybe for .h as well, unless you use them for C++ code (I mean classes, etc.).

I was able to reproduce your "go to definition" issue for .hpp file, thank you. I guess the reason is the new syntax format introduced in ST3 dev, see #41.