Allow NVDA to report indentation as tones

[derekriemer]

I propose adding functionality to NVDA to add the ability to report indents as tones.
My design ideas are based off of my indentone add-on at
https://github.com/derekriemer/nvda-indentone
Make NVDA report indents as tones when the user selects this option. This option might be in document formatting. We'd need to enable several new items if report indents is enabled that controls report indents .

• Report indents with speech check box.
• Report indents with increasing pitch checkbox.
• Use stereo to indicate indent level.
• (one of these proposals): Indent space behavior combo box with:
  • one quarter tone pitch increase per space.
  • One whole tone pitch increase for each n spaces.
  • If the later one there is selected, we need an edit control to specify what N is. We need to figure out better language to specify here.
• or: just an edit control asking how many spaces equals one tab. Then, one tab is one whole tone, and any sub part gets subdivided.

The code design of my current add-on monkeyPatches speech.getIndentationSpeech to do this. I'd probably put most of this code there, and maybe put a tones.reportIndentation item in tones.py so that I don't bloat the speech.getIndentationSpeech function with unnecessary math and stuff. We could just use beep inside tones in that case. As for getting config values, is it fine performance wise to just use config.conf["documentFormatting"]["reportIndentsAsStereo"] for this or is that too slow?

[derekriemer]

Hi,
Just curious, is this something I should investigate more?

[jcsteh]

I propose adding functionality to NVDA to add the ability to report indents as tones.

Sounds good.

Make NVDA report indents as tones when the user selects this option. This option might be in document formatting.

Makes sense.

We'd need to enable several new items if report indents is enabled that controls report indents .

• Report indents with speech check box.
• Report indents with increasing pitch checkbox.
• Use stereo to indicate indent level.

Is both pitch and stereo useful here? Is stereo actually accurate enough in terms of a user's ability to detect a small, discrete change? What do you do if stereo is enabled but pitch isn't?

• (one of these proposals): Indent space behavior combo box with:
  • one quarter tone pitch increase per space.
  • One whole tone pitch increase for each n spaces.
  • If the later one there is selected, we need an edit control to specify what N is. We need to figure out better language to specify here.
• or: just an edit control asking how many spaces equals one tab. Then, one tab is one whole tone, and any sub part gets subdivided.

I'm concerned about complexity and confusion here. Too many options = can't be bothered, too hard.

• It'd be good if we could come up with a one size fits all approach. So, perhaps we just map tab to a tone and then either 2 or 4 spaces to a tone. Yes, this means that different types of indentation will have different deltas per level, but I think it'd be fairly natural to adapt per file; it's rare that people intentionally skip a level, so misinterpretation should be minimal.
• If you/others are really concerned about the different number of spaces issue, I'd go with your final option: tab per tone and configurable spaces per tab.

The code design of my current add-on monkeyPatches speech.getIndentationSpeech to do this. I'd probably put most of this code there,

It's not really ideal for getIndentationSpeech to actually produce output; it's supposed to just return output. In theory, it could be called but the result might not be spoken... or it might be called multiple times with only one result spoken. That said, the current speech system doesn't give you any other option, so this will have to do for now. Still, we should note somewhere that this should be fixed once speech refactor happens.

and maybe put a tones.reportIndentation item in tones.py so that I don't bloat the speech.getIndentationSpeech function with unnecessary math and stuff.

Understand not wanting to bloat, but I'm guessing it should only be a couple of lines of code. It doesn't make sense to me to have tones.reportIndentation or the like, since it'll only ever get used by this code. If you like, you could split it out into a private helper function in speech.

As for getting config values, is it fine performance wise to just use config.conf["documentFormatting"]["reportIndentsAsStereo"] for this or is that too slow?

That's fine, though if you're going to fetch, say, more than 3 values from the same section, it's probably worth grabbing the section as a local variable.

[derekriemer]

  * Use stereo to indicate indent level.

Is both pitch and stereo useful here? Is stereo actually accurate enough in terms of a user's ability to detect a small, discrete change? What do you do if stereo is enabled but pitch isn't?
Well, I'm experiencing this now as I do indentone's GUI for the add-on.
Nothing. It's such a small change you can't tell. There are two options.

1. The number of indents I can report max needs to be lowered for stereo
   without pitch. This is rather annoying for the user who turns off pitch
   only to realize they get half the indents (although it's still like 12
   levels).
2. If pitch is disabled, stereo must be disabled, i.e. pitch controls
   wether it's mono or stereo, disabling pitch shouldn't be an option.
3. We just don't do stereo, it only gets to be mono (if you are working
   from one ear piece, stereo isn't good because you might miss indents).

  * (one of these proposals): Indent space behavior combo box with:

      o one quarter tone pitch increase per space.

This no longer makes sense. It's to complicated for users.
o One whole tone pitch increase for each n spaces.
see above.
I'm concerned about complexity and confusion here. Too many options =
can't be bothered, too hard.

• It'd be good if we could come up with a one size fits all
  approach. So, perhaps we just map tab to a tone and then either 2
  or 4 spaces to a tone. Yes, this means that different types of
  indentation will have different deltas per level, but I think it'd
  be fairly natural to adapt per file; it's rare that people
  intentionally skip a level, so misinterpretation should be minimal.
• If you/others are really concerned about the different number of
  spaces issue, I'd go with your final option: tab per tone and
  configurable spaces per tab.

I would agree that the quarter tone thing is too confusing. Lets either
do 2 spaces per level (half tone?) 1 tab = whole tone, 2 spaces = half tone, four spaces = tone. Or, edit field to pick.
Just a single edit field with "how many spaces is one indent level"

It's not really ideal for getIndentationSpeech to actually produce
output; it's supposed to just return output. In theory, it could be
called but the result might not be spoken... or it might be called
multiple times with only one result spoken. That said, the current
speech system doesn't give you any other option, so this will have to
do for now. Still, we should note somewhere that this should be fixed
once speech refactor happens.

We might be able to add a reportIndentations that takes in a number of
chars and produces a beep as a side effect. This would be added after
the call if the option is on.

Understand not wanting to bloat, but I'm guessing it should only be a
couple of lines of code. It doesn't make sense to me to have
tones.reportIndentation or the like, since it'll only ever get used by
this code. If you like, you could split it out into a private helper
function in speech.

See above.
Makes sense.

[derekriemer]

Edit:

tab/four spaces = whole tone, two spaces is half that, a semi/half
tone. This way the user hears half the indent.

On 6/8/2016 5:11 PM, James Teh wrote:

I propose adding functionality to NVDA to add the ability to
report indents as tones.

Sounds good.

Make NVDA report indents as tones when the user selects this
option. This option might be in document formatting.

Makes sense.

We'd need to enable several new items if report indents is enabled
that controls report indents .

  * Report indents with speech check box.
  * Report indents with increasing pitch checkbox.
  * Use stereo to indicate indent level.

Is both pitch and stereo useful here? Is stereo actually accurate
enough in terms of a user's ability to detect a small, discrete
change? What do you do if stereo is enabled but pitch isn't?

  * (one of these proposals): Indent space behavior combo box with:
      o one quarter tone pitch increase per space.
      o One whole tone pitch increase for each n spaces.
      o If the later one there is selected, we need an edit
        control to specify what N is. We need to figure out better
        language to specify here.
  * or: just an edit control asking how many spaces equals one
    tab. Then, one tab is one whole tone, and any sub part gets
    subdivided.

I'm concerned about complexity and confusion here. Too many options =
can't be bothered, too hard.

• It'd be good if we could come up with a one size fits all
  approach. So, perhaps we just map tab to a tone and then either 2
  or 4 spaces to a tone. Yes, this means that different types of
  indentation will have different deltas per level, but I think it'd
  be fairly natural to adapt per file; it's rare that people
  intentionally skip a level, so misinterpretation should be minimal.

• If you/others are really concerned about the different number of
  spaces issue, I'd go with your final option: tab per tone and
  configurable spaces per tab.

  The code design of my current add-on monkeyPatches
  speech.getIndentationSpeech to do this. I'd probably put most of
  this code there,

It's not really ideal for getIndentationSpeech to actually produce
output; it's supposed to just return output. In theory, it could be
called but the result might not be spoken... or it might be called
multiple times with only one result spoken. That said, the current
speech system doesn't give you any other option, so this will have to
do for now. Still, we should note somewhere that this should be fixed
once speech refactor happens.

and maybe put a tones.reportIndentation item in tones.py so that I
don't bloat the speech.getIndentationSpeech function with
unnecessary math and stuff.

Understand not wanting to bloat, but I'm guessing it should only be a
couple of lines of code. It doesn't make sense to me to have
tones.reportIndentation or the like, since it'll only ever get used by
this code. If you like, you could split it out into a private helper
function in speech.

As for getting config values, is it fine performance wise to just
use config.conf["documentFormatting"]["reportIndentsAsStereo"] for
this or is that too slow?

That's fine, though if you're going to fetch, say, more than 3 values
from the same section, it's probably worth grabbing the section as a
local variable.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivaxaSU2o2g-6366iIB27-E3946orks5qJ0wugaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[jcsteh]

IMO, we should just drop stereo. It doesn't seem to be practical without pitch, and if you've got pitch, there's little point in expressing it with stereo as well.

I think just go for 2 spaces as a semitone, tab as a tone. We can always add the edit field later if really necessary. Easier to add more options later than take them away later.

We might be able to add a reportIndentations that takes in a number of
chars and produces a beep as a side effect. This would be added after
the call if the option is on.

Meh. Just do the beep in getIndentationSpeech. We'll convert it to a SpeechCommand post speech refactor.

[nvaccessAuto]

Incubated in 5859154.

[LeonarddeR]

It seems that, when reporting is set to tones, speech is still used to say "no indentation" while it shouldn't.

[derekriemer]

confirmed. Let me fix.

On 6/10/2016 8:39 AM, Leonard de Ruijter wrote:

It seems that, when reporting is set to tones, speech is still used to
say "no indentation" while it shouldn't.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivdkFTquYJi5ZBMvPFZQ1yDvkAnrPks5qKXc8gaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[derekriemer]

Hi,

I just realized that we could make this better by getting the current
synth's volume, and playing tones at this volume. Can I add this, as it
would make the user experience more pleasant. I.E. left = right =
getSynth().volume

then when played

tones.beep(pitch, duration, left=left, right=right)

On 6/10/2016 8:39 AM, Leonard de Ruijter wrote:

It seems that, when reporting is set to tones, speech is still used to
say "no indentation" while it shouldn't.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivdkFTquYJi5ZBMvPFZQ1yDvkAnrPks5qKXc8gaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[LeonarddeR]

1. Speaking of this, do we want this feature to be disabled when speech
   is off? At least it beebs now when speech is off, and I'm not sure
   whether we really want this.
2. I also noticed another breakage. When line indentation is off and I
   use alt+i, the interface jumps between line indentation (as expected)
   and paragraph indentation (which is certainly unexpected). When line
   indentation is on, alt+i jumps between line indentation and the new
   report indents with setting.
3. Does this new indent reporting feature also apply to paragraph
   indents? If not, we probably want to collapse report line indentation
   and report indents with into one option to avoid misunderstandings.

[derekriemer]

In fact, I would highly recommend we do this change. without this, the volume is too loud for the synth at low volumes, which drowns it out. I'll add to the pull request later.

[derekriemer]

@leonardder commented on Jun 10, 2016, 11:59 AM MDT:

1. Speaking of this, do we want this feature to be disabled when speech is off? At least it beebs now when speech is off, and I'm not sure whether we really want this.

This oddly doesn't happen with speech mode of beeps. @jcsteh any idea why it happens with off but not speech?

1. I also noticed another breakage. When line indentation is off and I
   use alt+i, the interface jumps between line indentation (as expected)
   and paragraph indentation (which is certainly unexpected). When line
   indentation is on, alt+i jumps between line indentation and the new
   report indents with setting.

This might be a wx bug. I could remove the access key for this combo box. I don't know why this happens, maybe because this box is disabled, the access key still trys to go to it, and focus lands on the next enabled control.

1. Does this new indent reporting feature also apply to paragraph
   indents? If not, we probably want to collapse report line indentation
   and report indents with into one option to avoid misunderstandings.

[derekriemer]

1. Does this new indent reporting feature also apply to paragraph indents? If not, we probably want to collapse report line indentation and report indents with into one option to avoid misunderstandings.

I don't follow. Do you mean just add off to the combo box?

[derekriemer]

That actually might be a nice UI improvement.

The checkbox could be removed, and the options would be

• Off: Indents aren't reported.
• Speech: Indents get reported as speech.
• Tones: Indents get reported as tones.
• Both.

[LeonarddeR]

That's exactly how I mean it to be. Not sure whether this breaks compatibility with the older boolean behaviour though. May be off should be mapped to false and speech should be mapped to true to be compatible with earlier configurations.

[derekriemer]

That's why I did it this way but theoretically we could map off to false in any other value to true as well as that value in the config

Sent from a mobile device.
Please disregard errors as this is a smaller device.

On Jun 10, 2016, at 13:26, Leonard de Ruijter [email protected] wrote:

That's exactly how I mean it to be. Not sure whether this breaks
compatibility with the older boolean behaviour though. May be off should
be mapped to false and speech should be mapped to true to be compatible
with earlier configurations.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[jcsteh]

Combining these into one option makes sense. One idea is to just have two booleans: reportIndentation used for speech (for backwards compat) and reportIndentationUsingTones. It seems pointless to bother with bitwise flags when we have to have two settings anyway.

There's a separate issue open about having sounds follow the syth volume. There are problems with this; e.g. synth volume levels differ wildly, it's not entirely intuitive that adjusting voice volume will adjust sound volume, etc. So, I think this should perhaps be addressed separately.

As to why it doesn't happen for speech mode beeps, tones will only play one beep at a time; a subsequent call will override the earlier one. So, the speech beep overrides the indentation beep. You should disable this if speech mode is not speech.

[derekriemer]

The issue is that the tones can be too loud here. Is there a clean way
to set the volume for the tones?

On 6/10/2016 2:55 PM, James Teh wrote:

Combining these into one option makes sense. One idea is to just have
two booleans: reportIndentation used for speech (for backwards compat)
and reportIndentationUsingTones. It seems pointless to bother with
bitwise flags when we have to have two settings anyway.

There's a separate issue open about having sounds follow the syth
volume. There are problems with this; e.g. synth volume levels differ
wildly, it's not entirely intuitive that adjusting voice volume will
adjust sound volume, etc. So, I think this should perhaps be addressed
separately.

As to why it doesn't happen for speech mode beeps, tones will only
play one beep at a time; a subsequent call will override the earlier
one. So, the speech beep overrides the indentation beep. You should
disable this if speech mode is not speech.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivbSAuGzQvYXhDbyGYVZSDolYrYXvks5qKc9MgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[jcsteh]

Sure, but that's true for all tones (progress bar beeps, audio coordinates, etc.). By all means happy to discuss, but it's a more general issue.

[derekriemer]

The issue here (I would suggest using the tones for a while with code
with speech at a lowish volume for a couple of hours when you're
coding), is that the beginning of speech streams can be drowned out by
the tone. This means that if this option is on, the tone can in some
cases make the beginning of lines a bit hard to hear. Progress beeps
usually don't happen during every few utterances.

Also, did you see my fix for the no indent issue?

On 6/10/2016 3:38 PM, James Teh wrote:

Sure, but that's true for all tones (progress bar beeps, audio
coordinates, etc.). By all means happy to discuss, but it's a more
general issue.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivfdU7-D7XWFnQAKZHsKX0hP1RfRhks5qKdlAgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[jcsteh]

I get it, but if you do this here, it's inconsistent with all other beeps. Aside from the questions that raises for users, you'll also need to test edge cases; e.g. if the synth doesn't support volume (which the API does allow). Also, if tones is later updated to use voice volume, this code has to be updated.

[derekriemer]

I understand. I was just trying to think of a better solution.

On 6/10/2016 4:10 PM, James Teh wrote:

I get it, but if you do this here, it's inconsistent with all other
beeps. Aside from the questions that raises for users, you'll also
need to test edge cases; e.g. if the synth doesn't support volume
(which the API does allow). Also, if tones is later updated to use
voice volume, this code has to be updated.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivfuY6CA3UUs19tx_DErBSvZyi6c1ks5qKeDcgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[jcsteh]

Your latest change looks fine. Are you planning to address these two issues:

Combining these into one option makes sense. One idea is to just have two booleans: reportIndentation used for speech (for backwards compat) and reportIndentationUsingTones.

and

You should disable this if speech mode is not speech.

[derekriemer]

Hi,

I do plan to implement this (probably this weekend or some evening).

Thanks.

On 6/14/2016 11:53 PM, James Teh wrote:

Your latest change looks fine. Are you planning to address these two
issues:

Combining these into one option makes sense. One idea is to just
have two booleans: reportIndentation used for speech (for
backwards compat) and reportIndentationUsingTones.

and

You should disable this if speech mode is not speech.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivU6F-m55Frra_gaXSz7epKErpL0fks5qL5NYgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[derekriemer]

@jcsteh It's kind of a pointless feature if we don't have a only report indents as tones option. With the above in mind, disabling the whole feature if speech is on is a bad idea. I'd propose "report indents as tones or report indents as speech" as the condition. Therefore, the user can check either box.

[derekriemer]

I'm not sure that was clear. I'm meaning that only if both boxes are unchecked we don't report indents. They'll be off both by default.

[jcsteh]

If speech is off, I'm arguing it's not useful to play tones, even if only tones are enabled. If you've turned off speech, presumably, you want silence when pressing commands.

[derekriemer]

Oh. That issue. I thought this was referencing disabling tones if they
tell NVDA not to speak it. I'll fix this.

On 6/17/2016 10:16 AM, James Teh wrote:

If speech is off, I'm arguing it's not useful to play tones, even if
only tones are enabled. If you've turned off speech, presumably, you
want silence when pressing commands.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivT-ArDW1Qao1Fu2TZdgoXoh4s58yks5qMshFgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[jcsteh]

Okay. This has gotten confused. So we were discussing this:

Combining these into one option makes sense.

I meant combining these into one GUI option instead of two.

When I said this:

One idea is to just have two booleans: reportIndentation used for speech (for backwards compat) and reportIndentationUsingTones.

I was just referring to the internal config variables. So, even though it's a single option in the GUI, it would be two boolean options in the config to preserve backwards compat, while still being simpler than the bitwise stuff. Either or both of them could be turned off; they aren't mutually exclusive.

[jcsteh]

I meant combining these into one GUI option instead of two.

Extra clarification: a combo box with four options: off, speech, tones, both.

[derekriemer]

Ah.

I'll redesign the GUI later.

On 6/17/2016 10:31 AM, James Teh wrote:

Okay. This has gotten confused. So we were discussing this:

Combining these into one option makes sense.

I meant combining these into one GUI option instead of two.

When I said this:

One idea is to just have two booleans: reportIndentation used for
speech (for backwards compat) and reportIndentationUsingTones.

I was just referring to the internal config variables. So, even though
it's a single option in the GUI, it would be two boolean options in
the config to preserve backwards compat, while still being simpler
than the bitwise stuff. Either or both of them could be turned off;
they aren't mutually exclusive.> I meant combining these into one GUI
option instead of two.

Extra clarification: a combo box with four options: off, speech,
tones, both.

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivemdXQ1N0PDDRGX5ExxsKTB8wJOLks5qMsv6gaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[LeonarddeR]

@derekriemer, Could it be that you accidentally missed the script in globalCommands.GlobalCommands.script_toggleReportLineIndentation which allows for setting a shortcut to toggle line indent reporting? I think that script has to reflect the new tones and speech and tones settings. Thanks!

[derekriemer]

Yes.

@jcsteh I can't work on this until at least next week, and I will be
working on other things as a priority. Does this mean you need to take
this out of master?

On 9/8/2016 11:16 PM, Leonard de Ruijter wrote:

@derekriemer https://github.com/derekriemer, Could it be that you
accidentally missed the script in
globalCommands.GlobalCommands.script_toggleReportLineIndentation which
allows for setting a shortcut to toggle line indent reporting? I think
that script has to reflect the new tones and speech and tones
settings. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivQUIhU7-SVWeuwUOG9AWH_TfnqNAks5qoOuXgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[derekriemer]

Or at least stop it from going into stable?

On 9/8/2016 11:16 PM, Leonard de Ruijter wrote:

@derekriemer https://github.com/derekriemer, Could it be that you
accidentally missed the script in
globalCommands.GlobalCommands.script_toggleReportLineIndentation which
allows for setting a shortcut to toggle line indent reporting? I think
that script has to reflect the new tones and speech and tones
settings. Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivQUIhU7-SVWeuwUOG9AWH_TfnqNAks5qoOuXgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194

[jcsteh]

Stable is just master frozen at a certain point in time, so we can't prevent things from going to stable without removing them from master. I'll leave it in master for another week or so, but I'll probably need to remove it soon after that if we don't have a fix.

[josephsl]

Hi, If you don’t mind, I’ll take a stab at it tomorrow afternoon, as we also need to provide Gettext context also.

From: James Teh [mailto:[email protected]]
Sent: Monday, September 12, 2016 8:59 PM
To: nvaccess/nvda [email protected]
Subject: Re: [nvaccess/nvda] Allow NVDA to report indentation as tones (#5906)

Stable is just master frozen at a certain point in time, so we can't
prevent things from going to stable without removing them from master.
I'll leave it in master for another week or so, but I'll probably need
to remove it soon after that if we don't have a fix.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub #5906 (comment) , or mute the thread https://github.com/notifications/unsubscribe-auth/AHgLkDfowmdcmWApYe0lA578sGjqWoe_ks5qph9qgaJpZM4IRpnJ .

[zersiax]

In Visual Studio, when line numbers are enabled, this doesn't seem to work. Turning them off makes it work as expected, but when they are on it appears NVDA thinks the line numbers are the first characters of the line rather than the indentation chars, mucking things up.

[derekriemer]

How do I enable/disable line numbers in visual studeo?

On 11/22/2016 2:25 PM, Florian Beijers wrote:

In Visual Studio, when line numbers are enabled, this doesn't seem to
work. Turning them off makes it work as expected, but when they are on
it appears NVDA thinks the line numbers are the first characters of
the line rather than the indentation chars, mucking things up.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#5906 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFGivU2kqcEywT9wU-rMqLZAJt0EjrO6ks5rA13kgaJpZM4IRpnJ.

---

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at [email protected] mailto:[email protected]
Phone: (303) 906-2194