@nidza07, I'm saying this because its technically being advertised as one. Its not even really a code editor. If you've used code editors than you already know this -- I should not need to point this out to you.
@Amit, yes, the initial design was to make code folding accessible. If you want code editors or IDEs, use actual code editors, not scripts in BGT. You can just make an NVDA add-on or something like it to detect when code folding is in use. I'm not really sure if very many mainstream programmers use that anyway. If I'm wrong, tell me.
@nidza07, I'm also ranting about this because its pretty much a useless program. That's harsh, yes, but nevertheless its true. That is, its useless written in BGT. BGT was not designed to do what this "editor" is trying to do. Load up a massive source file in it and see if it crashes -- it probably will. Detecting scopes? That's not very difficult (unless your like me: someone who puts tuns of brace-requiring expressions inside each other and then loses track of them). But that's easy to solve -- just look back through the code and count your braces, you'll find which ones match and which ones don't. Indentation? Easily solvable -- use tabs, like I tend to do, or use two spaces per level (like I sometimes also do). And, might I remind the OP that indentation is not just a problem in the blind community like post 1 generalizes it to be? The war of tabs vs. indentation has been raging for years and years, going all the way back to the very first assemblers, all the way back to the very first version of assembly language ever written. Also, the OP indicates that you sometimes find yourself in 6-7 levels deep with indentation; this is an extremely uncommon and rare situation to be in. Why, you might ask? Because most languages have shorthands or other alternatives that, if used correctly, eliminate this possibility. If your 6 plus levels deep in a nest, then there's a high chance you could probably modularize most of that code into a function and thereby make it easier to read. If you're so deep into code that indentation and tracking of levels becomes such an issue that you're pressing the tab key 6-7 times, you've got too much code in that area and need to move it elseware (or find alternatives).
OP also writes:
Another problem in programming is, that when you write a lots of code, you don't see forest because of trees. Browsing it by arrow keys, you are crossing many lines you are not interested in, for example in catching keys from a keyboard, everyone have its code block, but if you are editing them, only block that interest you is thatone you want to edit, not a mass of code for other keys, which hovever are distracting you while navigating through them, because you haven't picture about program's work on higher level, only concrete commands.
Again, this is not just a problem for blind people. Most IDEs (Visual Studio included) have this little feature called regions. This is mainly a compiler-based pragma, so doesn't work with C++ (but does with with C#). You can expand a region that you focus on with ctrl+M, x, collapse a region with ctrl+M, O, and expand everything with ctrl+M, L. These hotkeys are known as a cord.
So, I believe I have covered each problem the OP outlined in post 1 and given sensible and easy solutions. While I myself don't use regions in visual studio, I've seen them in action.
In order for an app to be a code editor, it must have, at minimum:
syntax highlighting (or some form of it)
indentation (smart indentation, auto indentation, etc)
Autocomplete (intelli sense, etc)
Brace matching functionality (brace-ish languages only); equivalent for others.
The ability to run a compiler, debugger, interpreter, or any other such program for the software development process.
If a program doesn't have this then its not a code editor; its just an editor. A fancy editor, but an editor nonetheless.
"On two occasions I have been asked [by members of Parliament!]: 'Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out ?' I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question." — Charles Babbage.