Pelles C forum
Pelles C => General discussions => Topic started by: Pelle on September 25, 2004, 12:02:13 PM
-
I have been playing with the add-in interface for a while.
One thing that will be in the 2.90 IDE is the possibility to add new file extensions to the IDE, with an associated syntax color highlighting parser. When a file is loaded with this extension, the associated parser will be used. Attached is the source code of a prototype add-in DLL.
- Is it useful - or too complex?
- Should it be possible to add the new file types to a project? How should the build commands be specified?
- What about dependency scanning ("include files")? (Browse information is probably too complex).
- Other ideas?
- Suggestions?
Pelle
-
- Should it be possible to add the new file types to a project? How should the build commands be specified?
This is actually not related to this, but it would be nice to be able to include "related" files, I mean readme files and other files related to the project, in the project tree... Can you add this?
~ Tommy
-
I have been playing with the add-in interface for a while.
One thing that will be in the 2.90 IDE is the possibility to add new file extensions to the IDE, with an associated syntax color highlighting parser. When a file is loaded with this extension, the associated parser will be used. Attached is the source code of a prototype add-in DLL.
- Is it useful - or too complex?
- Should it be possible to add the new file types to a project? How should the build commands be specified?
- What about dependency scanning ("include files")? (Browse information is probably too complex).
- Other ideas?
- Suggestions?
Pelle
Do you have the vbfile.h file?
I imagine someone will find it useful, not sure what for yet, but new possibilities often arise.
John
-
Is it useful - or too complex?
IMHO a generic parser with config files for each extensions is an easier solution for you and for users to modify
Should it be possible to add the new file types to a project?
maybe under "Other types" folder and opened as text files
How should the build commands be specified?
when a new type is added a dialog should ask for the build command (path/browse to compiler) and then saved in PPJ as EXT_extension=build command (EXT_TXT for text files)
then it will be easier to parse the PPJ for all EXT_ build commands
What about dependency scanning ("include files")?
not available :roll:
I think to leave PoIDE to deal only with files for PellesC compiler and not make and "all around" IDE.
a generic parser would be nice to have for other type of files configured via config files.
-
TBD:
I believe that the fundamental scheme is to construct this as an add-in not as a hardwired object in the IDE.
To quote Pelle
"Attached is the source code of a prototype add-in DLL."
As an add-in you could use it or not use it as you wish.
Robert Wishlaw
-
Sounds good.
Would this be an / (is this the) idea:
If the user elects to use the addin.
The addin inserts a menu option, say,
syntax highlighting, under, eg, the tools menu.
The addin enables, first time, a default pref file preset for common extensions.
Users can add own extensions and keyword/syntax info.
New extensions can be advised to be aliases of an existing extension. Build treats as such.
Users can mod existing keyword info.
Mods are done via sub-options or directly (text editor .. um) to the text file holding preferences.
Included files use their own extension/type syntax scheme.[/list]
-
Maybe providing wrapper functions for tiping apis (difference assembler, difference syntax?) among assembler paser add-ins? And wrapper functions for adding-deleting-refreshing function definitions in the asm source into their own browser info databases (again, difference assembler, difference syntax?) ?
-
Tommy: maybe I can add related files. I need to find a way of adding them to the project file without build commands.
JohnF: the vbfile.h only contains an icon ID, which isn't even used.
TBD: adding a generic parser is way too much work. Asking for build commands for each file seems really clumpsy. It should be possible to have default commands, like today, and then change them if/when needed.
dare2: the basic idea is that the add-in defines one or more extensions it supports (in this sample .frm and .bas). The extensions will be available in "Open..." and "Save As...". The syntax color highlighter will automatically be used when a .frm or .bas file is used. If you want to support other extensions, or some other highlighting syntax, you need to write a new add-in.
The possibility to add new extensions to the IDE is probably not for everyone, so I want to keep things simple. Most of the logic should be in the add-in DLL, not the IDE.
BiMode: this would be useful, but probably too much work. You need to write a new browse information parser. Having worked on POBR, I can say that this is not trivial.
Pelle
-
I have been playing with the add-in interface for a while.
One thing that will be in the 2.90 IDE is the possibility to add new file extensions to the IDE, with an associated syntax color highlighting parser. When a file is loaded with this extension, the associated parser will be used. Attached is the source code of a prototype add-in DLL.
- Is it useful - or too complex?
- Should it be possible to add the new file types to a project? How should the build commands be specified?
- What about dependency scanning ("include files")? (Browse information is probably too complex).
- Other ideas?
- Suggestions?
Pelle
Pelle,
It's like you are looking over my shoulder. I've been using PellesC in combination with BCX, and I often switch between basic and c within your IDE. I added a tool to translate my BCX code into C (then I compile the PellesC project if I don't need to make any changes), but the ability to open highlighted .bas files would be ideal. Very useful.
Thanks,
Eric
-
Hi Pelle:
Thanks for this. I looked at the code and it seams easy enough to understand.
Garvan
-
Hello Garvan,
Thanks. Sounds good. Will add it as a sample in the Add-In SDK for 2.90.
Pelle