codelite roadmap

[eranif]

Hi All,

As part of the planing for the next release of codelite (minor release), I am putting here the list of items (beside the bugs) that I am planing on implementing for the next release:

- add build-errors-assistant - parse compiler output and suggest include files in case the error is due to missing include files
- Debugger: add option to copy value from the display variable tree
- Debugger: add option to copy backtrace to clipboard
- Debugger: add option to 'add watch' from the display variable tree
- New Class Wizard: Implement only direct parent virtual methods
- New Class Wizard: Applied various pending patches
- Code Completion: Add 'Include Files' per workspace level

This is the list I had in mind, please feel free to comment

Eran

[jfouche]

As part of the planing for the next release of codelite (minor release), I am putting here the list of items (beside the bugs) that I am planing on implementing for the next release:

Well, time to try the TRAC roadmap
BTW, I had a look to how import actual bug tracker into TRAC : it's not possible actually . May be you can change the link to bug reports on CodeLite web site to go on TRAC, wait for me to add the actuals bug / requests to TRAC, and remove the actual bug tracking from sourceforge (if possible...)

- add build-errors-assistant - parse compiler output and suggest include files in case the error is due to missing include files

It means that we need to add a way to told the error parser what kind of regex pattern is an include error (it can't be hard coded because my gcc produces French warning / errors).

[eranif]

It means that we need to add a way to told the error parser what kind of regex pattern is an include error (it can't be hard coded because my gcc produces French warning / errors).

Not really.

I was thinking of adding somekind of popup dialog which will ask you after a build has ended (with errors) whether you like codelite to try and fix some of the errors for him. If the user accepts it, codelite will then iterate over the error messages and will try to parse them for recognized patterns.

I was thinking of making it independent of the build system settings.

BTW: Another plugin which I am planing to add (which I am kinda need personally for my daily job) is a 'scp plugin' (scp=secure copy) which allows user to edit file and save them using the scp tool (pscp for windows) - this will make my life a lot easier whenever I need to edit files on a remote machine (AIX, i5) with poor editing tools and no UI access...

Eran

[marfi]

Some suggestions dealing with include files:

1) It would be nice if proposed include files would contain also "full path". For example if you ask CL to add include file for wxClipboard class then you get #include <clipbrd.h> instead of #include <wx/clipbrd.h>, for wxXmlDocument you get #include <xml.h> instead of #include <wx/xml/xml.h> etc.

2) The new "New class wizard" should allow user to specify also include file(s) for base class(es) (or it could propose them).

[eranif]

1) It would be nice if proposed include files would contain also "full path". For example if you ask CL to add include file for wxClipboard class then you get #include <clipbrd.h> instead of #include <wx/clipbrd.h>, for wxXmlDocument you get #include <xml.h> instead of #include <wx/xml/xml.h> etc.

have you tried to modify the name of the include in the text control (the upper one) - if you will add wx/xml/ at the first time -> codelite will "do the math" and will offer all the include files (after this one) with the wx/ prefixed.

2) The new "New class wizard" should allow user to specify also include file(s) for base class(es) (or it could propose them).

Agreed

Eran

[marfi]

have you tried to modify the name of the include in the text control (the upper one) - if you will add wx/xml/ at the first time -> codelite will "do the math" and will offer all the include files (after this one) with the wx/ prefixed.

Yes, I've tried it, but it doesn't work flawlessly. After prepending of "wx/" to proposed include, the next includes (tested on wxFrame, wxFileDialog, wxTextCtrl) have prefix "wx/gtk/" instead of simple "wx/" which is obviously problem if I want to get a portable source code (I use Ubuntu). Moreover, some classes (for example wxClipboard, wxDropTarget, ...) are not recognized by code completition out-of-the-box unless I add their includes manually (for example "wx/dnd.h") so in this case the "Add Include File for ... " function doesn't work at all.

Michal

[eranif]

Code Completion: Add 'Include Files' per workspace level

This part is now completed and committed in SVN trunk.
Users can set search / exclude paths in addition to the globals paths this is done by right clicking on the workspace icon in the 'Workspace' tab and select 'Workspace Settings...'
The file explorer context menu was also adjusted to support this feature.

You can read more about it here:
http://codelite.org/LiteEditor/SettingUpCodeCompletion

Eran

[kspes]

I'm curious, what is your policy on supporting other programming languages?
IMO, CodeLite should stick strictly to C/C++, other IDE's have tried supporting other languages, trying to be universal but because of it, neither language support was really any good; Code::Blocks, KDevelop, Eclipse are a good example. They are good IDE's but really mediocre in comparison with Visual C++ and of course CodeLite.

[eranif]

I too think that codelite should stick with what it does best: C/C++.

I dont mind adding patches / fixes to allow more customization (like I did with hops & cobra).

Creating an IDE for C/C++ was my intentation from day one, this is why some of the basic functionalities in codelite are NOT plugins, like:
- Code Completion
- Debugger
- Build systems

All other tools are plugins.

So even if you strip codelite from all its plugins, it will still be an excellent tool for C++

Eran

[garfield]

Registered here just to say WOW:) CodeLite is way, way, waaaay above may expectations! And I have tested basically all c++ IDEs.

Anyway, I will not hijack the topic with superlatives, critic or comparisons...but still I want to share my wishes with any C++ IDE, CL included.

1. Fast and powerful debugging... across the board. I really do not know whats the problem with ALL gdb based IDE but debugging is faaar from robust... It almost make me question gdb itself, hope Im not right.
And "across the board" I mean every modern feature in every situation - not just working for a screencast of hello world app!
Main tricky situations are:
- debugging dll from an app (good luck writing a custom config file just to set a breakpont).
- working tooltips! Really! If I cannot select an expression, hover over it, and see the value, Im better of writing just a cout or whatever and forget about it. (I dont need Watches *that* much if I have working tooltips at any time... I really cant remember using Watches at all "back in the VS days" - only tooltips )
- if an option to print the values in readable form exists utilizing it is a must for me. Simply because all modern apps are written on a framework, not plain c/c++...hell even stl and standard string are "framworks", not to mention Qt and wxWidgets. Such a feature worth thousand times any stupid plug-ing "that makes typing easier".

2. VS import. This also is a must..and the only reason for me of using Code::Blocks so far.
As we all know most if not every project with Windows origin uses VS as build environment. This is unfortunate but well deserved - c/c++ has no strong, robust , powerfull, free and cross-platform environment so far... The moment I start using CodeLight - it will be with imported VS project (have not tested it yet).

3. Code completion and hinting that actually *works* (again acroooss the board, not for screencast). And by "works" I dont mean just the technical staff, but also the UI. It must NOT stand in the way. And it must be SMART in every moment. It must understand Im pointing at a function parameter, not the function, an the reverse - Im willing to pop up the function overload list (again), not to complete the param...ect. etc.... Again tooltips are here also a key!
C++ code can, and most of the time is messy (especially using a framework) we... I use IDE *mainly* to aid code navigation and understanding and if the tool can dig to hell to find me the implementation of the function this is worth all the code beautifiers in the world and all the cpu cycles! I just happen to spend most of the time digging someones else's project... code navigation is critical for me. (a small letdown was CL failing to find anything hidden behind a simple macro)

In general do-the-things-you-do-right is critical to me. If I expect something to work it - it must work, I will sacrifice "features" just for rock solid basics! (For instance if I include a path to the include list of the compiler it *must* also be included in the Code completion path - this is "a basic thing working"... regardless of complex it is to implement or how may cycles it costs)
The problem is - all gcc based IDEs fail to glue the things together...they provide a text editor (of some power) , a (low level) interface to the tools and (partly) working code hints. Thats it. Every time.(Ok, eclipse code hints rock, though slow)
This is in *sharp* contrast to say Java, C# or ActionScript or some other language's IDEs.... I dont know... May be IF CodeLight sets in stone to work only with gcc (much like VS with the ms compiler), may be than we can hope of some really robust environment "that sings together". I dont know...

There some interface issues I will not complain about for now, as I said robustness is much more important for me...the UI can aways be modified.

I wish you *best of luck*, hope CL will succeed, for me and for every c++ developer, of becoming de-facto standard for c++ development.
I hope I don't sound too excited
Anyway, thanks!
MihailNaydenov