Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

xmas list

(1/2) > >>

grv575:
Not that any of these will be tackled this year, but just some things that would be nice to add / modify:

1.  Allow right-click Watch for arbitrary strings?  Like highlight array, right-click, Watch.  gdb recognizes it so why not?
2.  A memory dialog.  Just have a textbox labelled Address: 0x and let the user type one in.  Then do x/128 0xaddress and paste it into the dialog.  Maybe radio boxes for unsigned, int, long, hexadecimal, etc.  A scrollbar or down array could be used to move up/down by 128 bytes or whatever (maybe 128 can be user-configurable but may not be necessary really)
3.  Once the compiler framework changes, wouldn't it  be cool to have a plugable code completion module - a) so that people can write a plugin code-completion part for an arbitrary language and it should be used...not sure how complicated this would get and b) an AST (abstract syntax tree) representation of the code in memory would be so useful.  You could maybe store allocated array sizes at the array node and then the debugger could give a browseable array (like VC, where you click on the + expand box and it shows the first 10 elements of the array - w/ scrollbar, etc to see more).

That's all I can think of right now.

Michael:

--- Quote from: grv575 on December 19, 2005, 12:06:38 am ---3.  Once the compiler framework changes, wouldn't it  be cool to have a plugable code completion module - a) so that people can write a plugin code-completion part for an arbitrary language and it should be used...not sure how complicated this would get and b) an AST (abstract syntax tree) representation of the code in memory would be so useful.  You could maybe store allocated array sizes at the array node and then the debugger could give a browseable array (like VC, where you click on the + expand box and it shows the first 10 elements of the array - w/ scrollbar, etc to see more).

--- End quote ---

I think that it would be a good idea to have a plugable code completion module :). In this way, if a user would like to integrate a new programming language, e.g., Java, Prolog, she/he can also use (or implement :)) a specific code completion module. May be for such users, it could be of some interest the Mini C++, I have provided in another topic. An expression parser for C++ is implemented, but its basic tokenizer function could be adapted for other languages.

Michael

takeshimiya:
I also like the idea of the codecompletion pluggable arch.

But regarding parsers, I think it's way more easy to use existing parser generators (and grammars+lexers perhaps).

Michael:

--- Quote from: Takeshi Miya on December 19, 2005, 01:15:00 am ---But regarding parsers, I think it's way more easy to use existing parser generators (and grammars+lexers perhaps).

--- End quote ---

I am not an expert in parser generators, but if it would be really easy to use one of them, then I think it would be a good idea. If not it could be an alternative to use an abstract parser and then derive specific parsers (e.g., C++, Java). For what I have read&understood, the most basic and important functionality of an expression parser is the tokenizer function.

Michael

Game_Ender:
I think it would be awesome to be able to implement you own code completion plugin, as well give the other plugins access to the AST through the SDK.  I have been looking at Elsa, it looks to be the best open source C++ parser there is, in fact I am starting a project called Code::Morpher (currently awaiting sourceforge and berlios project approval), a C++ refactoring tool and plugin for Code::Blocks using Elsa.  There have been some issues raised about the protability of Elsa, and I have been talking to the writer of Elsa, and it appears to be a pretty simple job to it compiling under mingw32.  It already works under linux.

Navigation

[0] Message Index

[#] Next page