This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Hi, because it is now release 8.2 and NB is well designed, stable environment, I want to mention something that is apparently forgotten. The syntax highlighter options dialog for C++ has three subitems: * C * C++ * C/C++ header. I don't understand why it is constructed like this, but this is not important. Important is that setting own syntax profile for each three of them, without ability to copy-paste argument (like color in hex format) makes use of this dialog rather uncomfortable. I don't want my code looks different depending on file type (source/header). There is, in some primitive form, option to inherit parameter. But inherit from where? My proposal is to make it fully inheritable, which means I setup only C++ highlighter, then for entire C and Headers I can check from drop-down menu "Inherit from:" "C++". If somebody wants to use another color for keyword - fine, he may use existing functionality to change "Inherited" to custom font/style/color. But changing it back to "Inherited" means "inherit form C++", not from "All languages". Second thing is extending code parser/highlighter to recognize not only typedefs, but all classes/struct/enums as user types. Just like VisualStudio2015 do. Also eclipe acts like this, making the code look very nice. vector<char*>::iterator looks more friendly :) In fact, I'm using typedefs only to improve code syntax in NB, which is basically wrong technique and should be avoided. Last proposal is to add highlighting enumerators - new category in highlighter. This is also becoming more common in another IDE's. I have more feelings and ideas of what can be improved, as I'm recently forced to work with many different IDE's. One of them is to improve debugger hints in editor, but this is another issue. I'm supporting you from years, but I'm hardware-oriented man, limited in programming skills to C++, so I cannot help you developing the IDE, but I can perform some tests. Regards, Mariusz Midor
Aded 3 new categories: Classes, Enums, Enumerators in enum, branch release82, change set ab5a522d9510
Thanks Alexander, it is always pleasure to see a response to proposal :)
(In reply to mariusz_m from comment #0) > My proposal is to make it fully inheritable, which means I setup only C++ > highlighter, then for entire C and Headers I can check from drop-down menu > "Inherit from:" "C++". If somebody wants to use another color for keyword - > fine, he may use existing functionality to change "Inherited" to custom > font/style/color. But changing it back to "Inherited" means "inherit form > C++", not from "All languages". Hi Mariusz, It is interesting proposal. But Netbeans platform does not allow customize fonts and color dialog. We are thinking about replacing 3 languages to "C/C++". For example Editor->Hints has single language. There is a fair to do it: - how many users use different colors for C, C++ and headers? - which language take for common settings? C or C++? Alexander
I think as long there is no category valid only for one sub-language (like template or template argument) the single C/C++ is good enough. Even if - another IDE's use single category set even if they support c++ - only specific element (like template argument). Just follow the KISS rule ;) Offering too much options sometimes leads peoples to not choose anything at all. I love to see my code well formatted and colorful, but now it requires to made similar changes in four places.
Integrated into 'main-silver', will be available in build *201610310002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/e675c7c2a5f4 User: Alexander Simon <alexvsimon@netbeans.org> Log: fixing Bug #268656 - Syntax highlighter - settings inheritance, new categories - added 3 new categories: Classes, Enums, Enumerators (transplanted from ab5a522d951097673474511a50b69845986ac532)
The "new categories" proposal was extracted to the separated bug #269016.