Code::Blocks Forums

User forums => General (but related to Code::Blocks) => Topic started by: smallB on October 31, 2011, 05:40:25 pm

Title: smallB's suggestions
Post by: smallB on October 31, 2011, 05:40:25 pm
1. Folding is misleading. It leaves left top most bracket. It looks like closing bracket is missing. I think that this style of collapsing would be more obvious:

Having:
Code
for (auto i : c)
{
//body
}

After collapsing body of for
Code
for [...] 
- the part [ ... ] is collapsed body of for
or:
Code
for (auto i : c)
[ ... ]
- collapsed body
Title: Re: smallB's suggestions
Post by: oBFusCATed on October 31, 2011, 08:18:18 pm
This is a scintilla feature ask on their mailing list if this style is supported, if it is we can try to enable it.
But my opinion is that this is pretty ugly (the VStudio style) and I like the current style pretty much, especially the horizontal line...

one suggestion: write all your features requests in a text file and after you've used C::B for a while post the ones you still feel are relevant and useful.
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 10:16:46 am
@Obfuscated, that's ok, I didn't know (still don't) how am I suppose to recognize which is cb feature and which one is scintilla?
Anyway, I already have txt file with features request and I do filter them before I post them here.
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 10:22:57 am
2. Compiler option - make it explicitly visible
Guys, now when I set compiler options like -Wall it is not obvious at all which warnings are enabled. I know that it suppose to mean "all" but there is -Wextra so it looks like -Wall is not all at all ;)
What I'm driving at is that if I i.e. select -Wall, it would be quite a helpful if all those warnings would be listed somewhere (next tab named: "command line", perhaps?).
Also for some green horn like me it is not obvious at all if certain switches are exclusive or not. Example:
Can I use -std=c++0x with -std=c++98? Or only one there may be selected? Again, if so the other one should be disabled.
Also If I select -Wall then I think quite reasonable is that all listed warnings which actually are "within" -Wall should also be ticked automatically + listed on tab named command line.
Thanks.
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 01, 2011, 10:46:03 am
I already have txt file with features request and I do filter them before I post them here.
Increase the threshold, the filter is not working good enough :lol:

-Wall changes enabled warnings every gcc release, so we can't do what you propose.
The checkboxes are for convenience only.
And:
1. you're supposed to know what you're doing.
2. you're supposed to know what every option does, before setting it, so go read the gcc docs before setting them
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 10:56:23 am
@Obfuscated about this un/folding and horizontal line.
I also like the idea with this horizontal line. But I think having extra bracket visible could be (by some people) seen as a confusing/misleading. What your opinion on that?
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 01, 2011, 10:58:51 am
Get used to it:)
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 11:04:26 am
Now, seriously about my suggestions in general. Guys, I really want only help (currently just by giving suggestions which can be ignored if not suitable). I've started giving those suggestions because:
1. I see on this forum "Development
 Anything concerning development of Code::Blocks. Regular users should use the other forums for support/help/suggestions."
2. On the cb starting page I see: "Request new feature"

In view of the above I get the impression that suggestions/requests are welcome.
 
But unfortunately after few comments, notably from obfuscated and neil butterworth I'm getting the impression that they are not.
So level with me, I'm a big boy and I won't get offended - do you mean what you say when you're asking/announcing possibilities of filing suggestions/requests or you don't really need/want them?
Regards
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 11:05:53 am
Get used to it:)
I'd rather improve something which doesn't work as *I* would like than get use to it. It's just the way I am.
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 11:11:30 am
I already have txt file with features request and I do filter them before I post them here.
Increase the threshold, the filter is not working good enough :lol:

-Wall changes enabled warnings every gcc release, so we can't do what you propose.
The checkboxes are for convenience only.
And:
1. you're supposed to know what you're doing.
Yes, but seeing which options are enabled would allow me to SEE what I already did
[quote ]
2. you're supposed to know what every option does, before setting it, so go read the gcc docs before setting them
[/quote]
Agreed but again, seeing certain options would allow me to CHECK what this particular option does an this way educate myself.
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 01, 2011, 12:10:35 pm
PLEASE DON'T SHOUT!

The only way to tell which sub-options are enabled by -Wall is to read the gcc docs for your release of the compiler.
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 12:17:15 pm
@Obfuscated and where did I shout? Mind telling me?
Title: Re: smallB's suggestions
Post by: Jenna on November 01, 2011, 12:35:46 pm
@smallB:
many (or most) of your suggestions just show, that yoiu are neither an experienced programmer, nor an experienced user of C::B.

We (moderators and admins) have to read each and every post due to legal reasons (server in germany).

And reading many of your posts is just a waste of time in my opinion.
This might sound harsh but it is not meant to be offending.
I spent many times in one of your threads (stray \216) and at the end it turns out to be a misconfiguration, because you did not read the manual of the compiler you use.
In the same time I could have spent time with my family or worked on C::B to improve it or do "realworld" work to earn money.

Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 12:44:33 pm
@jens fair enough, won't hear any suggestion from me again. No problem.
Title: Re: smallB's suggestions
Post by: Jenna on November 01, 2011, 01:52:20 pm
@jens fair enough, won't hear any suggestion from me again. No problem.

You like to misunderstand others don't you ?

@smallB:
many (or most) of your suggestions just show, that you are neither an experienced programmer, nor an experienced user of C::B.

That does not mean that suggestions (of you and others) are not welcome.

But as others told you, you should collect your suggestions, work with C::B for a while, read the manual, see whether your suggestions are real improvements, whether it can probably be done in another way, and whether another way is more flexible and therefor better for many developpers.

And be sure, that the issues you find are real C::b issues and not compiler/linker issues.

Than search the forum and the web for related posts, mybe it was discussed already.

And as last step post your suggestions here.
Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 02:03:55 pm
@jens and as for you saying:
"I spent many times in one of your threads (stray \216) and at the end it turns out to be a misconfiguration, because you did not read the manual of the compiler you use."
Few points:
1. I never and nowhere claimed that I'm experienced programmer nor cb user - quite the contrary
2. I thought that this forum is for people (unexperienced users too) having trouble with configuring/using cb - am I wrong? Or is this forum just for experienced cb users and experienced programmers? So they won't ask questions/have problems that will cause waste of your time?
I'm sorry, there have to be some misunderstanding about purpose of this forum. So would you mind clarifying it to me?

When you say on your forum:
a) Help
    Code::Blocks installation/troubleshooting issues. This is NOT a general programming board.

Do you really mean that, and is this forum's purpose to help ANY user (experienced or not)?
b) Using Code::Blocks
 General questions regarding the usage of Code::Blocks (all platforms)

Do you really mean that, and is this forum's purpose to help using cb by ANY user (experienced or not)?
c) Development
 Anything concerning development of Code::Blocks. Regular users should use the other forums for support/help/suggestions.

Do you really mean that, and do you really want to hear from ANY user (experienced or not)suggestions? Do you really mean that help can be asked by ANY user, and that support will be provided to ANY user?

And saying to someone that reading his/her post is a waste of time is VERY offensive. Especially in view of the above I've just listed for you - you do not indicate anywhere that suggestions are not welcome - quite the contrary, you do not indicate that only experienced users are welcome and only they can ask for help, and you do not indicate anywhere that users should restrain themselves from asking for help if they are unexperienced programmers/cb users and if they don't they will just waste your time.
I'm sorry to say/hear that.
Title: Re: smallB's suggestions
Post by: zabzonk on November 01, 2011, 02:25:21 pm
Nobody is saying you cannot ask for help. And in fact you have been given quite a lot of help, by me, among others. And I, and I suspect others, will continue giving help, if you request it.

However, as I said before, anyone can have ideas, and posting ideas alone is not particularly helpful. CB works the way it does because that is the way its developers want or have wanted it to work - if you want it to work significantly differently (and most of your "ideas" were very significant changes) then it is up to you to

(a) make a very good and detailed case for them, which so far you have not - "I would like it to work this way" is not sufficient,

(b) suggest how such changes might be implemented, and how the implementation would avoid problems with other parts of CB

(c)  ideally provide some code.

This is not something specific to CB, it is the way that all FOSS projects operate. You would get the same response if you repeatedly posted ideas alone about how (say) GCC or Apache should be changed.




Title: Re: smallB's suggestions
Post by: smallB on November 01, 2011, 02:40:08 pm
@Neil fair enough, will try to teach myself about patching/plugin etc for cb and contribute to this great project. And Neil, I'm very grateful for your and other's help.
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 08:58:18 am
3. Checking matching brackets when matters only.
I don't think that checking for matching braces in either:
a) comments
b) as a string
c) as a char
is the right thing to do.
Thanks
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 09:04:22 am
4. SmartSense's window is not placed correctly when editing line is close to bottom of the screen.
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 09:36:49 am
5. While debugging something like VS's "show next statement"(yellow arrow on debugging bar) could prove to be very useful.
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 09:46:29 am
6. Debugger doesn't stop on a breakpoint. In project (http://www.mediafire.com/?h34w9ow9ok2wn88) set debug point on line no 15 in main.cpp. This will have no effect. Debugger will exit with code zero. In order to reach this point one have to set another debugging point - i.e. no 12  in main.cpp. This time debugger will skip the first debug point and stop on the second (the wanted one).
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 08, 2011, 10:02:01 am
As stated in the other topic if it works in a command line gdb, but is doesn't in c::b, then it is some bug on our side.
But if it doesn't even work in gdb then we can do nothing, because gdb is the read debugger, c::b is just a wrapper/gui over it.
Title: Re: smallB's suggestions
Post by: ollydbg on November 08, 2011, 10:04:39 am
6. Debugger doesn't stop on a breakpoint. In project (http://www.mediafire.com/?h34w9ow9ok2wn88) set debug point on line no 15 in main.cpp. This will have no effect. Debugger will exit with code zero. In order to reach this point one have to set another debugging point - i.e. no 12  in main.cpp. This time debugger will skip the first debug point and stop on the second (the wanted one).
I just test your project, and I found that it is your fault.
1, you have enabled the "-O2" option.
2, you have enabled the "-s" option.
Remove those options, and rebuild your target, this will let your debugger works quite well. Next time you meet such a problem, I suggest you need to post the "full build log" and the "full debugger log".
Title: Re: smallB's suggestions
Post by: ollydbg on November 08, 2011, 10:06:52 am
5. While debugging something like VS's "show next statement"(yellow arrow on debugging bar) could prove to be very useful.
No idea about your feature request.
Please show us the screen shot, and how it works by step by step mini sample code. Thanks.
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 08, 2011, 10:19:14 am
Haha, I've the same problem myself yesterday, I had -O2 and -s and I wanted to debug, stupid me, lost a bit of precious time.

About feature no 5, I doubt, gdb supports this, smallB if you can tell me the command I can probably do something about it.
But I've never used this feature in VStudio...
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 11:45:01 am
Next time you meet such a problem, I suggest you need to post the "full build log" and the "full debugger log".
Absolutely agree. Will remember next time. Thanks.
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 12:07:28 pm
Haha, I've the same problem myself yesterday, I had -O2 and -s and I wanted to debug, stupid me, lost a bit of precious time.

About feature no 5, I doubt, gdb supports this, smallB if you can tell me the command I can probably do something about it.
But I've never used this feature in VStudio...
I'm not sure about the exact command but it will have something to do with next statement to be executed.
The whole point of having that, is that when you are in debugging process sometimes you want to check something without canceling the whole debug process. So you go let's say to another file and you're checking some definitions, then you go to another/or the same file and checking another things. After you done you would like to continue debugging but you don't remember where was it (which file, which line) the only options at the moment is either find manually the point where you stopped before you decided to check something or press one of: "next line", "go into" or "step out". This isn't always satisfactory because one of those steps may go into fnc which will cause exception and you won't know which line it was so you cannot prepare yourself for that next time. Instead you have to repeat whole debugging process all over, cause exception, remember the exact place and start debugging again.

With what I propose you would just press "show next statement" and you'd be brought back to where you left off.
Thanks.
Title: Re: smallB's suggestions
Post by: ollydbg on November 08, 2011, 12:22:22 pm
After you done you would like to continue debugging but you don't remember where was it (which file, which line) the only options at the moment is either find manually the point where you stopped before you decided to check something or press one of: "next line", "go into" or "step out". This isn't always satisfactory because one of those steps may go into fnc which will cause exception and you won't know which line it was so you cannot prepare yourself for that next time. Instead you have to repeat whole debugging process all over, cause exception, remember the exact place and start debugging again.

With what I propose you would just press "show next statement" and you'd be brought back to where you left off.
Thanks.
Ok, for this feature request, I always double click on the lowest frame in the "call stack" window, then I return to the "next statement" position.  :D
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 12:44:21 pm
@ollydbg, yes, sure that is good workaround but I think (if it's not to hard to implement) it would be nice to have it on a debugging toolbar.

Just a thought.
Regards
Title: Re: smallB's suggestions
Post by: ollydbg on November 08, 2011, 01:00:07 pm
About how to configure the compiler setting.
see:
(http://i683.photobucket.com/albums/vv194/ollydbg_cb/2011-11-08193319.png)
and make sure no "-O2" and "-s" is selected in all the panels.
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 03:05:19 pm
@ollydbg, thank you for your reply. I'm quite sure that I didn't have them selected then (although it does work now as intended (after restarting cb)). The only options I mostly have selected are -Wall, -Wextra, -g, -Wfatal-errors and -std=c++0x;
Once again thanks for your help. Most appreciated.
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 03:08:34 pm
7. Keep/Store breakpoints and watches permanently - unless I decide to remove them.
Guys I think that this is quite reasonable suggestion. It is just very tiring setting all the same watched vars and breakpoints every time I run cb. Disabled breakpoints should also be stored and be available after cb restarts. What'yer thinking?
Title: Re: smallB's suggestions
Post by: MortenMacFly on November 08, 2011, 04:45:25 pm
What'yer thinking?
IMHO is is possible to save/load breakpoints from a file. At least in trunk.
Title: Re: smallB's suggestions
Post by: smallB on November 08, 2011, 05:45:03 pm
What'yer thinking?
IMHO is is possible to save/load breakpoints from a file. At least in trunk.
I'm not really with you. So is the answer yey or ney ;)
Title: Re: smallB's suggestions
Post by: stahta01 on November 08, 2011, 06:13:29 pm
I'm not really with you. So is the answer yey or ney ;)

I think the answer is did you confirm it does NOT work in the nightly.
If it allows saving like he says.

I suggest you submit a patch to add a GUI to make it always do it.

If your suggestions are NOT worth you doing any work; why do you think it is worth the devs doing any work.

Tim S.
Title: Re: smallB's suggestions
Post by: Jenna on November 08, 2011, 07:12:47 pm
What'yer thinking?
IMHO is is possible to save/load breakpoints from a file. At least in trunk.
Are you sure ?

As far as I know, it's possible for watches, but I don't know a way to do so for breakpoints, or do I miss something ?
Title: Re: smallB's suggestions
Post by: MortenMacFly on November 08, 2011, 08:18:58 pm
Are you sure ?
I checked, but you are right. I wanted to commit patch #2775 which implements this and I thought I did, but in favour of the debugger branch I skipped it.

However, this patch could still work on trunk though...
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 08, 2011, 10:07:15 pm
I suggest you submit a patch to add a GUI to make it always do it.
No patches for this or similar features, please.
Unfortunately C::B doesn't have the infrastructure to do it right, until then (I have a plan for it),
breakpoints and watches won't be saved automatically.
It isn't that useful anyways.
Title: Re: smallB's suggestions
Post by: ollydbg on November 09, 2011, 01:40:23 am
Are you sure ?
I checked, but you are right. I wanted to commit patch #2775 which implements this and I thought I did, but in favour of the debugger branch I skipped it.

However, this patch could still work on trunk though...
Yeah, this patch Watches and breakpoints persistent (https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2775&group_id=5358) was create by me years ago, but I use a separate file to save the breakpoints. As we have discussed, the best way was to save the breakpoint in the cbp file.
Title: Re: smallB's suggestions
Post by: ollydbg on November 09, 2011, 02:09:47 am
@ollydbg, yes, sure that is good workaround but I think (if it's not to hard to implement) it would be nice to have it on a debugging toolbar.

Just a thought.
Regards
@OBF:
It looks like run the command "frame 0" will give us the "next line".

BTW: I found a tiny bug in the debugger branch, when I double click on the frame 0 of the call-stack window, I looked at the debugger-log, I see that
1, "frame 0" command was send
2, "bt" command was send

So, I think "bt" command do not need to send, right?
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 09, 2011, 02:58:04 am
As we have discussed, the best way was to save the breakpoint in the cbp file.
This is even worse, than saving in a separate file in the main project directory! Never do that, never ever think about it!

About the "bt" command, I'm not sure, but the reason is that the cursor has changed and the bt command is executed on cursor changed.
Not a big, deal, please don't report problems in other people topics, use the nightly build one.
Title: Re: smallB's suggestions
Post by: killerbot on November 09, 2011, 07:31:31 am
indeed do NOT save breakpoint info in the cbp file !
This file is the project configuration, something you put in version control system. As such a file that shouldn't change because one just had a debug session, and it wants to keep some breakpoints in mind.

We have a similar mistake today, the workspace contains the active project, and therefor changes when another project is active, this is bad for version control.
Title: Re: smallB's suggestions
Post by: smallB on November 09, 2011, 07:55:31 am
I suggest you submit a patch to add a GUI to make it always do it.
No patches for this or similar features, please.
Unfortunately C::B doesn't have the infrastructure to do it right, until then (I have a plan for it),
breakpoints and watches won't be saved automatically.
It isn't that useful anyways.
I have to disagree with you on that one. How many times did you start and finish debugging a project/part of project in one session? It never happened to me so far, and I think I'm not the only one who has had this experience.
Title: Re: smallB's suggestions
Post by: smallB on November 09, 2011, 07:58:40 am
I'm not really with you. So is the answer yey or ney ;)


If your suggestions are NOT worth you doing any work; why do you think it is worth the devs doing any work.

Tim S.
It's not about that Tim. If I'd had necessary skills I'd do it myself - much easier route - no need to ask anyone, no need to convince anyone etc. you're getting the general gist. But in view of the fact that I do not posses them (yet, or maybe never) I'm merely suggesting them and is up to devs to either implement them or not. As simple as that. But believe me, when I eventually will be able to do it myself will never ask anyone, for reasons mentioned above.
Regards
Title: Re: smallB's suggestions
Post by: MortenMacFly on November 09, 2011, 08:14:55 am
As we have discussed, the best way was to save the breakpoint in the cbp file.
This is even worse, than saving in a separate file in the main project directory! Never do that, never ever think about it!
Agreed. The cbp file is definitely the wrong place. However, ollydbg's approach was to save it in a "layout" file - similar to the project layout file.

This sound good:
Unfortunately C::B doesn't have the infrastructure to do it right, until then (I have a plan for it),
breakpoints and watches won't be saved automatically.
So, we are all happy. ;-)
Title: Re: smallB's suggestions
Post by: smallB on November 09, 2011, 08:23:47 am
That's great news!
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 09, 2011, 09:29:02 am
Morten: I know about his patch, but I'm really sick of this files next to the .cbp
Title: Re: smallB's suggestions
Post by: MortenMacFly on November 09, 2011, 09:40:54 am
Morten: I know about his patch, but I'm really sick of this files next to the .cbp
Yes, but the problem is: If you provide projects to third parties and/or have projects under version control, permanent changes to the project file are a nightmare. In addition: private project stuff (like layout options and BP's are) do not belong to a general project file. the general rule is: Put to the project files only what all devs need too compile the project the same/compatible way.
Title: Re: smallB's suggestions
Post by: oBFusCATed on November 09, 2011, 10:10:55 am
Yes, I know, the plan is to have a directory (.codeblocks for example) somewhere in the tree, next to the project or to the workspace.
And then provide some kind of API to the plugin write for managing these files.
The problem is that I've not sure where to save it, next to the project file or next to the workspace file.
In it is not that simple, unfortunately. But we can start a topic, where we can discuss it if you're interested about this problem.
Title: Re: smallB's suggestions
Post by: smallB on November 09, 2011, 01:49:01 pm
8. If I cannot use is it make it inactive
a) Start cb
b) File/new/ File...
c) Pick any type of file
d) Try to check "Add file to active project" - for obvious reasons it doesn't let you check it but I think it would be nicer if it was inactive at all.
Thanks.
Title: Re: smallB's suggestions
Post by: smallB on November 11, 2011, 11:26:03 am
9. Signatures must match

Guys, this suggestion/request is based on the fact that it is not allowed (good thing) in order to successfully compile a program for signatures of class, fnc, variable(static) not to match.
So what I'm saying is, if I have classical .h and cpp structure and I'm changing let's say in cpp:


Code
My_Class::My_Class(int,double,char)
{
/*e.b.*/
}
and for some reason I remove any element from argument list, let's say int (the first one), then it is only logical that this same happens in .h file with this ctor declaration, so from:
Code
My_Class(int,double,char);
will become:
Code
My_Class(double,char);
This should work in both ways - changing .h should be reflected in cpp and vice versa.
Same goes with adding/removing ref, ptr etc etc - they just have to match and this should be automated.
Same goes with templates:
If I have two files in order to simulate classical .h .cpp structure, so I have .h (interface) and *_impl.h (implementation)
and in my implementation file I've got

Code
template<class T>
class X
{
/*Lots of very cool fncs decl. in here*/
};
and in my *_impl.h, I've got

Code
template<class T>
void X<T>::one_of_many_cool_fncs(char*,double)
{
}
when I decide after some time (week, month) that another template param is needed and instead of:
Code
template<class T>
class X
{
};
I want

Code
template<class T,class F>
class X
{
};
then all definitions in *_impl.h should also be appropriately updated, so in my case would give me:


Code
template<class T,class F>
void X<T,F>::one_of_many_cool_fncs(char*,double)
{
}

And again, if after some time I decide that over all it wasn't good decision at all and I decide to remove the second param (class F), again, all definitions should be appropriately updated.
Title: Re: smallB's suggestions
Post by: MortenMacFly on November 12, 2011, 12:10:37 pm
then it is only logical that this same happens in .h file with this ctor declaration, so from:
Code
My_Class(int,double,char);
will become:
Code
My_Class(double,char);
This is absolutely not logical. You can have classes that have multiple interfaces for the same method, like:
Code
void my_method(int i, float f);
void my_method(int i, float f, bool b);
int  my_method(int i, float f, bool b, double d);
Also, you can have optional parameters:
Code
void my_method(int i, float f = 0.0);
void my_method(int i, float f, bool b = false);
int  my_method(int i, float f, bool b = false, double d = 0.0);
So, changing an interface in the CPP file does absolutely not logically mean to change the interface in the H file, too. It might simply mean you are implementing another method / want to use a different method or it may be an user error.
In addition, if you do something automatically, you might create conflicts that you have suddenly two methods with the same interface which is invalid.

Sorry, but the common way to deal with this is:
1.) Design the interface (H file)
2.) Implement the methods (CPP file)
...in case you need re-factoring, you
3.) Re-design the interface
4.) Re-implement what has changed.

Any auto-foo here will bring you in hell, sooner or later, so we won't do it. An exception are the re-factoring possibilities we have. But this is on behalf and under full control of the user and not something automagically.
Title: Re: smallB's suggestions
Post by: smallB on November 12, 2011, 12:23:07 pm
Fair enough (it could be done, but I agree that at the moment it would require too much work), but what about template's params? You cannot have ambiguities there, can you?
Title: Re: smallB's suggestions
Post by: Alpha on November 12, 2011, 03:19:32 pm
3. Checking matching brackets when matters only.
I don't think that checking for matching braces in either:
a) comments
b) as a string
c) as a char
is the right thing to do.
Personally, I like it that all the braces can be matched.  I can see, however, why this might be annoying (if I get the chance, I will create a patch with an option to enable/disable this).

Morten: I know about his patch, but I'm really sick of this files next to the .cbp
What about having only a single file - like FileName.state or FileName.activestate - that contains all the information about the user preferences of the current project/workspace.  Another option would be to have a hidden folder, for example .ProjectState, which allows all the various files that are currently written to be organized into a single spot.

An exception are the re-factoring possibilities we have. But this is on behalf and under full control of the user and not something automagically.
I have not looked very much into Code::Blocks' refactoring abilities; is it currently possible to refactor function/constructor/etc. arguments?
Title: Re: smallB's suggestions
Post by: MortenMacFly on November 12, 2011, 04:07:21 pm
You cannot have ambiguities there, can you?
Sure you can, why not? It can be seen as an abstraction of a class! In addition it gets more complex, as you need to really do a good and complete parsing before.
Title: Re: smallB's suggestions
Post by: MortenMacFly on November 12, 2011, 04:11:03 pm
I have not looked very much into Code::Blocks' refactoring abilities; is it currently possible to refactor function/constructor/etc. arguments?
I don't know. We have some capabilities but I'll never use. I never trust any automisation when it comes to that kind of stuff... no matter what IDE. In the end you usually don't need it if you put software design before implementation.
Title: Re: smallB's suggestions
Post by: smallB on November 12, 2011, 06:55:59 pm
You cannot have ambiguities there, can you?
Sure you can, why not? It can be seen as an abstraction of a class! In addition it gets more complex, as you need to really do a good and complete parsing before.
I somewhat cannot see how can you run into ambiguities here. Small code example would surely help ;)
Title: Re: smallB's suggestions
Post by: ollydbg on November 13, 2011, 03:36:25 am
The code-refactoring feature in the currently CC is not good, I don't believe it will be good. Unless we have a compiler level parser.
Title: Re: smallB's suggestions
Post by: smallB on November 13, 2011, 11:57:43 am
@ollydbg, thanks
Title: Re: smallB's suggestions
Post by: ollydbg on November 25, 2011, 03:25:10 pm
@ollydbg, yes, sure that is good workaround but I think (if it's not to hard to implement) it would be nice to have it on a debugging toolbar.

Just a thought.
Regards
@OBF:
It looks like run the command "frame 0" will give us the "next line".

BTW: I found a tiny bug in the debugger branch, when I double click on the frame 0 of the call-stack window, I looked at the debugger-log, I see that
1, "frame 0" command was send
2, "bt" command was send

So, I think "bt" command do not need to send, right?
Are there any good way to navigate to the "next line" when debugging.
I just read the gdb manual, and I can't find a better than "frame 0" command.
Any ideas?

Once I thought we can save the position when we place the "next line" mark in the scintilla control, so the user click the "show the next line" tool button, we can quickly return to the saved line. But later I found that when we switch the frame will change the triangle mark position too. So it doesn't work this way.