In fact, I will wait, hoping it will available in september after my vacations. I looks very promising. So, Rico, thank you in advance, another great program for us !
ome of the things VS has in it's favour is that it is designed to be used for one purpose, CodeBench is designed to be as general as possible to accommodate any language. While certain language specific stuff can be implemented by the plugins, the complxity is limited by the fact that it is just a plugin, and cannot replace all IDE functionality.
Things like variable definition tracking etc are beyond the scope of this application, and are the job of the preprocessor. In order to implement what you mention would mean practically writing my own preprocessor. Sadly, that is not going to happen.
Right. Well, I guess you could say that VS also uses a plugin system of sorts; it has support for multiple languages (BASIC, C#, C++, J# and I believe more). And I would expect the plugin to be the place for language-aware stuff, whether you'd call it a preprocessor or a parser, anything that can go far enough to keep track of the syntax tree of a whole project, which is more or less what would be needed for such features.
And I do understand that this is not just something you add with a swift movement of your left hand . But maybe you can give a few thoughts to a way to add it later? A plan for how the interface would work for a language plugin to be able to deliver such services to the general IDE?
Do you know if VS uses a separate compiler/preprocessor to create the finished executable, or is it all handled by VS itself?
If the later is the case, then VS already has the preprocessor built-in (possibly in the language specific plugin), so tracking variable usage and other such luxuries are already in the system. For me, I would have to duplicate the work of the preprocessor, and that is not something I am thinking about doing in the next 10 years, sorry.
Are you planning any kind of system for "auto complete" when writing code (variables, functions, struct-members, object-members and so on)? (Crossing fingers as this is what I really miss when developing on the Amiga...)
Do you know if VS uses a separate compiler/preprocessor to create the finished executable, or is it all handled by VS itself?
Well, I'm not exactly sure how it all works internally, but from the user's standpoint, it's all handled within VS.
When you install VS, you select which languages you want to install support for, and I believe the support "chunk" for each language is pretty extensive (like so much in that world), so it probably contains lots of stuff that performs some of the magic seen in the IDE. But there is also a command-line version of the compiler, at least for C# (which is the language I use). I would guess that much of the language-specific code resides in DLLs which can be used from both the command line compiler and the IDE. There's also such things as language-aware (user-definable) code formatting, but again, this could be a service in a language-specific DLL called generically from the IDE application.
Yes, even GoldED has some sort of auto completion but it only takes the first 'hit' and prints it out, no selection at all if the starting characters could be multiple values.
Things like autocomplete should be an easy task to implement once I have all the lexicons sorted out. These will be needed to support the highlighting, so they will serve a dual purpose.
Whether that makes it into the intial release is something else entirely.
Again, if that is the case, which it most likely is, then that's how it implements the resource tracking. The preprocessor (and probably the compiler too) is already part of VS. This is not the case with CodeBench (for the C/C++ plugin, cc1 is separate), and as such, is a duplication of work, which I'm not prepared to spend time on.
This is why CodeBench is promoted as a Project Management System, rather than a full blown code generator.
In any case, I have to leave something to the programmer, otherwise there'd be nothing to think about :)
Actually many IDE's use external compilers. And still do stuff like that. Just make a public API for the plugin/module system in one of the future versions and people can write this fancy stuff on their own without you having to do everything.
For example, the plugin/module system could allow someone to write their own editor component. The application provides a way to add the GUI elements to itself as well as functions for retrieving linker settings and the source tree. And voila, all the sudden it's possible to create a custom editor that keeps track of methods, erroneous code etc.
A popular method among java IDE developers is to enable external developers to register modules/plugins in a central repository and then present plugins via an IDE built in installer/uninstaller that downloads from the central repository. It's a perfect way to provide added value to a product without the application author having to do all the work.
Btw, to get performance out of such stuff it's probably not a good idea to parse the whole file over and over again, but rather build a document tree when first loading the file and keep track of what the user is doing in the current scope/segment separating each part as it's own object defining what type it is etc. That way the parser can focus on what is actually changing rather than the whole file.
Anyway, I'm sure the application will be just fine as is and that developers will use it. The above is just theoretical path for future development of your product.
You understood that Rigo "only" developped an IDE, not a new language, don't you ? If so a basic plugin is not feasible as there is no such thing as a "basic" language. If under OS4 we were having access to AmiBlitz you could have asked for an AmiBlitz plugin, if we were having access to Mattathias Basic you could have asked for a plugin for it, but a "basic" plugin does not mean anything.
Or maybe I completely misundertood what you were saying and you were only asking when Rigo will have a simple (=basic) working plugin available and ready to ship ?
Well, as C/C++ is by far the most popular, and best supported, language, that will be the one that will be focused on first. The PHP/HTML plugin will be close behind for commercial purchasers.