Re: The top three big problems, Summing up # 1

  • From: "treble" <lauraeaves@xxxxxxxxx>
  • To: <programmingblind@xxxxxxxxxxxxx>
  • Date: Sun, 14 Oct 2007 00:26:45 -0400

Hi Andy -- I was thinking if you have available an internal representation 
of the parsed program, you could navigate top down and say something like

    if ( x ) ...
    else ...

where you could click on the elision (the ...) to expand what is in each 
I think this would be useful to catch bugs in prpogram flow due to 
misplacement or omission of curly braces (in C/C++) for example.

Note that you are writing this for a particular group of C-ish languages 
(C/C++/C#) and that the most general IDE would not include this type of 
thing for all the supported languages as languages will unavoidably differ 
in fundamental ways.  The old fashioned line number stepping with 
highlighted text displayed will always be the most general and cover most 
The problem with incremental compilation is that it really requires a lot of 
work on the various compilers which I think may be more work than the powers 
that be would want to support.  (This may sound inconsistent with my last 
mail where I said it was "not hard to do" -- what i meant was that it has 
been done and is quite doable, but the overhead is high and the 
implementation will depend on the IDE and what it supports already.
As for jumping focus to highlighted text (green declarations for example), 
it would be nice if the IDE would provide something simple -- such as a red 
arrow pointing at the location in question, which the screen reader could be 
configured or scripted to locate and jump to. This wouldn't even need to be 
visible on the screen, but provided in the MSAA or UIA (I'm showing my 
ignorance here of current state of access technology -- does Vista and the 
latest Visual Studio support UIA yet, or do they still use MSAA?)
Anyway, just musing.
Happy hacking.

----- Original Message ----- 
From: "Andreas Stefik" <stefika@xxxxxxxxx>
To: <programmingblind@xxxxxxxxxxxxx>
Sent: Saturday, October 13, 2007 11:09 PM
Subject: Re: The top three big problems, Summing up # 1

le said: Thanks Andy for posing the question.

No problem, this is all extremely fascinating. So, ok, I'm going to
take a shot at summing up the important features, if I'm correctly
processing everyone's thoughts, in order of importance. Here goes
(Critiques welcome!)

1. A way to navigate in such a way that you can quickly jump between
pertinent program constructs. (End of method, end of block, beginning
of block, beginning of method). (Marlon, Will)

The debugger I've created allows you to "navigate" the execution of a
program, backward and forward. It sounds like it would be much more
useful if you could also, with the keyboard, navigate back and forth
between major events too, like "jump back to the beginning of the
method" or " jump to the end of this block. Code that isn't running in
the debugger could probably allow you to navigate in the same way,
making the interface aurally consistent, and navigationally
consistent, for both running and non-running programs, just the
program "speaks" different information. At runtime, it gives you
information about the values of variables, control flow, etc, but
while not at runtime it gives you static information.

2. Construct Preview.

Not sure what to call this idea. What if, while you are debugging or
while your cursor is at some position in the code, you can get a
preview of "what is left" in the rest of the block or the method.
Marlon, and others, suggested things like collapsing methods would be
cool. I'm thinking, perhaps if you can preview what's ahead of the
cursor, and what is behind, that this might simulate "hiding" of code?

For example, would statements like, "There are 10 statements left in
this method?" or something equivalent, be useful at all? (Maybe not)
Any other ideas for how to "hide" code using audio?

3. Optional ways to read the code, depending upon the context.
(Veli-Pekka Tätilä )

It sounds like, sometimes you want the spoken text to include words
that give you the semantics of what is happening in the program, while
other times you want the no frills syntax so you literally know what
to type. What about a suggestion like this:

You have two sets of key combinations. One shortcut will read the
syntax to the left or right of the cursor raw. Another shortcut could
read the semantics of the left or right syntax. For example, maybe
something like:

a * b, the cursor, if it were right before the b, could read either
"multiplication" or "asterisk," while the phrase

*p * b. If the cursor is right before the second asterisk, in the
language C, it could read, "pointer p" or "asterisk p," depending on
what key combination you pressed. This is a cool idea, I think because
it could adapt to whatever programming language you are using, to tell
you not only the syntax, but what the syntax means. What do you think?

4. Easier navigation of errors. (Marlon)

Right now I've got a multiline textbox representing compiler errors,
etc. If you could choose any system for how you access errors from
this box, how would you do it?

Like, should I just include a key combination that navigates you to
the box, then have another combination that reads the next error or
the previous error?

Great conversation, thanks for the feedback everyone. For sighted
person like myself, this type of information is solid gold.

View the list's information and change your settings at

View the list's information and change your settings at 

Other related posts: