| T O P I C R E V I E W |
| Adequat |
Posted - Aug 19 2007 : 04:42:05 AM
1) I would like an option to specify the color of the highlighted brace's background. This makes a far better visual feedback for this often changing "micro-focus". This is the case eg. in the text editor named "EditPad Pro".
2) I would prefer to have the highlighting occur even if the cursor is just before the opening brace, or just after the closing brace. Again, like in the editor mentionned before. This is just more intuitive in my experience.
Thanks
|
| 9 L A T E S T R E P L I E S (Newest First) |
| Adequat |
Posted - Aug 29 2007 : 11:51:30 AM
It's not my intention to insist on the subject. I just emit the suggestion, when you've got 5 minutes, to try the text editor I have mentionned in my first message, with a .cpp file. Then you can see **in practise** that the option I have talked about, feels right, even in the "difficult" cases you have mentionned. |
| feline |
Posted - Aug 28 2007 : 08:36:19 AM
Adequat when to add an option is a discussion that comes up every now and then. The simplest answer is that if we added an option every time someone suggested doing so we would have a couple of thousands options by now, with the number still going up. There are some programs out there with that many options, and it is not really helpful, it is just to confusing, to many things to fiddle with.
The second point here is that VA is not a "normal" program. So adding an option is not a simple case of putting a single check in a single place, it often means adding many checks, all over the place, and the checks may have to work differently in each IDE. For these reasons we try to keep the number of options to a minimum. |
| sl@sh |
Posted - Aug 28 2007 : 03:28:05 AM
This might be as you say, but I still prefer any program working 'as it should' out of the box, at least in cases that I know I'm not doing anything exotic.
What VA does - and I really like this approach - is provide options that many users can make good use of, but at the same time make any option behave in such a way by default that makes it unnoticable for those who don't need it. (hmmm, there's bound to be grammar problems here, but that early in the morning I'm too lazy to check  )
I like the background color suggestion, but I consider the positioning request confusing. Even if VA introduces this as an option that is off by default, the question remains what it should do in cases of multiple brackets - and then the user will have to understand VA's behaviour. Even more dubious would be the case of the cursor positioned between a closing and opening bracket! Like this: )|( I cannot think of a reasonable way to resolve that!
Methinks the current behaviour is easy to grasp and unambiguous. Plus I see no real merit in having it behave otherwise. |
| Adequat |
Posted - Aug 28 2007 : 03:01:00 AM
>>We try to keep options to the minimum, and prefer
>> to have VA "just work" for as many people as possible.
While I agree this is a good approach for many applications, VA is an application for programmers, that is, a population that likes and is ready, by definition, to "program" things (to suit their needs in this case). |
| feline |
Posted - Aug 22 2007 : 09:29:33 AM
Personally I tend towards the same approach as you sl@sh, but I also have seen all sorts of code.
Sometimes it is hard to avoid, a multi-conditioned if statement is a good example. I end up splitting those across several lines to try and keep an eye on what goes with what, but on a few occasions I ended up with a 10 or 12 line "if", since it had that many conditions you had to consider *sigh*
It was the following "else if" statement that was also 10 lines tall that really irritated me though.
There were quite a lot of brackets in that, as you can imagine. |
| sl@sh |
Posted - Aug 22 2007 : 04:12:04 AM
I'd wager whether or not code features excessive (IMO) use of bracket-encapsulation is a matter of style.
Personally, I'll try to split up any expression into the most simple parts that don't cause unneccessary overhead elsewhere (following the KISS! principle (Keep It Simple, Silly!). IME bugs occur at the least suspecting parts of the code, and being able to debug and check each step of a calculation helps a lot!
OTOH I tend to use '{}' to group code just about anywhere, even if there's only one line (to make a point that some time there might be a block of code instead of just a line), so my use for the matched bracket highlighting is fokussed on these kinds of brackets.
But, like I said, it's a matter of style. I've seen both extremes (i.e. people like me, using '{}' even if it was obvious there never would be more than a single line of code in that block, and people using multiple nested layers of function calls resulting in complete algorithms within a single line of code). Better brace yourself against either use |
| feline |
Posted - Aug 20 2007 : 3:53:14 PM
The case is for our internal bug tracking system, this FAQ explains about it:
http://docs.wholetomato.com?W318
Brackets next to brackets, what about calling functions with the return of another function? If statements involving functions? On reflection the example I produced was a little exotic, but in my personal experience brackets next to brackets is quite common.
We try to keep options to the minimum, and prefer to have VA "just work" for as many people as possible. |
| Adequat |
Posted - Aug 20 2007 : 11:52:36 AM
Yes, but the case you describe is rare (at least in my code). A global option would be welcome, to choose either mode.
BTW, where can I find item #8301 ? (I am not aware of a web area about suggestions other than here).
|
| feline |
Posted - Aug 20 2007 : 08:14:26 AM
I have put in a feature request for changing the background colour for matching brackets:
case=8301
to see what people make of the idea.
For the caret position, what happens when you have code like:
functionCallWithCasts((char *)foo1, (void *)foo2, ((int)foo3));
it is at times like this that highlighting matching brackets suddenly becomes rather important, and you want to know which pair of brackets the caret is actually inside. |
|
|
